Don't access i915->vbt.ddi_port_info[] directly.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c52c39df43374b51f56439daf8047079afae7749.1579270868.git.jani.nikula@intel.com

Move the force_dvi check to a single function that can be called from
both mode validation and compute_config().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Lots of enc_to_foo(&encoder->base) around. Simplify by passing
in the intel_encoder instead.

@find@
identifier F =~ "^enc_to_.*";
identifier E;
@@
F(struct drm_encoder *E)
{
...
}

@@
identifier find.F;
identifier find.E;
@@
F(
- struct drm_encoder *E
+ struct intel_encoder *encoder
  )
{
<...
- E
+ &encoder->base
...>
}

@@
identifier find.F;
expression E;
@@
- F(E)
+ F(to_intel_encoder(E))

@@
expression E;
@@
- to_intel_encoder(&E->base)
+ E
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-4-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

Life is usually easier when we pass around intel_ types instead
of drm_ types. In this case it might not be, but I think being
consistent is a good thing anyway. Also some of this might get
cleaned up a bit more later as we keep propagating the intel_
types further.

@find@
identifier F =~ "^intel_attached_.*";
identifier C;
@@
F(struct drm_connector *C)
{
...
}

@@
identifier find.F;
identifier find.C;
@@
F(
- struct drm_connector *C
+ struct intel_connector *connector
  )
{
<...
- C
+ &connector->base
...>
}

@@
identifier find.F;
expression C;
@@
- F(C)
+ F(to_intel_connector(C))

@@
expression C;
@@
- to_intel_connector(&C->base)
+ C
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-3-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Use the ddc pointer provided by the generic connector.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@collabora.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Reviewed-by: NEmil Velikov <emil.velikov@collabora.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128150130.26266-1-andrzej.p@collabora.com

intel_hdcp_transcoder_config() is clobbering some globally visible
state in .compute_config(). That is a big no no as .compute_config()
is supposed to have no visible side effects when either the commit
fails or it's just a TEST_ONLY commit.

Inline this stuff into intel_hdcp_enable() so that the state only
gets modified when we actually commit the state to the hardware.

Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Fixes: 39e2df09 ("drm/i915/hdcp: update current transcoder into intel_hdcp")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-2-ville.syrjala@linux.intel.comReviewed-by: NRamalingam C <ramalingam.c@intel.com>
(cherry picked from commit 67e1d5ed)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

intel_hdcp_transcoder_config() is clobbering some globally visible
state in .compute_config(). That is a big no no as .compute_config()
is supposed to have no visible side effects when either the commit
fails or it's just a TEST_ONLY commit.

Inline this stuff into intel_hdcp_enable() so that the state only
gets modified when we actually commit the state to the hardware.

Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Fixes: 39e2df09 ("drm/i915/hdcp: update current transcoder into intel_hdcp")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-2-ville.syrjala@linux.intel.comReviewed-by: NRamalingam C <ramalingam.c@intel.com>

HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d
so no need to initialize conn_state->picture_aspect_ratio with it.

Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-6-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that
selected we should keep whatever aspect ratio the mode already has.

Also no point in checking for connector->is_hdmi in the SDVO code
since we only attach the property to HDMI connectors.

Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-5-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

Tiger Lake supports HDMI on port A. For other platforms we ignore what
the VBT says regarding HDMI to workaround broken VBTs, see
commit 2ba7d7e0 ("drm/i915/bios: ignore HDMI on port A"). Make this
apply gen12+ so they inherit the TGL behavior.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113021935.41547-1-lucas.demarchi@intel.com

The warning should be just a warning. Where it is currently is wrong
since we already registered the connector on drm, meaning it dies later
on a NULL pointer deref if the VBT-overriding we have is removed. Move
the warning up.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108214251.79305-1-lucas.demarchi@intel.com

For the HPD interrupt functionality the HW depends on power wells in the
display core domain to be on. Accordingly when enabling these power
wells the HPD polling logic will force an HPD detection cycle to account
for hotplug events that may have happened when such a power well was
off.

Thus a detect cycle started by polling could start a new detect cycle if
a power well in the display core domain gets enabled during detect and
stays enabled after detect completes. That in turn can lead to a
detection cycle runaway.

To prevent re-triggering a poll-detect cycle make sure we drop all power
references we acquired during detect synchronously by the end of detect.
This will let the poll-detect logic continue with polling (matching the
off state of the corresponding power wells) instead of scheduling a new
detection cycle.

