Refactor the output_format calculation into a helper so that
we can reuse it for mode validation as well.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200917214335.3569-1-ville.syrjala@linux.intel.comReviewed-by: NVandita Kulkarni <vandita.kulkarni@intel.com>

When roll over detected for seq_num_m, we shouldn't continue with stream
management with rolled over value.

So we are terminating the stream management retry, on roll over of the
seq_num_m.

v2:
  using drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
v3:
  dev_priv is used as i915 [JaniN]
v4:
  roll over is detected at the start of the stream management.
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> [v3]
Tested-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200923132435.17039-3-anshuman.gupta@intel.com

As per the HDCP2.2 compliance test 1B-10 expectation, when stream
management for a repeater fails, we retry thrice and when it fails
in all retries, HDCP2.2 reauthentication aborted at kernel.

v2:
  seq_num_m++ is extended for steam management failures too.[Anshuman]
v3:
  use drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman]
v4:
  dev_priv is used as i915 [JaniN]
v5:
  Few improvisements are done [Sean]
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Tested-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200923132435.17039-2-anshuman.gupta@intel.com

The name of the argument is different, causing those warnings:

	./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member 'video_code' not described in 'drm_display_mode_from_cea_vic'
	./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter 'vic' description in 'drm_display_mode_from_cea_vic'

Fixes: 7af655bc ("drm/dp: Add drm_dp_downstream_mode()")
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200922175357.42998-3-lyude@redhat.com

As warned by kernel-doc:

	./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or member 'type' not described in 'drm_dp_downstream_is_type'
	./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or member 'dev' not described in 'drm_dp_downstream_mode'

Some function parameters weren't documented.

Fixes: 38784f6f ("drm/dp: Add helpers to identify downstream facing port types")
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200922175357.42998-2-lyude@redhat.com

Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

This workaround applies to all TGL and RKL steppings.
Signed-off-by: NSwathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200911221158.4700-1-swathi.dhanavanthri@intel.com

Since we now have proper old and new cdclk state we no longer
need to keep this flag to indicate that the force min cdclk has
changed. Instead just check if the old vs. new value are different.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-4-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

With the dbuf code mostly converted over to the new global state
handling we can remove the leftovers of the old global state
stuff.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200902122141.15181-1-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

For platforms that can't do native 4:2:0 outout we may still be
able to do it by getting the DP->HDMI protocol converter to
perform the 4:4:4->4:2:0 downsamling for us. In this case we
have to configure our hardware to output YCbCr 4:4:4, which we've
already hooked up so all we need to do is flip the switch.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-19-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add helpers to determine whether the DFP supports
YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion.

v2: Add kdocs (Lyude)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-18-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Account for the TMDS clock limits declared by the DFP
when determining what color depth we're going to use.

v2: Drop the reference to DP++ dongle since it's not handled here
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-17-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pull the "do we want to enable audio?" computation into a small helper
to make intel_hdmi_compute_config() less messy. Will make it easier to
add more checks for this later (eg. we should actually be checking
at the hblank is long enough for audio transmission).
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-16-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use drm_dp_downstream_mode() to get a suitable mode for downstream
facing ports which don't have an EDID.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-15-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The downstream facing port caps in the DPCD can give us a hint
as to what kind of display mode the sink can use if it doesn't
have an EDID. Use that information to pick a suitable mode.

v2: Use Returns: for kdoc (Lyude)
    Add kdocs for drm_display_mode_from_cea_vic() (Lyude)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-14-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion.
Let's use that to configure the "HDMI mode" (ie. infoframes vs. not)
based on the capabilities of the sink.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-13-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the new helpers to extract the TMDS clock limits from
the downstream facing port and check them in .mode_valid().

TODO: we should check these in .compute_config() too to eg.
determine if we can do deep color on the HDMI side or not
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-12-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add helpers to get the TMDS clock limits for HDMI/DVI downstream
facing ports.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-11-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the downstream facing port dotclock check into a new function
(intel_dp_mode_valid_downstream()) so that we have a nice future
place where we can collect other related checks.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-10-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We want to differentiate between the DFP dotclock and TMDS clock
limits. Let's convert the current thing to just give us the
dotclock limit.

