Pps power hook seems to be problematic for backlight controlled via
aux channel. Disable it for such cases.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3657
Cc: stable@vger.kernel.org
Signed-off-by: NJouni Högander <jouni.hogander@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220822140836.534432-1-jouni.hogander@intel.com

From MTL onwards we support DSC 1.2, since there is hardcoding to minor
version 1, update it.

Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: NAnkit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220817124516.284456-1-jani.nikula@intel.com

drm_crtc.h has no need for drm_edid.h, so don't include it.
Avoids useless rebuilds of the entire universe when
touching drm_edid.h.

Quite a few placs do currently depend on drm_edid.h without
actually including it directly. All of those need to be fixed
up.

v2: Fix up i915 and msm some more
v3: Fix alphabetical ordering (Sam)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220614090245.30283-1-ville.syrjala@linux.intel.comAcked-by: NSam Ravnborg <sam@ravnborg.org>
Acked-by: NJani Nikula <jani.nikula@intel.com>

Each LFP may have different panel type which is stored in LFP data
data block. Based on the child device index respective panel-type/
panel-type2 field will be used.

v1: Initial rfc verion.
v2: Based on review comments from Jani,
- Used panel-type instead addition panel-index variable.
- DEVICE_HANDLE_* name changed and placed before DEVICE_TYPE_*
macro.
v3:
- passing intel_bios_encoder_data as argument of
intel_bios_init_panel(). Passing NULL to indicate encoder is not
initialized yet for dsi as current focus is to enable dual EDP. [Jani]
v4:
- encoder->devdata used which is initialized before from vbt
structure. [Jani]
Signed-off-by: NAnimesh Manna <animesh.manna@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-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/20220620065138.5126-1-animesh.manna@intel.com