Fixes: 6cfe7ec0 ("drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112125Reported-and-tested-by: NVal Kulkov <val.kulkov@gmail.com>
Reported-and-tested-by: Nwangqr <wqr.prg@gmail.com>
Cc: Val Kulkov <val.kulkov@gmail.com>
Cc: wangqr <wqr.prg@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028181517.22602-1-imre.deak@intel.com
(cherry picked from commit a8ddac7c)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Split up crtc_state->base to uapi. This is done using the following patch,
ran after the previous commit that splits out any hw references:

@@
struct intel_crtc_state *T;
@@
-T->base
+T->uapi
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-5-maarten.lankhorst@linux.intel.com

Split up crtc_state->base to hw where appropriate. This is done using the following patch:

@@
struct intel_crtc_state *T;
identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$";
@@
-T->base.x
+T->hw.x

@@
struct drm_crtc_state *T;
identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$";
@@
-to_intel_crtc_state(T)->base.x
+to_intel_crtc_state(T)->hw.x
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-4-maarten.lankhorst@linux.intel.com

Just set pipe_mask=~0 for the non-special cases where any pipe
will do. intel_encoder_possible_crtcs() will anyway drop out
anything that doesn't exist.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-5-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

Rename the encoder->crtc_mask to encoder->pipe_mask to better
reflect what it actually contains.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-3-ville.syrjala@linux.intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>

For the HPD interrupt functionality the HW depends on power wells in the
display core domain to be on. Accordingly when enabling these power
wells the HPD polling logic will force an HPD detection cycle to account
for hotplug events that may have happened when such a power well was
off.

Thus a detect cycle started by polling could start a new detect cycle if
a power well in the display core domain gets enabled during detect and
stays enabled after detect completes. That in turn can lead to a
detection cycle runaway.

To prevent re-triggering a poll-detect cycle make sure we drop all power
references we acquired during detect synchronously by the end of detect.
This will let the poll-detect logic continue with polling (matching the
off state of the corresponding power wells) instead of scheduling a new
detection cycle.

Fixes: 6cfe7ec0 ("drm/i915: Remove the unneeded AUX power ref from intel_dp_detect()")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112125Reported-and-tested-by: NVal Kulkov <val.kulkov@gmail.com>
Reported-and-tested-by: Nwangqr <wqr.prg@gmail.com>
Cc: Val Kulkov <val.kulkov@gmail.com>
Cc: wangqr <wqr.prg@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191028181517.22602-1-imre.deak@intel.com

All the timeout values fit in u16, so let's shrink the structure
a bit.

This ends up actually increasing the .text size a bit due to
some changes in instructions (constant imul+small jmps replaced
with mov+bigger jmpqs). Seems pretty arbitrary to me so I'll
just pretend I didn't see it.

    text	   data	    bss	    dec	    hex	filename
-  34521	    360	      0	  34881	   8841	intel_hdmi.o
+  34537	    360	      0	  34897	   8851	intel_hdmi.o
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-5-ville.syrjala@linux.intel.comReviewed-by: NRamalingam C <ramalingam.c@intel.com>

The only reason for the timeout2 value in the array is the
HDCP_2_2_AKE_SEND_HPRIME message. But that one still needs
special casing inside the loop, and so just ends up making
the code harder to read. Let's just remove this leaky
timeout2 abstraction and special case that one command
in a way that is easy to understand. We can then remove the
timeout2 member from struct entirely.

    text	   data	    bss	    dec	    hex	filename
-  34633	    360	      0	  34993	   88b1	intel_hdmi.o
+  34521	    360	      0	  34881	   8841	intel_hdmi.o
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-4-ville.syrjala@linux.intel.comReviewed-by: NRamalingam C <ramalingam.c@intel.com>

The .read_2_2() hooks is never called for any of the message
types with a zero timeout. So it's all just dead weight which
we can chuck.

    text	   data	    bss	    dec	    hex	filename
-  34701	    360	      0	  35061	   88f5	intel_hdmi.o
+  34633	    360	      0	  34993	   88b1	intel_hdmi.o
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-3-ville.syrjala@linux.intel.comReviewed-by: NRamalingam C <ramalingam.c@intel.com>

The array is there only for timeout, "data" doesn't mean anything
so let's rename the thing to be more descriptive.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010145127.7487-2-ville.syrjala@linux.intel.comReviewed-by: NRamalingam C <ramalingam.c@intel.com>

According to Bspec, GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
GEN11. And it makes handle different register size for
HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
platforms. It addresses Uma's review comments.

v9: Add WARN_ON() when buffer size if larger than register size. [Ville]
Signed-off-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919195311.13972-7-gwan-gyeong.mun@intel.com

Use BIT(pipe) for better legibility when populating the crtc_mask
for encoders.

Also remove the redundant possible_crtcs setup for the TV encoder.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190708162048.4286-11-ville.syrjala@linux.intel.com

crtc_state->limited_color_range only applies to RGB output but
we're currently setting it even for YCbCr output. That will
lead to conflicting MSA and PIPECONF settings which can mess
up the image. Let's make sure limited_color_range stays unset
with YCbCr output.

Also WARN if we end up with such a bogus combination when
programming the MSA MISC bits as it's impossible to even
indicate quantization rangle for YCbCr via MSA MISC. YCbCr
output is simply assumed to be limited range always. Note
that VSC SDP does provide a mechanism for full range YCbCr,
so in the future we may want to rethink how we compute/store
this state.

And for good measure we add the same WARN to the HDMI path.

v2: s/==/!=/ in the HDMI WARN
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190718164523.11738-1-ville.syrjala@linux.intel.comReviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>

Pull the code for computing the limited color range
setting into a small helper. We'll add a bit more to it
later.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-5-ville.syrjala@linux.intel.comReviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>

We're configuring the AVI infoframe quantization range bits as if
we're always transmitting RGB pixels. Let's fix this so that we
correctly indicate limited range YCC quantization range when
transmitting YCbCr instead.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-4-ville.syrjala@linux.intel.comReviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>

Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
planes' max resolution. This has the nasty implication that modes on the
connectors' mode list may not be usable when the user asks for a
fullscreen plane. Seeing as that is the most common use case it seems
prudent to filter out modes that don't allow for fullscreen planes to
be enabled.

Let's do that in the connetor .mode_valid() hook so that normally
such modes are kept hidden but the user is still able to forcibly
specify such a mode if they know they don't need fullscreen planes.

This is in line with ealier policies regarding certain clock limits.
The idea is to prevent the casual user from encountering a mode that
would fail under typical conditions, but allow the expert user to
force things if they so wish.

Maybe in the future we should consider automagically using two
planes when one can't cover the entire screen? Wouldn't be a
great match for the current uapi with explicit planes though,
but I guess no worse than using two pipes (which we apparently
have to in the future anyway). Either that or we'd have to
teach userspace to do it for us.

v2: Fix icl+ max plane heigth (Manasi)

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Leho Kraav <leho@kraav.com>
Cc: Sean Paul <sean@poorly.run>
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190918150707.32420-1-ville.syrjala@linux.intel.com

We generally assume future platforms will inherit the behavior of the
most recent platforms, so update our DDC pin mapping defaults to match
how ICP/TGP behave (i.e., pins starting from GMBUS_PIN_1_BXT for combo
PHY's and pins starting from GMBUS_PIN_9_TC1_ICP for TC PHY's).  MCC's
non-standard handling of combo PHY C seems like a platform-specific
quirk that is unlikely to be duplicated on future platforms, so continue
handling it as a special case.

Without this change, future platforms would default to gen4-style pin
mapping which is almost certainly not what we'll want.

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190918235626.3750-1-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Reogranize the HDMI deep color state computation to just
loop over possible bpc values. Avoids having to maintain
so many variants of the clock etc.

The current code also looks confused w.r.t. port_clock vs.
bw_constrained. It would happily update port_clock for
deep color but then not actually enable deep color due to
bw_constrained being set. The new logic handles that case
correctly.

v2: Pull stuff into separate funcs (Jani)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190828183424.7856-1-ville.syrjala@linux.intel.com

enum port is a mess now because it no longer matches the spec
at all. Let's start to dig ourselves out of this hole by
reducing our reliance on port_name(). This should at least make
a bunch of debug messages a bit more sensible while we think how
to fill the the hole properly.

Based on the following cocci script with a lot of manual cleanup
(all the format strings etc.):
@@
expression E;
@@
(
- port_name(E->port)
+ E->base.base.id, E->base.name
|
- port_name(E.port)
+ E.base.base.id, E.base.name
)

@@
enum port P;
expression E;
@@
  P = E->port
<...
- port_name(P)
+ E->base.base.id, E->base.name
...>

@@
enum port P;
expression E;
@@
  P = E.port
<...
- port_name(P)
+ E.base.base.id, E.base.name
...>

@@
expression E;
@@
{
- enum port P = E;
... when != P
}
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190830182719.32608-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

>From Gen12 onwards, HDCP HW block is implemented within transcoders.
Till Gen11 HDCP HW block was part of DDI.

Hence required changes in HW programming is handled here.

As ME FW needs the transcoder detail on which HDCP is enabled
on Gen12+ platform, we are populating the detail in hdcp_port_data.

v2:
  _MMIO_TRANS is used [Lucas and Daniel]
  platform check is moved into the caller [Lucas]
v3:
  platform check is moved into a macro [Shashank]
v4:
  Few optimizations in the coding [Shashank]
v5:
  Fixed alignment in macro definition in i915_reg.h [Shashank]
  unused variables "reg" is removed.
v6:
  Configuring the transcoder at compute_config.
  transcoder is used instead of pipe in macros.
  Rebased.
v7:
  transcoder is cached at intel_hdcp
  hdcp_port_data is configured with transcoder index asper ME FW.
v8:
  s/trans/cpu_transcoder
  s/tc/cpu_transcoder
v9:
  rep_ctl is prepared for TCD too.
  return moved into deault of rep_ctl prepare function [Shashank]
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-7-ramalingam.c@intel.com

On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.

v2:
  s/trans/cpu_transcoder [Jani]
v3:
  comment is added for fw_ddi init for gen12+ [Shashank]
  only hdcp capable transcoder is translated into fw_tc [Shashank]
v4:
  fw_tc initialization is kept for modeset. [Tomas]
  few extra doc is added at port_data init [Tomas]
v5:
  Few comments are improvised [Tomas]
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190828164216.405-6-ramalingam.c@intel.com

Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Signed-off-by: NDariusz Marcinkiewicz <darekm@google.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814104520.6001-3-darekm@google.com

It's static const data, make it so.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820134019.13229-5-jani.nikula@intel.com

Split struct declaration and array definition. Fix indents and
whitespace. No functional changes.

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: NRamalingam C <ramalingam.c@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820134019.13229-4-jani.nikula@intel.com

Everything about the file is about display, and mostly about types
related to display. Move under display/ as intel_display_types.h to
reflect the facts.

There's still plenty to clean up, but start off with moving the file
where it logically belongs and naming according to contents.

v2: fix the include guard name in the renamed file
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190806113933.11799-1-jani.nikula@intel.com

Right now we are aware of two cases that needs another hotplug retry:
- Unpowered type-c dongles
- HDMI slow unplug

Both have a complete explanation in the code to schedule another run
of the hotplug handler.

It could have more checks to just trigger the retry in those two
specific cases but why would sink signal a long pulse if there is
no change? Also the drawback of running the hotplug handler again
is really low and that could fix another cases that we are not
aware.

Also retrying for old DP ports(non-DDI) to make it consistent and not
cause CI failures if those systems are connected to chamelium boards
that will be used to simulate the issues reported in here.

v2: Also retrying for old DP ports(non-DDI)(Imre)

v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep
it consistent(Rodrigo)
Tested-by: NTimo Aaltonen <tjaalton@ubuntu.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-2-jose.souza@intel.com

Now that we distinguish between phy and port(ddi), mcc_port_to_ddc_pin
should use the phy, not the DDI, for determining DDC pins.

We're only converting the MCC function at the moment since EHL is the
only platform that has configurations where port!=phy.

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712221641.21031-1-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Make the icl function generic so it is based on phy type and can be
applied to tgl as well.

I checked if this could not apply to EHL as well, but unfortunately
there the HPD and DDC/GMBUS pins for DDI C are mapped to TypeC Port 1
even though it doesn't have TC phy.

v2: don't add a separate function for TGL, but rather reuse the ICL one
    (suggested by Rodrigo)
v3: rebase after the introduction of enum phy and use it for the
    conversions

Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190711173115.28296-19-lucas.demarchi@intel.com

Although EHL introduces a new PCH, the South Display part of the PCH
that we care about is nearly identical to ICP, just with some pins
remapped.  Most notably, Port C is mapped to the pins that ICP uses for
TC Port 1.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190615004210.16656-1-matthew.d.roper@intel.com