v2: Use Returns: for kdoc (Lyude)
    Fix up nouveau code too
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-9-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Deal with more cases in drm_dp_downstream_max_bpc():
- DPCD 1.0 -> assume 8bpc for non-DP
- DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything
- DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is crap
- anything else -> assume 8bpc

v2: Use Returns: for kdoc (Lyude)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-8-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a few helpers to let us better identify which kind of DFP
we're dealing with.

v2: Use Returns: for kdoc (Lyude)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-7-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Stash the downstream facing port max bpc away during
intel_dp_set_edid(). We'll soon need the EDID in there so
we can't figure this out so easily during .compute_config() anymore.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-6-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Our definitions for the DPCD DFP capabilities are lacking.
Add the missing bits.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-5-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DP 1.3 and 1.4 introduced some new registers for DP->HDMI protocol
converters. Define those.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-4-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Non-HDMI sinks shouldn't be sent infoframes. Check for that when
using LSPCON.

FIXME: How do we turn off infoframes once enabled? Do we even
       have to?
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-3-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It helps when the logs have a dump of the DFP capabilities.

v2: Move the dumping to the new helper
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200904115354.25336-2-ville.syrjala@linux.intel.comReviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since we store a pointer to the fake iommu device that is allocated on
the stack, as soon as we leave the function it goes out of scope and any
future dereference is undefined behaviour. Just in case we may need to
look at the fake iommu device after initialiation, move the allocation
from the stack into the data.

Fixes: 01b9d4e2 ("iommu/vt-d: Use dev_iommu_priv_get/set()")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200916105022.28316-2-chris@chris-wilson.co.uk

Just in case the caller passes in 0 for both slow&fast timeouts, make
sure we initialise the stack value returned. Add an assert so that we
don't make the mistake of passing 0 timeouts for the wait.

drivers/gpu/drm/i915/intel_uncore.c:2011 __intel_wait_for_register_fw() error: uninitialized symbol 'reg_value'.

References: 3f649ab7 ("treewide: Remove uninitialized_var() usage")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200916105022.28316-1-chris@chris-wilson.co.uk

We currenty check for platform at multiple parts in the driver
to grab the correct PLL. Let us begin to centralize it through a
helper function.

v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville)

v3: Clean up combo_pll_disable() (Rodrigo)

v4: s/dev_priv/i915 (Jani)
Move static and return type to the same line( Ville, Jani)
Suggested-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200914175703.15024-1-anusha.srivatsa@intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

No point in assigning the function return value to a local
variable if we're just going to use it the one time.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-13-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Introduce intel_hpd_hotplug_irqs() as a partner to
intel_hpd_enabled_irqs(). There's no need to care about the
encoders which we're not exposing, so we can avoid hardcoding
the masks in various places.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-12-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Make a clean split between hpd pins for DDI vs. TC. This matches
how the actual hardware is split.

And with this we move the DDI/PHY->HPD pin mapping into the encoder
init instead of having to remap yet again in the interrupt code.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-11-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Currently DP/HDMI/DDI encoders init their hpd_pin from the
connector init. Let's move it to the encoder init so that
we don't need to add platform specific junk to the connector
init (which is shared by all g4x+ platforms).
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-10-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

No reason to stuff both DDI and TC port handling into the same
function. Split it into two.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-9-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

gen11_hpd_detection_setup() is missing ports TC5/6. Add them.

TODO: Might be nice to only enable the hpd detection logic
for ports we actually have. Should be rolled out for all
platforms if/when done...
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-8-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

We have nice parametrized GEN11_{TC,TBT}_HOTPLUG() so nuke
the overlapping defines.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-7-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

As with everything else VBT can now specify AUX CH H or I.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-6-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

VBT has ports H and I since version 217.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-5-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

AUX CH H/I need their power domains too.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-4-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>