This reverts commit 73867c87 ("drm/i915/display: Remove check for
low voltage sku for max dp source rate"), which, on an i7-11850H iGPU
with a Thinkpad X1 Extreme Gen 4, attached to a LG LP160UQ1-SPB1
embedded panel, causes wild flickering glitching technicolor
pyrotechnics on resumption from suspend. The display shows strobing
colors in an utter disaster explosion of pantone, as though bombs were
dropped on the leprechauns at the base of the rainbow.

Rebooting the machine fixes the issue, presumably because the display is
initialized by firmware rather than by i915. Otherwise, the GPU appears
to work fine.

Bisection traced it back to this commit, which makes sense given the
issues.

Note: This re-opens, and puts back to the drawing board,
https://gitlab.freedesktop.org/drm/intel/-/issues/5272 which was fixed
by the regressing commit.

Fixes: 73867c87 ("drm/i915/display: Remove check for low voltage sku for max dp source rate")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220613102241.9236-1-Jason@zx2c4.com
(cherry picked from commit d5929835)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts commit 73867c87 ("drm/i915/display: Remove check for
low voltage sku for max dp source rate"), which, on an i7-11850H iGPU
with a Thinkpad X1 Extreme Gen 4, attached to a LG LP160UQ1-SPB1
embedded panel, causes wild flickering glitching technicolor
pyrotechnics on resumption from suspend. The display shows strobing
colors in an utter disaster explosion of pantone, as though bombs were
dropped on the leprechauns at the base of the rainbow.

Rebooting the machine fixes the issue, presumably because the display is
initialized by firmware rather than by i915. Otherwise, the GPU appears
to work fine.

Bisection traced it back to this commit, which makes sense given the
issues.

Note: This re-opens, and puts back to the drawing board,
https://gitlab.freedesktop.org/drm/intel/-/issues/5272 which was fixed
by the regressing commit.

Fixes: 73867c87 ("drm/i915/display: Remove check for low voltage sku for max dp source rate")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220613102241.9236-1-Jason@zx2c4.com

The eDP BDB block has gained yet another max link rate field.
Let's parse it and consult it during the source rate filtering.

v2: *20 instead of *2 to get the correct units (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/20220602205723.11341-1-ville.syrjala@linux.intel.com

We'll need to know the VBT panel_type before we can determine the
maximum link rate for eDP. To that end move
intel_dp_set_source_rates() & co. to be called after the per-panel
VBT parsing has been done.

intel_dp_mst_encoder_init() depends on the source rates so we'll
have to do it a bit later as well.

v2: Fix the intel_dp_mst_encoder_init() oops

Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220603165841.15481-1-ville.syrjala@linux.intel.com

The intel_dp_dsc_get_output_bpp() function outputs two lines of
unconditional logs, which was okay when it was called only once.  But
now, we also call this function from intel_dp_mode_valid(), which is
in turn called for every mode we need to validate.  This causes a lot
of useless noise.

Remove the unconditional prints to avoid spamming the logs.  Also
remove one more print that is not unconditional, but is related.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220607074433.1202917-1-luca@coelho.fi

It seem that when dealing with VRR capable eDP panels we need
to accept fixed modes with variable vblank length (which is what
VRR varies dynamically). Typically the preferred mode seems to be
a non-VRR more (lowish dotclock/refresh rate + short vblank).

We also have examples where it looks like even the hblank length
is a bit different between the preferred mode vs. VRR mode(s).
So let's just accept anything that has matching hdisp+vdisp+flags.

v2: Document that is_alt_drrs_mode() is a subset of is_alt_vrr_mode() (Jani)

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/125Reviewed-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/20220531191844.11313-4-ville.syrjala@linux.intel.com

Apparently when the VBT panel_type==0xff we should trawl through
the PNPID table and check for a match against the EDID. If a
match is found the index gives us the panel_type.

Tried to match the Windows behaviour here with first looking
for an exact match, and if one isn't found we fall back to
looking for a match w/o the mfg year/week.

v2: Rebase due to vlv_dsi changes
v3: Adjust to .get_panel_type() vfunc

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5545Reviewed-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/20220510104242.6099-14-ville.syrjala@linux.intel.com

Move the panel specific VBT parsing to happen during the
output probing stage. Needs to be done because the VBT
parsing will need to look at the EDID to determine
the correct panel_type on some machines.

We split the parsed VBT data (i915->vbt) along the same
boundary. For the moment we just hoist all the panel
specific stuff into connector->panel.vbt since that seems
like the most convenient place for eg. the backlight code.

Note that we simply drop the drrs type check from
intel_drrs_frontbuffer_update() since that operates on the whole
device rather than a specific connector/encoder. But the check
was just a micro optimization so removing it doesn't actually
mattter for correctness.

TODO: Lot's of cleanup to be done in the future. Eg. most of
the DSI stuff could probably be eliminated entirely and just
parsed on demand during DSI init.

v2: Note the intel_drrs_frontbuffer_update() change
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-13-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Split the PPS init to something we do at the start of the eDP
probe and a second part we do at the end.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-8-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

We have the same "override eDP VBT bpp with the current bpp" code
duplciated in two places. Extract it to a helper function.

TODO: Having this in .get_config() is pretty ugly. Should probably
try to move it somewhere else (setup_hw_state()/etc.)...
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Pass intel_connector instead of drm_connector to
intel_vrr_is_capable(). Will result in less ugly casts.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Move DRM's HMDI helpers into the display/ subdirectoy and add it
to DRM's display helpers. Update all affected drivers. No functional
changes.

The HDMI helpers were implemented in the EDID and connector code, but
are actually unrelated. With the move to the display-helper library, we
can remove the dependency on drm_edid.{c,h} in some driver's HDMI source
files.

Several of the HDMI helpers remain in EDID code because both share parts
of their implementation internally. With better refractoring of the EDID
code, those HDMI helpers could be moved into the display-helper library
as well.

v3:
	* fix Kconfig dependencies (Javier)
v2:
	* reduce HDMI helpers to avoid exporting functions (Jani)
	* fix include statements (Jani, Javier)
	* update Kconfig symbols
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-8-tzimmermann@suse.de

DSC is the Display Stream Compression standard for DisplayPort. Move
the DSC code into display/ and split the header into files for protocol
core and DRM helpers. Adapt all users of the code. No functional
changes.

To avoid the proliferation of Kconfig options, DSC is part of DRM's
support for DisplayPort. If necessary, a new option could make DSC an
independent feature.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-6-tzimmermann@suse.de

Rename dp/ to display/ to account for additional display-related
helpers, such as HDMI. Update all related include statements. No
functional changes.

Various drivers, such as i915 and amdgpu, use similar naming scheme
by putting code for video-output standards into a local display/
directory. The new directory's name is aligned with this convention.

v2:
	* update commit message (Javier)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-3-tzimmermann@suse.de

With some VRR panels, user can turn VRR ON/OFF on the fly from the panel settings.
When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA bit
in the DPCD. Currently the driver parses that onevery HPD but fails to reset
the corresponding VRR Capable Connector property.
Hence the userspace still sees this as VRR Capable panel which is incorrect.

Fix this by explicitly resetting the connector property.

v2: Reset vrr capable if status == connector_disconnected
v3: Use i915 and use bool vrr_capable (Jani Nikula)
v4: Move vrr_capable to after update modes call (Jani N)
Remove the redundant comment (Jan N)
v5: Fixes the regression on older platforms by resetting the VRR
only if HAS_VRR
v6: Remove the checks from driver, add in drm core before
setting VRR prop (Ville)
v7: Move VRR set/reset to set/unset_edid (Ville)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 9bc34b4d ("drm/i915/display/vrr: Reset VRR capable property on a long hpd")
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303233222.4698-1-manasi.d.navare@intel.com
(cherry picked from commit d999ad10)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

With some VRR panels, user can turn VRR ON/OFF on the fly from the panel settings.
When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA bit
in the DPCD. Currently the driver parses that onevery HPD but fails to reset
the corresponding VRR Capable Connector property.
Hence the userspace still sees this as VRR Capable panel which is incorrect.

Fix this by explicitly resetting the connector property.

v2: Reset vrr capable if status == connector_disconnected
v3: Use i915 and use bool vrr_capable (Jani Nikula)
v4: Move vrr_capable to after update modes call (Jani N)
Remove the redundant comment (Jan N)
v5: Fixes the regression on older platforms by resetting the VRR
only if HAS_VRR
v6: Remove the checks from driver, add in drm core before
setting VRR prop (Ville)
v7: Move VRR set/reset to set/unset_edid (Ville)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 9bc34b4d ("drm/i915/display/vrr: Reset VRR capable property on a long hpd")
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303233222.4698-1-manasi.d.navare@intel.com

Our YCbCr output is always supposed to be limited range BT.709.
That's what we send with native HDMI. The conn_state->colorspace
stuff is entirely independent of that and is not supposed to alter
the generated output in any way. If we want a way to do that then
we need a new proprty for it.

Make it so that the RGB->YCbCr conversion when performed by the
DPF will match the BT.709 we would transmit with native HDMI.

Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-12-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

With native HDMI we allow the user to override the mode with
something that may not respect the downstream (sink,dual-mode adapter)
TMDS clock limits. Let's reuse the same logic for DP HDMI DFPs
so that behaviour is more or less uniform.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-11-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

Currently we only support "4:2:0 also" modes on native HDMI.
Extend that support for DP as well.

With all the HDMI DFP TMDS clock handling sorted out this
is now going to work for both native DP and DP->HDMI
converters. As with native HDMI we first check if RGB
output is possible, and if not we try YCbCr 4:2:0 instead.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-10-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

Rework the HDMI DFP TMDS clock checks to also check at 8bpc.
Previously we only checked the deep color cases. But I suppose
a sink could potentially declare "4:2:0 also" modes that only
actually fit within its own limits when using 4:2:0. Even if
that is too nuts to be real there is no real harm in running
through the full checks for everything.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-9-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

Hoist the drm_mode_is_420_only() from intel_dp_output_format()
into the caller. This will allow intel_dp_output_format() to be
reused for "4:2:0 also" modes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-8-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

Prefer to use intel_connector over drm_connector. Also clean
up the related variable names a bit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-7-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

Consolidate the double pfit call, and reorder things so that
intel_dp_output_format() and intel_dp_compute_link_config() are
back-to-back. They are intimately related, and will need to be
called twice to properly handle the "4:2:0 also" modes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-6-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

intel_dp_hdmi_ycbcr420() does account for native DP 4:2:0
output as well, so lets rename it a bit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-5-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

Declutter intel_dp_compute_config() a bit by moving the
has_audio computation into a helper. HDMI already does the same thing.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-4-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

Currently we only look at the DFPs max TMDS clock limit when
considering whether the mode is valid, or whether we can do
deep color. The sink's max TMDS clock limit may be lower than
the DFPs, so we need to account for it as well.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4095
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2844Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-3-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

We're currently duplicating the DFP min/max TMDS clock checks
in .mode_valid() and .compute_config(). Extract a helper suitable
for both use cases.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322120015.28074-2-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

Stop hand rolling drm_connector_attach_hdr_output_metadata_property().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220321195006.775-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Only seamless DRRS has specific hardware requirements so
we can allow static DRRS on any eDP port.

And we can replace these port checks and whatnot with
a simple check to make sure the transcoder(s) we're
about to use are capable of seamless DRRS.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-11-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>

intel_drrs_compute_config() is 100% DP specific. DRRS on other
types of encoders wouldn't do any of these M2/N2 calculations
etc. So let's move this into intel_dp.c so all the DP state
calculation is more concentrated into one place.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-10-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

The intel_panel_add_edid_fixed_mode() vs.
intel_panel_add_edid_downclock_mode() split is not really
helpful. Let's just roll those into a single function so
that the connector init code doesn't have to care too much
about this. All we need to know is whether DRRS should be
allowed or not.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

intel_drrs_init() is a mostly pointless wrapper around
intel_panel_add_edid_downclock_mode(), get rid of it.

The only really useful thing left in there is the debug
print regarding the DRRS type supported by the connector.
Let's just move that into intel_panel_init().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Rather than having the connector init get the fixed mode back from
intel_panel and then feed it straight back into intel_panel_init()
let's just make the fixed mode lookup put the mode directly onto
the panel's fixed_modes list. Avoids the pointless round trip and
opens the door for further enhancements to the fixed mode handling.

v2: Make the debug message correct by using intel_panel_drrs_type() (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Pull all the eDP specific platform/port checks out from
intel_drrs_init() into intel_edp_has_drrs().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Debug log when DSC is going to be used, and why, instead of
unconditionally logging the rarely used debug option setting, which
might not have any bearing on whether DSC is going to be used or not.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220330093019.4150386-1-jani.nikula@intel.com

Rename intel_panel_vbt_fixed_mode() to
intel_panel_vbt_lfp_fixed_mode() to be more descriptive.
We'll have another VBT fixed mode function soon and we
don't want to confuse the two.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>