drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode()

If we have no VBT, or the VBT didn't declare the encoder
in question, we won't have the 'devdata' for the encoder.
Instead of oopsing just bail early.

We won't be able to tell whether the port is DP++ or not,
but so be it.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10464
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240319092443.15769-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 26410896206342c8a80d2b027923e9ee7d33b733)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/dsi: Go back to the previous INIT_OTP/DISPLAY_ON order, mostly

Reinstate commit 88b065943cb5 ("drm/i915/dsi: Do display on
sequence later on icl+"), for the most part. Turns out some
machines (eg. Chuwi Minibook X) really do need that updated order.
It is also the order the Windows driver uses.

However we can't just undo the revert since that would again
break Lenovo 82TQ. After staring at the VBT sequences for both
machines I've concluded that the Lenovo 82TQ sequences look
somewhat broken:
- INIT_OTP is not present at all
- what should be in INIT_OTP is found in DISPLAY_ON
- what should be in DISPLAY_ON is found in BACKLIGHT_ON
(along with the actual backlight stuff)

The Chuwi Minibook X on the other hand has a full complement
of sequences in its VBT.

So let's try to deal with the broken sequences in the
Lenovo 82TQ VBT by simply swapping the (non-existent)
INIT_OTP sequence with the DISPLAY_ON sequence. Thus we
execute DISPLAY_ON when intending to execute INIT_OTP,
and execute nothing at all when intending to execute
DISPLAY_ON. That should be 100% equivalent to the
revert, for such broken VBTs.

Cc: stable@vger.kernel.org
Fixes: 6992eb815d08 ("Revert "drm/i915/dsi: Do display on sequence later on icl+"")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/10071
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10334
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240305083659.8396-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 94ae4612ea336bfc3c12b3fc68467c6711a4f39b)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/bios: Use per-device debugs for VBT related stuff

Switch to drm_dbg_kms() in the VBT code so we see which
device generated the debugs. Need to plumb i915 a bit deeper
to make that happen.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Switch to kms debugs

The VBT code is all about displays, so switch to UT_KMS debugs
from UT_DRIVER.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/opregion: abstract getting the opregion VBT

Add a function to get the opregion VBT instead of accessing the opregion
structures directly.

Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8205b8fa724f98bbf1f76c59e661909d874e843e.1704992868.git.jani.nikula@intel.com

drm/i915/bios: move i915_vbt debugfs to intel_bios.c

All things VBT should be placed in intel_bios.c.

While at it, shove in a FIXME comment about VBT possibly originating
from other places than opregion.

Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5e14a9559b6916022b506e5eb8d943783dc627a2.1704992868.git.jani.nikula@intel.com

drm/i915/mtl: Add fake PCH for Meteor Lake

Correct the implementation trying to detect MTL PCH with
the MTL fake PCH id.

On MTL, both the North Display (NDE) and South Display (SDE) functionality
reside on the same die (the SoC die in this case), unlike many past
platforms where the SDE was on a separate PCH die. The code is (badly)
structured today in a way that assumes the SDE is always on the PCH for
modern platforms, so on platforms where we don't actually need to identify
the PCH to figure out how the SDE behaves (i.e., all DG1/2 GPUs as well as
MTL and LNL),we've been assigning a "fake PCH" as a quickhack that allows
us to avoid restructuring a bunch of the code.we've been assigning a
"fake PCH" as a quick hack that allows us to avoid restructuring a bunch
of the code.

Removed unused macros of LNL amd MTL as well.

v2: Reorder PCH_MTL conditional check (Matt Roper)
Reverting to PCH_MTL for PICA interrupt(Matt Roper)

Signed-off-by: Haridhar Kalvala <haridhar.kalvala@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231219185233.1469675-1-haridhar.kalvala@intel.com

drm/i915: Drop redundant NULL check

intel_bios_get_dsc_params() is only called from
gen11_dsi_dsc_compute_config() and it always passes a non-NULL
crtc_state in. Drop the redundant check.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231207193441.20206-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dgfx: DGFX uses direct VBT pin mapping

DDC pin mapping for DGFX cards uses direct VBT pin mapping

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231128190329.1335562-1-lucas.demarchi@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>

drm/i915/display: Store compressed bpp in U6.4 format

DSC parameter bits_per_pixel is stored in U6.4 format.
The 4 bits represent the fractional part of the bpp.
Currently we use compressed_bpp member of dsc structure to store
only the integral part of the bits_per_pixel.
To store the full bits_per_pixel along with the fractional part,
compressed_bpp is changed to store bpp in U6.4 formats. Intergral
part is retrieved by simply right shifting the member compressed_bpp by 4.

v2:
-Use to_bpp_int, to_bpp_frac_dec, to_bpp_x16 helpers while dealing
with compressed bpp. (Suraj)
-Fix comment styling. (Suraj)

v3:
-Add separate file for 6.4 fixed point helper(Jani, Nikula)
-Add comment for magic values(Suraj)

v4:
-Fix checkpatch warnings caused by renaming(Suraj)

v5:
-Rebase.
-Use existing helpers for conversion of bpp_int to bpp_x16
and vice versa.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn>
Link: https://patchwork.freedesktop.org/patch/msgid/20231110101020.4067342-3-ankit.k.nautiyal@intel.com

drm/i915/bios: Clamp VBT HDMI level shift on BDW

Apparently some BDW machines (eg. HP Pavilion 15-ab) shipped with
a VBT inherited from some earlier HSW model. On HSW the HDMI level
shift value could go up to 11, whereas on BDW the maximum value is
9.

The DDI code does clamp the bogus value, but it does so with
a WARN which we don't really want. To avoid that let's just sanitize
the bogus VBT HDMI level shift value ahead of time for all BDW machines.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9461
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231013140214.1713-1-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915/display: Move edp_vswing module parameter under display

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231024124109.384973-16-jouni.hogander@intel.com

drm/i915/display: Move vbt_sdvo_panel_type module parameter under display

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231024124109.384973-9-jouni.hogander@intel.com

drm/i915/bios: Fixup h/vsync_end instead of h/vtotal

We have the same h/vsync_end vs. h/vtotal quirk in the VBT parser
that was also present in EDID parser. Adjust the VBT parser the
same way as was done for hte EDID parser to fixup h/vsync_end
instead of h/vtotal. While I'm not currently aware of any machines
that need this for the VBT it seems prudent to keep both parsers
in sync.

And while at it let's add some debugs here as well. A bit
lackluster but didn't feel like plumbing the connector all
the way down at this time.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230920211934.14920-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/lnl: Add gmbus/ddc support

LNL's south display uses the same table as MTP. Check for LNL's fake PCH
to make it consistent with the other checks.

The VBT table doesn't contain the VBT -> spec mapping for LNL. Like in
other cases, uses the same as the previous platform.

Bspec: 68971, 20124
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-18-lucas.demarchi@intel.com

drm/i915: Only check eDP HPD when AUX CH is shared

Apparently Acer Chromebook C740 (BDW-ULT) doesn't have the
eDP HPD line properly connected, and thus fails the new
HPD check during eDP probe. The result is that we lose the
eDP output.

I suspect all such machines would be Chromebooks or other
Linux exclusive systems as the Windows driver likely wouldn't
work either. I did check a few other BDW machines here and
those do have eDP HPD connected, one of them even is a
different Chromebook (Samus).

To account for these funky machines let's skip the HPD check when
it looks like the eDP port is the only one using that specific AUX
channel. In case of multiple ports sharing the same AUX CH (eg. on
Asrock B250M-HDV) we still do the check and thus should correctly
ignore the eDP port in favor of the other DP port (usually a DP->VGA
converter).

v2: Don't oops during list iteration

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9264
Fixes: cfe5bdfb27fa ("drm/i915: Check HPD live state during eDP probe")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230908052527.685-1-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915: Only check eDP HPD when AUX CH is shared

Apparently Acer Chromebook C740 (BDW-ULT) doesn't have the
eDP HPD line properly connected, and thus fails the new
HPD check during eDP probe. The result is that we lose the
eDP output.

I suspect all such machines would be Chromebooks or other
Linux exclusive systems as the Windows driver likely wouldn't
work either. I did check a few other BDW machines here and
those do have eDP HPD connected, one of them even is a
different Chromebook (Samus).

To account for these funky machines let's skip the HPD check when
it looks like the eDP port is the only one using that specific AUX
channel. In case of multiple ports sharing the same AUX CH (eg. on
Asrock B250M-HDV) we still do the check and thus should correctly
ignore the eDP port in favor of the other DP port (usually a DP->VGA
converter).

v2: Don't oops during list iteration

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9264
Fixes: cfe5bdfb27fa ("drm/i915: Check HPD live state during eDP probe")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230908052527.685-1-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
(cherry picked from commit 70052100fabec5d8c1b09c9959817a2f4517e6b5)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Try to initialize DDI/ICL+ DSI ports for every VBT child device

Try to deal with duplicate child devices for the same DDI port
by attempting to initialize them in VBT defined order The first
on to succeed for a specific DDI port will be the one we use.

We'll also get rid of i915->display.vbt.ports[] here as any conflicts
will now be handled at encoder registration time rather than during
VBT parsing. Note that intel_bios_encoder_data_lookup() still remaims
for pre-DDI DP/HDMI ports as those don't (at least yet) use VBT
driven initialization.

TODO: DSI dual link handling is sketchy at best

v2: Leave intel_bios_encoder_port() to the encoder callback (Jani)

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230630155846.29931-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Extract intel_bios_encoder_port()

We'll have a few places where we need to do the full (incl. ICL+ DSI)
DVO port->port conversion, so extract the code for that into a helper.

Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230630155846.29931-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Remove AUX CH sanitation

Stop with the VBT AUX CH sanitation, and instead just check
that the appropriate AUX CH is still available when initializing
a DP/TC port.

The reason being that we want to start initializing ports in
VBT order to deal with VBTs that declare child devices with
seemingly conflicting ports. As the encoder initialization can
fail for other reasons (at least for eDP+AUX) we can't know
upfront which way the conflicts should be resolved.

Note that the old way of sanitizing gave priority to the last
port declared in the VBT, but now we sort of do the opposite by
favoring the first encoder to successfully initialize. The reason
for the old "last port wins" preference was eg. Asrock B250M-HDV
where port A (eDP) and port E (DP->VGA) have an AUX CH conflict
and we need to prefer port E. However with the new way port A (eDP)
will be probed first, but will fail to probe due to HPD and thus
port E will still win in the end.

v2: Pimp the commit message (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230630155846.29931-5-ville.syrjala@linux.intel.com

drm/i915: Remove DDC pin sanitation

Stop with the VBT DDC pin sanitation, and instead just check
that the appropriate DDC pin is still available when initializing
a HDMI connector.

The reason being that we want to start initializing ports in
VBT order to deal with VBTs that declare child devices with
seemingly conflicting ports. As the encoder initialization can
fail for other reasons (at least for eDP+AUX) we can't know
upfront which way the conflicts should be resolved.

Note that the old way of sanitizing gave priority to the last
port declared in the VBT, but now we sort of do the opposite by
favoring the first encoder to successfully initialize. So far
we're not aware of HDMI/DDC use cases where this would matter
but for AUX CH (will be subject to a similar change) there are
known cases where it matters.

Also note that the old code fell back to the platform default DDC
pin if the VBT pin was populated but invalid. That doesn't seem like
such a great idea because the VBT might have later declared another
port using that platform default pin, and so we might just be
creating more DDC pin conflicts here. So lets not second guess the
VBT and simply reject the entire HDMI encoder if the VBT DDC pin is
invalid.

v2: Pimp the commit message (Jani)

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230630155846.29931-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/mtl: Skip using vbt hdmi_level_shifter selection on MTL

The hdmi_level_shifter part of General Bytes definition in VBT, which was
used for choosing different levels on earlier platforms is now a hidden
optin and shows the default value of 0. The level shifter is now to be
deduced from hdmi_default_entry in intel_ddi_buf_trans for each phy.

Skip providing the default hw provided value to force driver to choose hdmi
default entry.

Bspec: 20124
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230616210028.1601533-1-radhakrishna.sripada@intel.com

drm/i915/bios: add helper for reading SPI

Add helper for reading SPI to not duplicate the write&read combo
everywhere.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230512111446.1524038-1-jani.nikula@intel.com

drm/i915: Nuke intel_bios_is_port_dp_dual_mode()

Now that we have encoder->devdata everwhere we don't need
the intel_bios_is_port_dp_dual_mode() wrapper any more.

And while at it let's include it in the child device log
dump as well since the logic in there is a bit more complex
than just DP&&HDMI.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509160206.25971-3-ville.syrjala@linux.intel.com
Acked-by: Gustavo Sousa <gustavo.sousa@intel.com>

drm/i915: Flip VBT DDC pin maps around

Swap the roles of the index vs. value for the VBT DDC pin
mapping tables. This is not strictly necessary for DDC pins
but it will make this work exactly like the AUX CH mapping
tables where the role reversal is necessary (or at least makes
things easier). Consistency is good.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509160206.25971-2-ville.syrjala@linux.intel.com
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>

drm/i915: Split map_aux_ch() into per-platform arrays

The big switch+if statement mess in map_aux_ch() is
illegible. Split up into cleaner per-platform arrays
like we already have for the gmbus pins.

We use enum aux_ch as the index and the VBT thing as
the value. Slightly non-intuitive perhaps but if we
did it the other way around we'd have problems with
AUX_CH_A being zero, and thus any non-populated
element would look like AUX_CH_A.

v2: flip the index vs. value around

TODO: Didn't bother with the platform variants beyond the
ones that really need remapping, which means if the
VBT is bogus we end up with a nonexistent aux ch.
Might be nice to check this a bit better.
Yet another bitmask in device info?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230509160206.25971-1-ville.syrjala@linux.intel.com
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>

drm/i915/bios: Rename find_section to find_bdb_section

This prevents a namespace collision on other archs.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230315121924.2314693-1-jani.nikula@intel.com

drm/i915: Bump VBT version for expected child dev size check

The most modern VBT I've observed in the wild is version 250.
The child dev size hasn't changed since version 216, so bump
the version number in the expected child dev size check.

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

drm/i915: Get HDR DPCD refresh timeout from VBT

Grab the HDR DPCD refresh timeout (time we need to wait after
writing the sourc OUI before the HDR DPCD registers are ready)
from the VBT.

Windows doesn't even seem to have any default value for this,
which is perhaps a bit weird since the VBT value is documented
as TGL+ and I thought the HDR backlight stuff might already be
used on earlier platforms. To play it safe I left the old
hardcoded 30ms default in place. Digging through some internal
stuff that seems to have been a number given by the vendor for
one particularly slow TCON. Although I did see 50ms mentioned
somewhere as well.

Let's also include the value in the debug print to ease
debugging, and toss in the customary connector id+name as well.

The TGL Thinkpad T14 I have sets this to 0 btw. So the delay
is now gone on this machine:
[CONNECTOR:308:eDP-1] Detected Intel HDR backlight interface version 1
[CONNECTOR:308:eDP-1] Using Intel proprietary eDP backlight controls
[CONNECTOR:308:eDP-1] SDR backlight is controlled through PWM
[CONNECTOR:308:eDP-1] Using native PCH PWM for backlight control (controller=0)
[CONNECTOR:308:eDP-1] Using AUX HDR interface for backlight control (range 0..496)
[CONNECTOR:308:eDP-1] Performing OUI wait (0 ms)

Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230220164718.23117-1-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Restructure intel_bios_port_aux_ch()

Restructure intel_bios_port_aux_ch() to resemble the ddc_pin
counterpart, where the intel_bios.c stuff only deals with the
child device definition, and the platform default will come from
elsewhere.

This requires the introduction of AUX_CH_NONE as the value 0
is already taken to mean AUX_CH_A.

v2: Sort includes alphabetically (Ankit)
vCould we ask them to do a BIOS fix for all of them so that
we wouldn't keep getting these bug reports for each model
separately?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216231312.32664-1-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Use encoder->devdata more

Switch a lot of the intel_bios_foo() stuff to just accept the
devdata (VBT child device info) directly, instead of taking
detours via vbt.ports[].

Also unify the function naming scheme.

v2: Drop the redundant "encoder" from the dp/hdmi specific functions

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

drm/i915: Use encoder->devdata in eDP init

Since we now populate encoder->devdata for all DP capable
platforms we can consult it directly during the eDP
connector init instead of taking a detour via some global
list/array.

Unfortunately we can't quite get rid of
intel_dp_is_port_edp() since it's still used by the higher
level ilk/vlv/chv output setup code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Iterate all child devs in intel_bios_is_port_present()

Instead of consulting vbt.ports[] lets just go through the
whole child device list to check whether a specific port
was declared by the VBT or not.

Note that this doesn't change anything wrt. detecting duplicate
child devices with the same port as vbt.ports[] would also always
contain exactly one of the duplicates.

v2: Include a is_port_valid() check to deal with some broken VBTs
Mention something about duplicate port detection (Jani)

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

drm/i915: Pass devdata to intel_bios_port_aux_ch()

Currently intel_bios_port_aux_ch() digs out the devdata
(VBT child device info) from the vbt.ports[] array. We
need to get rid of that, so just pass in the correct
encoder->devdata (now that we have it also for g4x+ ports)
directly.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Replace intel_bios_is_port_hpd_inverted() with intel_bios_encoder_hpd_invert()

intel_bios_is_port_hpd_inverted() is only used on bxt/glk on
which we always have encoder->devdata available. So consult
that instead of digging around in vbt.ports[].

And rename the function to match the common pattern.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Replace intel_bios_is_lane_reversal_needed() with intel_bios_encoder_lane_reversal()

The sole user of intel_bios_is_lane_reversal_needed() has
the devdata already located, so pass it in directly instead
of digging it again from vbt.ports[].

And rename the function to follow the common pattern for
these things.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Replace intel_bios_is_lspcon_present() with intel_bios_encoder_is_lspcon()

We always have encoder->devdata available on the platforms
that can have LSPCON. So let's start looking there instead
of digging it out from vbt.ports[].

And let's rename the function to fit the common pattern
for these things.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Move variables to loop context

Lot of the loops over VBT child devices have variables
declared outside the loop but only used inside the loop.
Move the variables to a tighter scope.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: set default backlight controller index

With backlight controller set to -1 in intel_panel_init_alloc() to
distinguish uninitialized values, and controller later being set only if
it's present in VBT, we can end up with -1 for the controller:

[drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation
frequency 200 Hz, active high, min brightness 0, level 255,
controller 4294967295

There's no harm if it happens on platforms that ignore controller due to
only one backlight controller being present, like on VLV above, but play
it safe.

Fixes: bf38bba3e7d6 ("drm/i915: Try to use the correct power sequencer intiially on bxt/glk")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230207111626.1839645-1-jani.nikula@intel.com

drm/i915: Populate encoder->devdata for DSI on icl+

We now have some eDP+DSI dual panel systems floating around
where the DSI panel is the secondary LFP and thus needs to
consult "panel type 2" in VBT in order to locate all the
other panel type dependant stuff correctly.

To that end we need to pass in the devdata to
intel_bios_init_panel_late(), otherwise it'll just assume
we want the primary panel type. So let's try to just populate
the vbt.ports[] stuff and encoder->devdata for icl+ DSI
panels as well.

We can't do this on older platforms as there we risk a DSI
port aliasing with a HDMI/DP port, which is a totally legal
thing as the DSI ports live in their own little parallel
universe.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix VBT DSI DVO port handling

Turns out modern (icl+) VBTs still declare their DSI ports
as MIPI-A and MIPI-C despite the PHYs now being A and B.
Remap appropriately to allow the panels declared as MIPI-C
to work.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: set default backlight controller index

With backlight controller set to -1 in intel_panel_init_alloc() to
distinguish uninitialized values, and controller later being set only if
it's present in VBT, we can end up with -1 for the controller:

[drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation
frequency 200 Hz, active high, min brightness 0, level 255,
controller 4294967295

There's no harm if it happens on platforms that ignore controller due to
only one backlight controller being present, like on VLV above, but play
it safe.

Fixes: bf38bba3e7d6 ("drm/i915: Try to use the correct power sequencer intiially on bxt/glk")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230207111626.1839645-1-jani.nikula@intel.com
(cherry picked from commit a0dcb06d29d9e477e1984dc3859e61568361fc1a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Populate encoder->devdata for DSI on icl+

We now have some eDP+DSI dual panel systems floating around
where the DSI panel is the secondary LFP and thus needs to
consult "panel type 2" in VBT in order to locate all the
other panel type dependant stuff correctly.

To that end we need to pass in the devdata to
intel_bios_init_panel_late(), otherwise it'll just assume
we want the primary panel type. So let's try to just populate
the vbt.ports[] stuff and encoder->devdata for icl+ DSI
panels as well.

We can't do this on older platforms as there we risk a DSI
port aliasing with a HDMI/DP port, which is a totally legal
thing as the DSI ports live in their own little parallel
universe.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit ba00eb6a4bfbe5194ddda50730aba063951f8ce0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix VBT DSI DVO port handling

Turns out modern (icl+) VBTs still declare their DSI ports
as MIPI-A and MIPI-C despite the PHYs now being A and B.
Remap appropriately to allow the panels declared as MIPI-C
to work.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 118b5c136c04da705b274b0d39982bb8b7430fc5)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: convert intel_bios_init_panel() to drm_edid

Try to use struct drm_edid where possible, even if having to fall back
to looking into struct edid down low via drm_edid_raw().

v2: Rebase

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/897807d62f74f690a173ecd405e25c6ccdd63b98.1674643465.git.jani.nikula@intel.com

drm/i915/display: drop redundant display/ from #includes

Drop the redundant sub-directory from #includes under display/. Group
and sort the results.

v2: Rebase

Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230104153258.453431-1-jani.nikula@intel.com

drm/i915: Do panel VBT init early if the VBT declares an explicit panel type

Lots of ADL machines out there with bogus VBTs that declare
two eDP child devices. In order for those to work we need to
figure out which power sequencer to use before we try the EDID
read. So let's do the panel VBT init early if we can, falling
back to the post-EDID init otherwise.

The post-EDID init panel_type=0xff approach of assuming the
power sequencer should already be enabled doesn't really work
with multiple eDP panels, and currently we just end up using
the same power sequencer for both eDP ports, which at least
confuses the wakeref tracking, and potentially also causes us
to toggle the VDD for the panel when we should not.

Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-3-ville.syrjala@linux.intel.com

drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs

When (size != 0 || ptrs->lvds_ entries != 3), the program tries to
free() the ptrs. However, the ptrs is not created by calling kzmalloc(),
but is obtained by pointer offset operation.
This may lead to memory leaks or undefined behavior.

Fix this by replacing the arguments of kfree() with ptrs_block.

Fixes: a87d0a847607 ("drm/i915/bios: Generate LFP data table pointers if the VBT lacks them")
Signed-off-by: Xia Fukun <xiafukun@huawei.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125063428.69486-1-xiafukun@huawei.com

drm/i915: Fix VBT DSI DVO port handling

Turns out modern (icl+) VBTs still declare their DSI ports
as MIPI-A and MIPI-C despite the PHYs now being A and B.
Remap appropriately to allow the panels declared as MIPI-C
to work.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 118b5c136c04da705b274b0d39982bb8b7430fc5)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs

When (size != 0 || ptrs->lvds_ entries != 3), the program tries to
free() the ptrs. However, the ptrs is not created by calling kzmalloc(),
but is obtained by pointer offset operation.
This may lead to memory leaks or undefined behavior.

Fix this by replacing the arguments of kfree() with ptrs_block.

Fixes: a87d0a847607 ("drm/i915/bios: Generate LFP data table pointers if the VBT lacks them")
Signed-off-by: Xia Fukun <xiafukun@huawei.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125063428.69486-1-xiafukun@huawei.com
(cherry picked from commit 7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/mtl: Add MTP ddc pin configuration

Meteorlake PCH reuses Alderlake vbt, DE pin mapping. Extend
ADL-P pin mapping for Meteorlake.

Bspec: 20124 does not have the mapping for MTP. Based on Bspec:49306, 64051,
it is concluded that MTP and ADL-P PCH have the same vbt -> DE pin pair mapping.

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221005002534.2966978-1-radhakrishna.sripada@intel.com

drm/i915: WARN if a port should use VBT provided vswing tables

We don't parse the VBT vswing/preemphassis tables at all currently.
Let's WARN if a port wants to use them so we get a heads up that
whether we really need to implement this stuff or not. My
current stash contains no VBTs with this bit set.

v2: Move to print_ddi_port() (Jani)

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916204132.10469-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Parse DP/eDP max lane count from VBT

Limit the DP lane count based on the new VBT DP/eDP max
lane count field.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220715202044.11153-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers

The current scheme for generating the LFP data table pointers
(when the block including them is missing from the VBT) expects
the 0xffff sequence to only appear in the fp_timing terminator
entries. However some VBTs also have extra 0xffff sequences
elsewhere in the LFP data. When looking for the terminators
we may end up finding those extra sequeneces insted, which means
we deduce the wrong size for the fp_timing table. The code
then notices the inconsistent looking values and gives up on
the generated data table pointers, preventing us from parsing
the LFP data table entirely.

Let's give up on the "search for the terminators" approach
and instead just hardcode the expected size for the fp_timing
table.

We have enough sanity checks in place to make sure we
shouldn't end up parsing total garbage even if that size
should change in the future (although that seems unlikely
as the fp_timing and dvo_timing tables have been declared
obsolete as of VBT version 229).

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6592
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Validate fp_timing terminator presence

Validate the LFP data block a bit hardwer by making sure the
fp_timing terminators (0xffff) are where we expect them to be.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Copy the whole MIPI sequence block

Turns out the MIPI sequence block version number and
new block size fields are considered part of the block
header and are not included in the reported new block size
field itself. Bump up the block size appropriately so that
we'll copy over the last five bytes of the block as well.

For this particular machine those last five bytes included
parts of the GPIO op for the backlight on sequence, causing
the backlight no longer to turn back on:

Sequence 6 - MIPI_SEQ_BACKLIGHT_ON
Delay: 20000 us
- GPIO index 0, number 0, set 0 (0x00)
+ GPIO index 1, number 70, set 1 (0x01)

Cc: stable@vger.kernel.org
Fixes: e163cfb4c96d ("drm/i915/bios: Make copies of VBT data blocks")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6652
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220829135834.8585-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Dump PNPID and panel name

Dump the panel PNPID and name from the VBT.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-16-ville.syrjala@linux.intel.com

drm/i915: move vbt to display.vbt

Move display VBT related members under drm_i915_private display
sub-struct.

v2: Rebase

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/db4b648b201ea0b79654fec2028120999a735db0.1661779055.git.jani.nikula@intel.com

drm/i915: move opregion to display.opregion

Move display opregion related members under drm_i915_private display
sub-struct.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a0ceb5148835fa3e0828786ae491fcd11e2e77ff.1661779055.git.jani.nikula@intel.com

drm/i915/mtl: Add VBT port and AUX_CH mapping

Add the proper VBT port,AUX_CH -> i915 port,AUX_CH mapping which just
follows the ADL_P one.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220818234202.451742-9-radhakrishna.sripada@intel.com

drm/i915/dsi: fix dual-link DSI backlight and CABC ports for display 11+

The VBT dual-link DSI backlight and CABC still use ports A and C, both
in Bspec and code, while display 11+ DSI only supports ports A and
B. Assume port C actually means port B for display 11+ when parsing VBT.

Bspec: 20154
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6476
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8c462718bcc7b36a83e09d0a5eef058b6bc8b1a2.1660664162.git.jani.nikula@intel.com

drm/i915/bios: Copy the whole MIPI sequence block

Turns out the MIPI sequence block version number and
new block size fields are considered part of the block
header and are not included in the reported new block size
field itself. Bump up the block size appropriately so that
we'll copy over the last five bytes of the block as well.

For this particular machine those last five bytes included
parts of the GPIO op for the backlight on sequence, causing
the backlight no longer to turn back on:

Sequence 6 - MIPI_SEQ_BACKLIGHT_ON
Delay: 20000 us
- GPIO index 0, number 0, set 0 (0x00)
+ GPIO index 1, number 70, set 1 (0x01)

Cc: stable@vger.kernel.org
Fixes: e163cfb4c96d ("drm/i915/bios: Make copies of VBT data blocks")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6652
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220829135834.8585-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit a06289f3f72431f3777af95ea1226b5b0abdc426)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/dsi: fix dual-link DSI backlight and CABC ports for display 11+

The VBT dual-link DSI backlight and CABC still use ports A and C, both
in Bspec and code, while display 11+ DSI only supports ports A and
B. Assume port C actually means port B for display 11+ when parsing VBT.

Bspec: 20154
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6476
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8c462718bcc7b36a83e09d0a5eef058b6bc8b1a2.1660664162.git.jani.nikula@intel.com
(cherry picked from commit ab55165d73a444606af1530cd0d6448b04370f68)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/dsi: fix dual-link DSI backlight and CABC ports for display 11+

The VBT dual-link DSI backlight and CABC still use ports A and C, both
in Bspec and code, while display 11+ DSI only supports ports A and
B. Assume port C actually means port B for display 11+ when parsing VBT.

Bspec: 20154
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6476
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8c462718bcc7b36a83e09d0a5eef058b6bc8b1a2.1660664162.git.jani.nikula@intel.com
(cherry picked from commit ab55165d73a444606af1530cd0d6448b04370f68)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/bios: debug log ddi port info after parsing

The ddc pin and aux channel sanitization may disable DVI/HDMI and DP,
respectively, of ports parsed earlier, in "last one wins" fashion. With
parsing and printing interleaved, we'll end up logging support first and
disabling later anyway.

Now that we've split ddi port info parsing and printing, take it further
by doing the printing in a separate loop, fixing the logging.

Note that this also changes the logging order from VBT child device
order to port number order.

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

drm: Drop drm_edid.h from drm_crtc.h

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220614090245.30283-1-ville.syrjala@linux.intel.com
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: calculate panel type as per child device index in VBT

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: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220620065138.5126-1-animesh.manna@intel.com

drm/i915/bios: Introduce panel_bits() and panel_bool()

Abstract the bit extraction from the VBT per-panel bitfields
slightly.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220615151445.8531-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Don't parse the DPS panel type when the VBT does not have it

Older VBTs don't have all the stuff we've defined for the
LVDS options block (40). In particular we're currently parsing
the DPS panel type bits even though they may not exist, which
could mean we end up flagging the machine as supporting static
DRRS when the VBT declared no such thing.

We don't actually have a clear idea which VBT versions have
which bits so we rely on the block size instead.

Here's a quick list from my VBT stash:
mgm version 108 -> 4 bytes
alv version 120 -> 4 bytes
cst version 134 -> 14 bytes
pnv version 144 -> 14 bytes
cl version 142 -> 16 bytes
ctg version 155 -> 24 bytes

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220615151445.8531-2-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Move panel_type stuff out of parse_panel_options()

Parsing the panel_type is a bit special and should be done
before we parse anything else potentially panel-specific from
the VBT. So move it out from parse_panel_options(). It doesn't
neet to be there anyway since it'll do its own LVDS options
block lookup.

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

drm/i915/bios: split ddi port parsing and debug printing

Split ddi port parsing and debug printing to clarify the functional
parts of parse_ddi_port(), which are quite small nowadays.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/34e0dd92b7f7e9076df1f01b542347e599ec6653.1654870175.git.jani.nikula@intel.com

drm/i915/bios: no need to pass i915 to parse_ddi_port()

i915 is available via devdata, grab it there instead of passing.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/45c97c93bb9262c08aefa7b4bfe31f3f3481c998.1654870175.git.jani.nikula@intel.com

drm/i915/bios: use dvi and hdmi support helpers

Improve clarity by using the helpers we have.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3a0b52593f19a465dc0dd898db5f6bf13537d734.1654870175.git.jani.nikula@intel.com

drm/i915: Parse max link rate from the eDP BDB block

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: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220602205723.11341-1-ville.syrjala@linux.intel.com

drm/i915: Update eDP fast link training link rate parsing

We're not parsing the 5.4 Gbps value for the old eDP fast link
training link rate, nor are we parsing the new fast link training
link rate field. Remedy both.

Also we'll now use the actual link rate instead of the DPCD BW
register value.

Note that we're not even using this information for anything
currently, so should perhaps just nuke it all unless someone
is planning on implementing fast link training finally...

v2: Stop using the DPCD BW values (Jani)
*20 instead of *2 to get the rate in correct units (Jani)

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

drm/i915: Treat DMRRS as static DRRS

Some machines declare DRRS type = seamless, DRRS = no, DMRRS = yes.
I *think* DMRRS stands for "dynamcic media refresh rate", and
I suspect the way it's meant to work is that it lets the driver
switch refresh rates to match the frame rate for media playback.
Obviously for us all that kind of policy stuff is entirely up to
userspace, so the only thing we may do is make the extra refresh
rate(s) available.

So let's treat this case as just static DRRS for now. In the
future We might want to differentiate the "seamless w/ downclocking"
vs. "seamless w/o downclocking" cases so that we could do seamless
refresh rate changes for systems that only claim to support DMRRS.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/125
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220531191844.11313-7-ville.syrjala@linux.intel.com

drm/i915: Parse VRR capability from VBT

VBT seems to have an extra flag for VRR vs. not. Let's consult
that for eDP panels.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220531191844.11313-2-ville.syrjala@linux.intel.com

drm/i915/bios: Determine panel type via PNPID match

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/5545
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-14-ville.syrjala@linux.intel.com

drm/i915/bios: Split VBT data into per-panel vs. global parts

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Split VBT parsing to global vs. panel specific parts

Parsing the panel specific data (anything that depends on panel_type)
from VBT is currently happening too early. Split the whole thing
into global vs. panel specific parts so that we can start doing
the panel specific parsing at a later time.

v2: Clarify that this is about panel_type (Jani)
Split out the leak checks (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-12-ville.syrjala@linux.intel.com

drm/i915/bios: Split parse_driver_features() into two parts

We use the "driver features" block for two different kinds
of data: global data, and per panel data. Split the function
into two parts along that line so that we can start doing the
parsing in two different locations.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-11-ville.syrjala@linux.intel.com

drm/i915: Rename block_size()/block_offset()

Give block_size()/block_offset() a "raw_" prefix since they
both operate on the "raw" (as in not duplicated) BDB block
contents.

What actually spurred this was a conflict between intel_bios.c
block_size() vs. block_size() from blkdev.h. That only
happened to me on a custom tree where we somehow manage to
include blkdev.h into intel_bios.c. But I think the rename
makes sense anyway to clarify the purpose of these functions.

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

drm/i915/bios: Parse the seamless DRRS min refresh rate

Extract the seamless DRRS min refresh rate from the VBT.

v2: Do a version check

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-9-ville.syrjala@linux.intel.com

drm/i915/bios: Refactor panel_type code

Make the panel type code a bit more abstract along the
lines of the source of the panel type. For the moment
we have three classes: OpRegion, VBT, fallback.
Well introduce another one shortly.

We can now also print out all the different panel types,
and indicate which one we ultimately selected. Could help
with debugging.

v2: Add .get_panel_type() vfunc (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-8-ville.syrjala@linux.intel.com

drm/i915/bios: Extract get_panel_type()

Pull the code to determine the panel type into its own set of
sane functions.

v2: rebase

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-7-ville.syrjala@linux.intel.com

drm/i915/bios: Assume panel_type==0 if the VBT has bogus data

Just assume panel_type==0 always if the VBT gives us bogus data.
We actually already do this everywhere else except in
parse_panel_options() since we just leave i915->vbt.panel_type
zeroed. This also seems to be what Windows does.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-6-ville.syrjala@linux.intel.com

drm/i915/bios: Get access to the tail end of the LFP data block

We need to start parsing stuff from the tail end of the LFP data block.
This is made awkward by the fact that the fp_timing table has variable
size. So we must use a bit more finesse to get the tail end, and to
make sure we allocate enough memory for it to make sure our struct
representation fits.

v2: Rebase due to the preallocation of BDB blocks
v3: Rebase due to min_size WARN relocation
v4: Document BDB_LVDS_LFP_DATA vs. BDB_LVDS_LFP_DATA_PTRS order (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-4-ville.syrjala@linux.intel.com

drm/i915/bios: Generate LFP data table pointers if the VBT lacks them

Modern VBTs no longer contain the LFP data table pointers
block (41). We are expecting to have one in order to be able
to parse the LFP data block (42), so let's make one up.

Since the fp_timing table has variable size we must somehow
determine its size. Rather than just hardcode it we look for
the terminator bytes (0xffff) to figure out where each table
entry starts. dvo_timing, panel_pnp_id, and panel_name are
expected to have fixed size.

This has been observed on various machines, eg. TGL with BDB
version 240, CML with BDB version 231, etc. The most recent
VBT I've observed that still had block 41 had BDB version
228. So presumably the cutoff (if an exact cutoff even exists)
is somewhere around BDB version 229-231.

v2: kfree the thing we allocated, not the thing+3 bytes
v3: Do the debugprint only if we found the LFP data block
v4: Fix t0 null check (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-3-ville.syrjala@linux.intel.com

drm/i915/bios: Reorder panel DTD parsing

Reorder things so that we can parse the entier LFP data block
in one go. For now we just stick to parsing the DTD from it.

Also fix the misleading comment about block 42 being deprecated.
Only the DTD part is deprecated, the rest is still very much needed.

v2: Move the version check+comment into parse_generic_dtd() (Jani)

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220504150440.13748-2-ville.syrjala@linux.intel.com

drm/display: Move DSC header and helpers into display-helper module

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: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-6-tzimmermann@suse.de

drm: Rename dp/ to display/

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: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-3-tzimmermann@suse.de

drm/i915/bios: Validate the panel_name table

In addition to the fp_timing,dvo_timing,panel_pnp_id tables
there also exists a panel_name table. Unlike the others this
is just one offset+table_size even though there are still 16
actual panel_names in the data block.

The panel_name table made its first appearance somewhere
around VBT version 156-163. The exact version is not known.
But we don't need to know that since we can just check whether
the pointers block has enough room for it or not.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Trust the LFP data pointers

Now that we've sufficiently validated the LFP data pointers we
can trust them.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Validate LFP data table pointers

Make sure the LFP data table pointers sane. Sensible looking
table entries, everything points correctly into the data block,
etc.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Use the copy of the LFP data table always

Currently get_lvds_fp_timing() still returns a pointer to the original
data block rather than our copy. Let's convert the data pointer offsets
to be relative to the data block rather than the whole BDB. With that
we can make get_lvds_fp_timing() return a pointer to the copy.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Make copies of VBT data blocks

Make a copy of each VBT data block with a guaranteed minimum
size. The extra (if any) will just be left zeroed.

This means we don't have to worry about going out of bounds
when accessing any of the structure members. Otherwise that
could easliy happen if we simply get the version check wrong,
or if the VBT is broken/malicious.

v2: Don't do arithmetic between bdb header and copy
of the LFP data block (Jani)
v3: Make all the copies up front
v4: Only WARN about min_size==0 if we found the block

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

drm/i915/bios: Use the cached BDB version

We have the BDB version cached, use it. We're going to have to
start doing some of the BDB block parsing later, at which point
we may no longer have the VBT around anymore (we free it at the
end of intel_bios_init() when it didn't come via OpRegion).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220405173410.11436-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Extract struct lvds_lfp_data_ptr_table

All the LFP data table pointers have uniform layout. Turn
that into a struct.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220317171948.10400-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use DRM_MODE_FMT+DRM_MODE_ARG()

Replace all drm_mode_debug_printmodeline() calls with
DRM_MODE_FMT+DRM_MODE_ARG(). Makes the debug output a bit more
terse in places where we previously had a newline in the precedeing
drm_dbg_kms(), and avoids anything else sneaking in between the two
printk()s in all cases.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Polish drrs type enum

Make the drrs type enum less convoluted.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220310004802.16310-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Read DRRS MSA timing delay from VBT

VBT hsa a field for the MSA timing delay, which supposedly
should be used with DRRS. Extract the data from the VBT.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220310004802.16310-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: update new TMDS clock setting defined by VBT

VBT 249 update to support more TMDS clock rate 3.00G, 3.40G
and 5.94G. Refer to this new definition to configure max
TMDS clock rate for HDMI driver.

BSpec: 20124

v2: new subject

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303083802.5071-1-shawn.c.lee@intel.com

drm/i915/display/tgl+: Implement new PLL programming step

A new programming step was added to combo and TC PLL sequences.
If override_AFC_startup is set in VBT, driver should overwrite
AFC_startup value to 0x0 or 0x7 in PLL's div0 register.

The current understating is that only TGL needs this and all other
display 12 and newer platforms will have a older VBT or a newer VBT
with override_AFC_startup set to 0 but in any case there is a
drm_warn_on_once() to let us know if this is not true.

v2:
- specification updated, now AFC can be override to 0x0 or 0x7
- not using a union for div0 (Imre)
- following previous wrong vbt naming: bits instead of bytes (Imre)

BSpec: 49204
BSpec: 20122
BSpec: 49968
BSpec: 71360
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220216134059.25348-1-jose.souza@intel.com

drm/i915: Only include i915_reg.h from .c files

Several of our i915 header files, have been including i915_reg.h. This
means that any change to i915_reg.h will trigger a full rebuild of
pretty much every file of the driver, even those that don't have any
kind of register access. Let's delete the i915_reg.h include from all
headers and add an explicit include from the .c files that truly
need the register definitions; those that need a definition of
i915_reg_t for a function definition can get it from i915_reg_defs.h
instead.

We also remove two non-register #define's (VLV_DISPLAY_BASE and
GEN12_SFC_DONE_MAX) into i915_reg_defs.h to allow us to drop the
i915_reg.h include from a couple of headers.

There's probably a lot more header dependency optimization possible, but
the changes here roughly cut the number of files compiled after 'touch
i915_reg.h' in half --- a good first step.

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-7-matthew.d.roper@intel.com

drm/i915/bios: Nuke DEVICE_TYPE_DP_DUAL_MODE_BITS

Replace the DEVICE_TYPE_DP_DUAL_MODE_BITS stuff with just
a DP+HDMI check. The rest of the bits shouldn't really
matter anyway.

The slight change in behaviour here is that now we do look at
the DEVICE_TYPE_NOT_HDMI_OUTPUT bit (via
intel_bios_encoder_supports_hdmi()) when we previously ignored it.
The one platform we know that has problems with that bit is VLV.
But IIRC the problem was always that buggy VBTs basically never
set that bit. So that should be OK since all it would do is make
all DVI ports look like HDMI ports instead. Also can't imagine
there are many VLV machines with actual DVI ports in existence.

We still keep the rest of the dvo_port/aux_ch checks as we
can't trust that DP+HDMI device type equals DP++ due to
buggy VBTs.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Throw out the !has_ddi_port_info() codepaths

Now that we parse the DDI port info from the VBT on all g4x+ platforms
we can throw out all the old codepaths in intel_bios_is_port_present(),
intel_bios_is_port_edp() and intel_bios_is_port_dp_dual_mode(). None
of these should be called on pre-g4x platforms.

For good measure throw in a WARN into intel_bios_is_port_present()
should someone get the urge to call it on older platforms. The
other two functions are specific to HDMI and DP so should not need
any protection as those encoder types don't even exist on older
platforms.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Use i915->vbt.ports[] for all g4x+

Extend the vbt.ports[] stuff for all g4x+ platforms. We do need
to drop the version check as some elk/ctg machines may have VBTs
older than that. The oldest I know is an elk with version 142.
But the child device stuff has had the correct size since at
least version 125 (observed on my sdg), so from that angle this
should be totally safe.

This does couple of things:
- Start using the aux_ch/ddc_pin from VBT instead of just the
hardcoded defaults. Hopefully there are no VBTs with entirely
bogus information here.
- Start using i915->vbt.ports[] for intel_bios_is_port_dp_dual_mode().
Should be fine as the logic doesn't actually change.
- Start using i915->vbt.ports[] for intel_bios_is_port_edp().
The old codepath only looks at the DP DVO ports, the new codepath
looks at both DP and HDMI DVO ports. In principle that should not
matter. We also stop looking at some of the other device type bits
(eg. LVDS,MIPI,ANALOG,etc.). Hopefully no VBT is broken enough that
it sets up totally conflicting device type bits (eg. LVDS+eDP at the
same time). We also lose the "g4x->no eDP ever" hardcoding (shouldn't
be hard to re-introduce that into eg. sanitize_device_type() if needed).

Lightly smoke tested on a set of machines (one of ctg,ilk,snb,ivb each)
with both DP and HDMI (DP++). Everything still worked as it should.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Use i915->vbt.ports[] on CHV

CHV is currently straddling the divide by using parse_ddi_ports() stuff
for aux_ch/ddc_pin but going through all old codepaths for the rest
(intel_bios_is_port_present(), intel_bios_is_port_edp(),
intel_bios_is_port_dp_dual_mode()). Let's switch over full and use
i915->vbt.ports[] for the rest of the stuff.

dvo_port_to_port() doesn't know about DSI so we won't get into
any kind of "is port B HDMI or DSI or both?" conundrum, which
could otherwise happen on VLV/CHV due to DSI ports living in a
separate world from the other digital ports.

Including Jani's detailed analysis here for posterity:
"We stop checking for port A for CHV in intel_bios_is_port_present(), but
it's a warn and I don't recall any bug reports, so probably fine. We
could add a check in parse_ddi_port(), but meh.

Ditto for intel_bios_is_port_dp_dual_mode(), except it doesn't have a
warn.

The eDP check in intel_bios_is_port_edp() becomes slightly more
relaxed. Both the old and new check require these to be set:

- DEVICE_TYPE_DISPLAYPORT_OUTPUT
- DEVICE_TYPE_INTERNAL_CONNECTOR.

The old code also required these to be unset:

- DEVICE_TYPE_MIPI_OUTPUT
- DEVICE_TYPE_COMPOSITE_OUTPUT
- DEVICE_TYPE_DUAL_CHANNEL
- DEVICE_TYPE_LVDS_SIGNALING
- DEVICE_TYPE_TMDS_DVI_SIGNALING
- DEVICE_TYPE_VIDEO_SIGNALING
- DEVICE_TYPE_ANALOG_OUTPUT

It's possible we've added these just as a sanity check for broken VBTs
more than anything. I guess I'd see if actual problems arise.

Bottom line, I think the functional changes matter only for VBTs with
bogus data."

I agree that it should work assuming the VBT isn't totally insane.
Modern windows drivers also don't seem to check any of those
additional device type bits, which may or may not matter for older
devices (no idea what some old driver versions are checking).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/bios: Introduce has_ddi_port_info()

Pull the "do we want to use i915->vbt.ports[]?" check into
a central place.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211217155403.31477-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/dp: Move public DisplayPort headers into dp/

Move all public DisplayPort headers into dp/ and update users. No
functional changes.

v3:
* rebased onto latest drm-tip

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20220114114535.29157-5-tzimmermann@suse.de

drm/i915/psr: remove unused lines_to_wait vbt info

The lines_to_wait info from VBT is never used. Remove.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220112112715.1234366-1-jani.nikula@intel.com

drm/i915/bios: fix slab-out-of-bounds access

If VBT size is not a multiple of 4, the last 4-byte store will be out of
bounds of the allocated buffer. Spotted with KASAN. Round up the
allocation size.

v2: Use round_up() intead of roundup() as it's a power of 2 (Thomas)

Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Fixes: a36e7dc0af1c ("drm/i915/dg1: Read OPROM via SPI controller")
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211222081654.1843211-1-jani.nikula@intel.com

drm/i915/dg1: Read OPROM via SPI controller

Read OPROM SPI through MMIO and find VBT entry since we can't use
OpRegion and PCI mapping may not work on some systems due to most BIOSes
not leaving the Option ROM mapped.

v2: Remove message with allocation failure

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211216062645.3477854-1-lucas.demarchi@intel.com

drm/i915/adl_p: Add ddc pin mapping

From VBT, ddc pin info suggests the following mapping:
VBT DRIVER
DDI TC1->ddc_pin=3 should translate to PORT_TC1->0x9
DDI TC2->ddc_pin=4 should translate to PORT_TC2->0xa
DDI TC3->ddc_pin=5 should translate to PORT_TC3->0xb
DDI TC4->ddc_pin=6 should translate to PORT_TC4->0xc

Adding pin map to facilitate this translation as we cannot use existing
icl ddc pin map due to conflict with DDI C and DDI TC1 info.

Bspec:20124

v2:
- Changed Author to Tejas Upadhyay

Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Raviteja Goud Talla <ravitejax.goud.talla@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211203073720.3823371-1-ravitejax.goud.talla@intel.com

drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platforms

Looks like we never updated intel_bios_is_port_dp_dual_mode() when
the VBT port mapping became erratic on modern platforms. This
is causing us to look up the wrong child device and thus throwing
the heuristic off (ie. we might end looking at a child device for
a genuine DP++ port when we were supposed to look at one for a
native HDMI port).

Fix it up by not using the outdated port_mapping[] in
intel_bios_is_port_dp_dual_mode() and rely on
intel_bios_encoder_data_lookup() instead.

Cc: stable@vger.kernel.org
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4138
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025142147.23897-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Revert "drm/i915/bios: gracefully disable dual eDP for now"

This reverts commit 05734ca2a8f76c9eb3890b3c9dfc3467f03105c1.

It's not graceful, instead it leads to boot time warning splats in the
case it is supposed to handle gracefully. Apparently the BIOS/GOP
enabling the port we end up skipping leads to state readout
problems. Back to the drawing board.

References: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/bat-adlp-4/boot0.txt
Fixes: 05734ca2a8f7 ("drm/i915/bios: gracefully disable dual eDP for now")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211019114334.24643-1-jani.nikula@intel.com

drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platforms

Looks like we never updated intel_bios_is_port_dp_dual_mode() when
the VBT port mapping became erratic on modern platforms. This
is causing us to look up the wrong child device and thus throwing
the heuristic off (ie. we might end looking at a child device for
a genuine DP++ port when we were supposed to look at one for a
native HDMI port).

Fix it up by not using the outdated port_mapping[] in
intel_bios_is_port_dp_dual_mode() and rely on
intel_bios_encoder_data_lookup() instead.

Cc: stable@vger.kernel.org
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4138
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025142147.23897-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 32c2bc89c7420fad2959ee23ef5b6be8b05d2bde)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Revert "drm/i915/bios: gracefully disable dual eDP for now"

This reverts commit 05734ca2a8f76c9eb3890b3c9dfc3467f03105c1.

It's not graceful, instead it leads to boot time warning splats in the
case it is supposed to handle gracefully. Apparently the BIOS/GOP
enabling the port we end up skipping leads to state readout
problems. Back to the drawing board.

References: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/bat-adlp-4/boot0.txt
Fixes: 05734ca2a8f7 ("drm/i915/bios: gracefully disable dual eDP for now")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211019114334.24643-1-jani.nikula@intel.com
(cherry picked from commit 171c555c2c2664a250cd35680c34c31a6d233dc7)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/bios: gracefully disable dual eDP for now

For the time being, neither the power sequencer nor the backlight code
properly support two eDP panels simultaneously. While the software
states will be independent, the same sets of registers will be used for
both eDP panels, clobbering the hardware state and leading to errors.

Gracefully disable dual eDP until proper support has been added.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005175636.24669-1-jani.nikula@intel.com

drm/i915/bdb: Fix version check

With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
the size of bdb_lfp_backlight_data structure has been increased,
causing if-statement in the parse_lfp_backlight function
that comapres this structure size to the one retrieved from BDB,
always to fail for older revisions.
This patch calculates expected size of the structure for a given
BDB version and compares it with the value gathered from BDB.
Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)

Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+")

Tested-by: Lukasz Majczak <lma@semihalf.com>
Signed-off-by: Lukasz Majczak <lma@semihalf.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210930134606.227234-1-lma@semihalf.com

drm/i915/dsi: Retrieve max brightness level from VBT

So far, DCS backlight driver hardcode (0xFF) for max brightness level.
MIPI DCS spec allow max 0xFFFF for set_display_brightness (51h) command.
And VBT brightness precision bits can support 8 ~ 16 bits.

We should set correct precision bits in VBT that meet panel's request.
Driver can refer to this setting then configure max brightness level
in DCS backlight driver properly.

v2: modify variable name brightness_precision_bits instead of
max_brightness_level.
v3: fix checkpatch warning.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: William Tseng <william.tseng@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-5-shawn.c.lee@intel.com

drm/i915/bios: get rid of vbt ddi_port_info

We can finally remove the extra caching in ddi_port_info. Good riddance.

v2: Rebased

Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f56e864d10bb3cbe616288450d92b56325d1df12.1630512523.git.jani.nikula@intel.com

drm/i915/bios: use ddc pin directly from child data

Avoid extra caching of the data. This is slightly more subtle than one
would think. For one thing, we explicitly ignore 0 value in child device
ddc pin; this is specified as N/A and does not warrant a warning. For
another, we start looking for ddc pin collisions in sanitize using
unmapped pin numbering.

v2: Check !devdata in intel_bios_alternate_ddc_pin()

Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e1dbf7cbdd2191439e760ab9098242dcec5fbb2e.1630512523.git.jani.nikula@intel.com

drm/i915/bios: move ddc pin mapping code next to ddc pin sanitize

Move code around to avoid a forward declaration in the future.

Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8c5f723e0b2d8ffd6f47068edf710947b45843be.1630512523.git.jani.nikula@intel.com

drm/i915/bios: use alternate aux channel directly from child data

Avoid extra caching of the data.

v2: Check for !info->devdata in intel_bios_port_aux_ch() (Ankit)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b1b9f0032b353c3279b4546d6acdb696fe0b6136.1630512523.git.jani.nikula@intel.com

drm/i915/bios: use dp max link rate directly from child data

Avoid extra caching of the data.

Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5593ce81f6670dc33cf18fa284f8237c875ef404.1630512523.git.jani.nikula@intel.com

drm/i915/bios: use max tmds clock directly from child data

Avoid extra caching of the data.

Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/451082780a8befb2b27919439c901a2159ce173f.1630512523.git.jani.nikula@intel.com

drm/i915/bios: use hdmi level shift directly from child data

Avoid extra caching of the data.

Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ef22e40b01eab571ff0dc2bfffabb906d0151fb4.1630512523.git.jani.nikula@intel.com

drm/i915/bdb: Fix version check

With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
the size of bdb_lfp_backlight_data structure has been increased,
causing if-statement in the parse_lfp_backlight function
that comapres this structure size to the one retrieved from BDB,
always to fail for older revisions.
This patch calculates expected size of the structure for a given
BDB version and compares it with the value gathered from BDB.
Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)

Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+")

Tested-by: Lukasz Majczak <lma@semihalf.com>
Signed-off-by: Lukasz Majczak <lma@semihalf.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210930134606.227234-1-lma@semihalf.com
(cherry picked from commit 4378daf5d04eed59724e6d0e74755e17dce2e105)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: replace random CNL comments

Cleanup remaining cases that we find CNL in the codebase.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-22-lucas.demarchi@intel.com

drm/i915/display: remove PORT_F workaround for CNL

Explicit support for CNL is being removed from the driver as it's not
expected to work. Remove the workaround for PORT_F from
display/intel_bios.c so we can also remove the generic DISPLAY_VER == 10
calls to intel_ddi_init(): the only platform with that display version
is already handled separately (GLK).

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-2-lucas.demarchi@intel.com

drm/i915/bios: Fix ports mask

PORT_A to PORT_F are regular integers defined in the enum port,
while for_each_port_masked requires a bit mask for the ports.

Current given mask: 0b111
Desired mask: 0b111111

I noticed this while Christoph was reporting a bug found on headless
GVT configuration which bisect blamed commit 3ae04c0c7e63 ("drm/i915/bios:
limit default outputs to ports A through F")

v2: Avoid unnecessary line continuations as pointed by CI and Christoph

Cc: Christoph Hellwig <hch@infradead.org>
Fixes: 3ae04c0c7e63 ("drm/i915/bios: limit default outputs to ports A through F")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Tested-by: Christoph Hellwig <hch@infradead.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210723095225.562913-1-rodrigo.vivi@intel.com

drm/i915/bios: Fix ports mask

PORT_A to PORT_F are regular integers defined in the enum port,
while for_each_port_masked requires a bit mask for the ports.

Current given mask: 0b111
Desired mask: 0b111111

I noticed this while Christoph was reporting a bug found on headless
GVT configuration which bisect blamed commit 3ae04c0c7e63 ("drm/i915/bios:
limit default outputs to ports A through F")

v2: Avoid unnecessary line continuations as pointed by CI and Christoph

Cc: Christoph Hellwig <hch@infradead.org>
Fixes: 3ae04c0c7e63 ("drm/i915/bios: limit default outputs to ports A through F")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Tested-by: Christoph Hellwig <hch@infradead.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210723095225.562913-1-rodrigo.vivi@intel.com
(cherry picked from commit 9b52aa720168859526bf90d77fa210fc0336f170)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915/xelpd: Provide port/phy mapping for vbt

This will allow proper DDI initialization based on vbt information.

Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210514153711.2359617-7-matthew.d.roper@intel.com

drm/i915/xelpd: Handle new location of outputs D and E

The DDI naming template for display version 12 went A-C, TC1-TC6. With
XE_LPD, that naming scheme for DDI's has now changed to A-E, TC1-TC4.

The XE_LPD design keeps the register offsets and bitfields relating to
the TC outputs in the same location they were previously. The new "D"
and "E" outputs now take the locations that were previously used by TC5
and TC6 outputs, or what we would have considered to be outputs "H" and
"I" under the legacy lettering scheme.

For the most part everything will just work as long as we initialize the
output with the proper 'enum port' value. However we do need to take
care to pick the correct AUX channel when parsing the VBT (e.g., a
reference to 'AUX D' is actually asking us to use the 8th aux channel,
not the fourth). We should also make sure that our encoders and aux
channels are named appropriately so that it's easier to correlate driver
debug messages with the bspec instructions.

v2:
- Update handling of TGL_TRANS_CLK_SEL_PORT. (Jose)

v3:
- Add hpd_pin to handle outputs D and E (Jose)
- Fixed conversion of BIOS port to aux ch for TC ports (Jose)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210514153711.2359617-2-matthew.d.roper@intel.com

drm/i915/adl_p: Add PCH support

Add ADP-P PCH device ID and assign as ADL PCH if found. Previously we
would assign the DDC pin map based on the PCH, but it can also change
based on the CPU. From Bspec 20124: "The physical port to pin pair
mapping are defined in the Bspec per PCH. Mapping can further change
based on CPU Si used as CPU and PCH can be mixed and matched".

Bspec: 20124
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210512042144.2089071-7-matthew.d.roper@intel.com

drm/i915/display: hide workaround for broken vbt in intel_bios.c

Instead of poluting the normal code path in intel_display.c, make
intel_bios.c handle the brokenness of the VBT.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-5-lucas.demarchi@intel.com

drm/i915/display: rename display version macros

While converting the rest of the driver to use GRAPHICS_VER() and
MEDIA_VER(), following what was done for display, some discussions went
back on what we did for display:

1) Why is the == comparison special that deserves a separate
macro instead of just getting the version and comparing directly
like is done for >, >=, <=?

2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for
brevity. If we remove the current users of IS_DISPLAY_VER(), we
could actually repurpose it for a range check

With (1) there could be an advantage if we used gen_mask since multiple
conditionals be combined by the compiler in a single and instruction and
check the result. However a) INTEL_GEN() doesn't use the mask since it
would make the code bigger everywhere else and b) in the cases it made
sense, it also made sense to convert to the _RANGE() variant.

So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range
like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER()
users to use == and != operators. Aside from the definition changes,
this was done by the following semantic patch:

@@ expression dev_priv, E1; @@
- !IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) != E1

@@ expression dev_priv, E1; @@
- IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) == E1

@@ expression dev_priv, from, until; @@
- IS_DISPLAY_RANGE(dev_priv, from, until)
+ IS_DISPLAY_VER(dev_priv, from, until)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor conflict resolve while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com

drm/i915/display: Eliminate IS_GEN9_{BC,LP}

Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the
display code, we should also kill off our use of the IS_GEN9_* macros
too. We'll do the conversion manually this time instead of using
Coccinelle since the most logical substitution can depend heavily on the
code context, and sometimes we can keep the code simpler if we make
additional adjustments such as swapping the order of if/else arms.

v2:
- Restore a lost negation in intel_pll_is_valid().

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com
(cherry picked from commit 70bfb30743d5da73058b0a2271e9c127a84fb494)
[Jani: cherry picked to topic branch to reduce conflicts]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: Eliminate IS_GEN9_{BC,LP}

Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the
display code, we should also kill off our use of the IS_GEN9_* macros
too. We'll do the conversion manually this time instead of using
Coccinelle since the most logical substitution can depend heavily on the
code context, and sometimes we can keep the code simpler if we make
additional adjustments such as swapping the order of if/else arms.

v2:
- Restore a lost negation in intel_pll_is_valid().

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com

drm/i915/display: Simplify GLK display version tests

GLK has always been a bit of a special case since it reports INTEL_GEN()
as 9, but has version 10 display IP. Now we can properly represent the
display version as 10 and simplify the display generation tests
throughout the display code.

Aside from manually adding the version to the glk_info structure, the
rest of this patch is generated with a Coccinelle semantic patch. Note
that we also need to switch any code that matches gen10 today but *not*
GLK to be CNL-specific:

@@ expression dev_priv; @@
- DISPLAY_VER(dev_priv) > 9
+ DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
(
- DISPLAY_VER(dev_priv) >= 10 && E
+ (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E
|
- DISPLAY_VER(dev_priv) >= 10
+ DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
|
- IS_DISPLAY_RANGE(dev_priv, 10, E)
+ IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv)
)

@@ expression dev_priv, E, E2; @@
(
- (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv)
+ E || IS_DISPLAY_VER(dev_priv, 10)
|
- E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv)
+ E || E2 || IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 10)
|
- (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_VER(dev_priv, 10)
)

@@ expression dev_priv; @@
- (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv))
+ IS_DISPLAY_VER(dev_priv, 9)

@@ expression dev_priv; @@
(
- !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) < 10
|
- (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10))
+ DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)
+ E || DISPLAY_VER(dev_priv) >= 10

@@ expression dev_priv, E; @@
- (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10))
+ IS_DISPLAY_RANGE(dev_priv, 10, E)

@@ expression dev_priv; @@
(
- DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || IS_GEN9_LP(dev_priv)
+ DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv)
|
- IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)
+ IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10
)

@@ expression dev_priv, E; @@
- !(DISPLAY_VER(dev_priv) >= E)
+ DISPLAY_VER(dev_priv) < E

v2:
- Convert gen10 conditions that don't include GLK into CNL conditions.
(Ville)

v3:
- Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." (Ville)

v3.1:
- Manually re-add the ".display.version = 10" to glk_info after
regenerating patch via Coccinelle.

v4:
- Also apply cocci rules to intel_pm.c and i915_irq.c! (CI)

Cc: Ville Syrjälä <ville.syrjala@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210322233840.4056851-1-matthew.d.roper@intel.com

drm/i915/display: Eliminate most usage of INTEL_GEN()

Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN()
in the display code to use DISPLAY_VER() comparisons instead. The
following semantic patch was used:

@@ expression dev_priv, E; @@
- INTEL_GEN(dev_priv) == E
+ IS_DISPLAY_VER(dev_priv, E)

@@ expression dev_priv; @@
- INTEL_GEN(dev_priv)
+ DISPLAY_VER(dev_priv)

@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ IS_DISPLAY_VER(dev_priv, E)

@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_DISPLAY_RANGE(dev_priv, from, until)

There are still some display-related uses of INTEL_GEN() in intel_pm.c
(watermark code) and i915_irq.c. Those will be updated separately.

v2:
- Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com

drm/i915/bios: add intel_bios_encoder_data to encoder, use for iboost

Add intel_bios_encoder_data pointer to encoder, and use it for hdmi and
dp iboost. For starters, we only set the encoder->devdata for DDI
encoders, i.e. we can only use it for data that is used by DDI encoders.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4bc49244ce68e136e5b21db4c4e6554bec9ac0fb.1615998927.git.jani.nikula@intel.com

drm/i915/bios: start using intel_bios_encoder_data for Type-C USB and TBT

Stop caching the information in ddi_port_info. We're phasing out
ddi_port_info usage completely, and prefer using the VBT child device
information directly using the provided helpers.

v2:
- Remove supports_typec_usb & supports_tbt from ddi_vbt_port_info (Lucas)

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b04bd183e7554aeb4bc3962af90d63171aa32fc2.1615998927.git.jani.nikula@intel.com

drm/i915/bios: start using the intel_bios_encoder_data directly

Start using struct intel_bios_encoder_data directly. We'll start
sanitizing the child device data directly as well, instead of the cached
data in ddi_port_info[]. The one downside here is having to store a
non-const pointer back to intel_bios_encoder_data.

Eventually we'll be able to have a direct pointer from encoder to
intel_bios_encoder_data, removing the need to go through the
ddi_port_info[] array altogether. And we'll be able to remove all the
cached data in ddi_port_info[].

v2:
- Remove supports_dp and supports_edp from ddi_port_info too
- Add devdata != NULL check in intel_bios_is_port_edp()

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> # v1
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/061df32a012ff640060920fcd730fb23f8717ee8.1615998927.git.jani.nikula@intel.com

drm/i915/bios: save a higher level pointer in ddi_vbt_port_info[]

We'll be needing the intel_bios_encoder_data pointer going forward, and
it's just easier to store the higher level pointer in the
ddi_vbt_port_info[] array.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/89717516e99afccfecf1a7c6c938b8349f65e985.1615998927.git.jani.nikula@intel.com

drm/i915/bios: add helper functions to check output support

These will be exposed to the rest of the driver and replace other
functions. Everything will operate on the child devices.

v2:
- Rebased, removed stray blank line
- Also abstracted intel_bios_encoder_supports_crt (Lucas)

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2bd40ccc093796d16300742d1789d78ffac3c450.1615998927.git.jani.nikula@intel.com

drm/i915/bios: add i915 backpointer to intel_bios_encoder_data

We'll be needing it in the future.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/026b737b122273d256f4247e9b0c84529aa391fd.1615998927.git.jani.nikula@intel.com

drm/i915/bios: rename display_device_data to intel_bios_encoder_data

Make the naming suitable for exposing to the rest of the driver as an
opaque type. No functional changes.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cb97c858de6e6afa96092db6d96e685fda006984.1615998927.git.jani.nikula@intel.com

drm/i915/bios: create fake child devices on missing VBT

Instead of initialing data directly in ddi_port_info array, create fake
child devices for default outputs when the VBT is missing. This makes
further unification of output handling easier.

This will make intel_bios_is_port_present() return true for the fake
child devices. This may cause subtle changes in a handful of places.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/91675b40a78bd04bf138598d979661257181880d.1615998927.git.jani.nikula@intel.com

drm/i915/bios: limit default outputs to ports A through F

There are two main cases where the default outputs are useful when the
VBT is missing:

- There are some DDI-platform Chromebooks out there that do not have a
VBT, which worked by coincidence because of the default outputs. The
machines need to continue to work.

- Early platform enabling when the VBT might not be available. (This
could be circumvented by using the i915.vbt_firmware parameter.)

Prepare for generating fake child devices for the default outputs by
limiting the number of outputs. We don't want to generate excessive
amounts of fake child devices. This could be perhaps be limited even
more in the future, but match what's possible on all DDI platforms.

Note that limiting the defaults to non-TypeC ports in commit
828ccb31cf41 ("drm/i915/icl: Add TypeC ports only if VBT is present") is
a more strict limit, and makes this a no-op on recent platforms.

v2: Rewrote commit message

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5c9c9743af1c7265a2c976d582b7a6685ec0c414.1615998927.git.jani.nikula@intel.com

drm/i915/bios: limit default outputs by platform on missing VBT

Pre-DDI and non-CHV aren't using the information created here anyway, so
don't bother setting the defaults for them. This should be a
non-functional change, but is separated here to catch any regressions in
a single commit.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/41526a4eee5fb0de8d7f1ffe4c09965b63ccbaa8.1615998927.git.jani.nikula@intel.com

drm/i915/bios: move aux ch and ddc checks at a lower level

Unify the code paths at the higher level.

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/44559ef456015f65a863c3d89a9bea9157d13a05.1615998927.git.jani.nikula@intel.com

drm/i915/bios: reduce indent in sanitize_ddc_pin and sanitize_aux_ch

Reduce indent with an early return. No functional changes.

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: fixed a couple of comment typos while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/17288137452f731a820e737582672f836660a26f.1615998927.git.jani.nikula@intel.com

drm/i915/bios: store bdb version in i915

We'll be needing the version in more places in the future, so avoid the
need to pass it around. No functional changes.

v2: Rebased

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> # v1
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c2a4189241bf0946d27e12804b1ba7d098c7d483.1615998927.git.jani.nikula@intel.com

drm/i915/bios: mass convert dev_priv to i915

Time to just yank out the bandage. No functional changes.

v2: Rebased

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> # v1
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/93fe9e8be2e6120b085d09e49aafdf52f5ccd725.1615998927.git.jani.nikula@intel.com

drm/i915/vbt: update DP max link rate table

According to Bspec #20124, max link rate table for DP was updated
at BDB version 230. Max link rate can support upto UHBR.

After migrate to BDB v230, the definition for LBR, HBR2 and HBR3
were changed. For backward compatibility. If BDB version was
from 216 to 229. Driver have to follow original rule to configure
DP max link rate value from VBT.

v2: split the mapping table to two for old and new BDB definition.
v3: return link rate instead of assigning it.
v4: remove the useless variable.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: William Tseng <william.tseng@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
[vsyrjala: Try to retain the comment that VBT version 216 added some of this]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210218052333.16109-1-shawn.c.lee@intel.com

drm/i915/gen9_bc: Introduce TGP PCH DDC pin mappings

With the introduction of gen9_bc, where Intel combines Cometlake CPUs with
a Tigerpoint PCH, we'll need to introduce new DDC pin mappings for this
platform in order to make all of the display connectors work. So, let's do
that.

Changes since v4:
* Split this into it's own patch - vsyrjala
Changes since v5:
* Rename gen9bc_port_to_ddc_pin() to gen9bc_tgp_port_to_ddc_pin()

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209212832.1401815-3-lyude@redhat.com

drm/i915/display: Handle lane polarity for DDI port

Lane Reversal is required for some of the DDI ports. This information
is populated in VBT and driver should read the same and set the
polarity while enabling the port. This patch handles the same.

It helps fix a display blankout issue on DP ports on certain
platforms.

Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210211114209.23866-1-uma.shankar@intel.com

drm/i915: Remove references to struct drm_device.pdev

Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.

v6:
* also remove assignment in selftests/ in a later patch (Chris)
v5:
* remove assignment in later patch (Chris)
v3:
* rebased
v2:
* move gt/ and gvt/ changes into separate patches

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210128133127.2311-2-tzimmermann@suse.de

drm/i915/bios: tidy up child device debug logging

Make the child device details easier to read by turning this:

[drm:parse_ddi_port [i915]] Port B VBT info: CRT:0 DVI:1 HDMI:1 DP:0 eDP:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0
[drm:parse_ddi_port [i915]] VBT HDMI level shift for port B: 8
[drm:parse_ddi_port [i915]] VBT DP max link rate for port B: 810000
[drm:parse_ddi_port [i915]] Port C VBT info: CRT:0 DVI:1 HDMI:1 DP:1 eDP:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0
[drm:parse_ddi_port [i915]] VBT HDMI level shift for port C: 8
[drm:parse_ddi_port [i915]] VBT (e)DP boost level for port C: 3
[drm:parse_ddi_port [i915]] VBT HDMI boost level for port C: 1
[drm:parse_ddi_port [i915]] VBT DP max link rate for port C: 810000

into this:

[drm:parse_ddi_port [i915]] Port B VBT info: CRT:0 DVI:1 HDMI:1 DP:0 eDP:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0
[drm:parse_ddi_port [i915]] Port B VBT HDMI level shift: 8
[drm:parse_ddi_port [i915]] Port B VBT DP max link rate: 810000
[drm:parse_ddi_port [i915]] Port C VBT info: CRT:0 DVI:1 HDMI:1 DP:1 eDP:0 LSPCON:0 USB-Type-C:0 TBT:0 DSC:0
[drm:parse_ddi_port [i915]] Port C VBT HDMI level shift: 8
[drm:parse_ddi_port [i915]] Port C VBT (e)DP boost level: 3
[drm:parse_ddi_port [i915]] Port C VBT HDMI boost level: 1
[drm:parse_ddi_port [i915]] Port C VBT DP max link rate: 810000

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

drm/i915/adl_s: Add vbt port and aux channel settings for adls

- ADL-S driver internal mapping uses PORT D, E, F, G for Combo phy B, C,
D and E.
- Add ADLS specific port mappings for vbt port dvo settings.
- Select appropriate AUX CH specific to ADLS based on port mapping.

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-10-aditya.swarup@intel.com

drm/i915/adl_s: Add adl-s ddc pin mapping

ADL-S requires TC pins to set up ddc for Combo PHY B, C, D and E.
Combo PHY A still uses the old ddc pin mapping.

From VBT, ddc pin info suggests the following mapping:
VBT DRIVER
DDI B->ddc_pin=2 should translate to PORT_D->0x9
DDI C->ddc_pin=3 should translate to PORT_E->0xa
DDI D->ddc_pin=4 should translate to PORT_F->0xb
DDI E->ddc_pin=5 should translate to PORT_G->0xc

Adding pin map to facilitate this translation as we cannot use existing
icl ddc pin map due to conflict with DDI B and DDI C info.

Bspec:20124

v2: Replace IS_ALDERLAKE_S() with HAS_PCH_ADP() as the pin map pairing
depends on the PCH being used rather than the platform.(mdroper)

v3:
- Modify adls_port_to_ddc_pin() to make PHY_A the special case for
check, else return pin mapping based on correct arithmetic with phy
offset. Remove redundant platform checks and use HAS_PCH_ADP() instead
of IS_ALDERLAKE_S() in intel_hdmi_ddc_pin().(mdroper)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-9-aditya.swarup@intel.com

drm/i915/rkl: new rkl ddc map for different PCH

After boot into kernel. Driver configured ddc pin mapping based on
predefined table in parse_ddi_port(). Now driver configure rkl
ddc pin mapping depends on icp_ddc_pin_map[]. Then this table will
give incorrect gmbus port number to cause HDMI can't work.

Refer to commit cd0a89527d06 ("drm/i915/rkl: Add DDC pin mapping").
Create two ddc pin table for rkl TGP and CMP pch. Then HDMI can
works properly on rkl.

v2: update patch based on latest dinq branch.
v3: update ddc table for RKL+TGP sku.
RKL+CNP sku will load cnp_ddc_pin_map[] setting.
v4: modify the if/else judgment to avoid nesting.
v5: fix typo in v4.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2577
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117142629.28729-1-shawn.c.lee@intel.com

drm/i915/bios: fill in DSC rc_model_size from VBT

The VBT fields match the DPCD data, so use the same helper.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/43fba75d89525413aed0bdbb082c26b09458bd46.1607429866.git.jani.nikula@intel.com

drm/i915: Use AUX_CH_USBCn for the RKL VBT AUX CH setup

As with the VBT DVO port, RKL uses PHY based mapping for the
VBT AUX CH. Adjust the code to use the new AUX_USBCn names
and add a comment to explain the situation.

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-7-ville.syrjala@linux.intel.com

drm/i915: Add PORT_TCn aliases to enum port

Since tgl the DDIs have been named A,B,C,TC1,TC2,TC3...
Add the appropriate enum values for the TC DDIs to enum port.

v2: Deal with rkl and dg1

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-3-ville.syrjala@linux.intel.com

drm/i915/vbt: Update the version and expected size of BDB_GENERAL_DEFINITIONS map

This will remove the "Expected child device config size for VBT
version 235 not known" debug message seen in TGL, although this is not
fixing anything it good to keep our VBT parser updated.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008211932.24989-2-jose.souza@intel.com

drm/i915/vbt: Fix backlight parsing for VBT 234+

Child min_brightness is obsolete from VBT 234+, instead the new
min_brightness field in the main structure should be used.

This new field is 16 bits wide, so backlight_precision_bits is needed
to check if value needs to be scaled down but it is only available in
VBT 236+ so working around it by using the also new backlight_level
in the main struct.

v2:
- missed that backlight_data->level is also obsolete

v3:
- s/backlight/brightness to better match specification
- using u16 to specify brightness level instead of a u32 : 16

BSpec: 20149
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008211932.24989-1-jose.souza@intel.com

drm/i915/dg1: provide port/phy mapping for vbt

As with RKL, DG1's VBT outputs are indexed according to PHY rather than
DDI.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-8-lucas.demarchi@intel.com

drm/i915/dg1: gmbus pin mapping

Add tables to map the GMBUS pin pairs to GPIO registers and port to DDC.
From spec we have registers GPIO_CTL[1-4], so we should not do the 4->9
mapping as in ICL/TGL.

The values for VBT seem wrong in BSpec. For the current boards we
actually have a 1:1 mapping.

BSpec: 49311, 49945, 20124

Cc: Aditya Swarup <aditya.swarup@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007002210.3678024-5-lucas.demarchi@intel.com

drm/i915: Add VBT AUX CH H and I

As with everything else VBT can now specify AUX CH H or I.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-6-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Add VBT DVO ports H and I

VBT has ports H and I since version 217.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-5-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Reduce INTEL_DISPLAY_ENABLED to just removing the outputs

Having a mode where the display hardware is present but we try
to pretend it isn't just leads to massive headaches when trying
to reason what the fallout might be from skipping some random
bits of programming.

Let's just neuter INTEL_DISPLAY_ENABLED so that we treat the
hardware as fully present, except we just don't register any
outputs. That's still rather sketchy if the outputs are already
enabled when the driver is loaded. I think the simplest solution
would be to probe everything as normal and just return
disconnected" from all .detect() hooks. That would avoid anything
automagically enabling those outputs, but the driver could then
shut things down using the normal codepaths.

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

treewide: Use fallthrough pseudo-keyword

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>

drm/i915/bios: Parse HOBL parameter

HOBL means hours of battery life, it is a power-saving feature
were supported motherboards can use a special voltage swing table
that uses less power.

So here parsing the VBT to check if this feature is supported.

BSpec: 20150
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708205512.21625-3-jose.souza@intel.com

drm/i915/params: switch to device specific parameters

Start using device specific parameters instead of module parameters for
most things. The module parameters become the immutable initial values
for i915 parameters. The device specific parameters in i915->params
start life as a copy of i915_modparams. Any later changes are only
reflected in the debugfs.

The stragglers are:

* i915.force_probe and i915.modeset. Needed before dev_priv is
available. This is fine because the parameters are read-only and never
modified.

* i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and
I915_STATE_WARN_ON would result in massive and ugly churn. This is
handled by not exposing the parameter via debugfs, and leaving the
parameter writable in sysfs. This may be fixed up in follow-up work.

* i915.inject_probe_failure. Only makes sense in terms of the module,
not the device. This is handled by not exposing the parameter via
debugfs.

v2: Fix uc i915 lookup code (Michał Winiarski)

Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com

drm/i915: Restore DP-E to VBT mapping table

We accidentally dropped matching for DVO_PORT_DPE from the VBT mapping
table when we refactored the function. Restore it.

Fixes: 4628142aeccc ("drm/i915/rkl: provide port/phy mapping for vbt")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200606031803.3309624-1-matthew.d.roper@intel.com

drm/i915/rkl: provide port/phy mapping for vbt

RKL uses the DDI A, DDI B, DDI USBC1, DDI USBC2 from the DE point of
view, so all DDI/pipe/transcoder register use these indexes to refer to
them. Combo phy and IO functions follow another namespace that we keep
as "enum phy". The VBT in theory would use the DE point of view, but
that does not happen in practice.

Provide a table to convert the child devices to the "correct" port
numbering we use. Now this is the output we get while reading the VBT:

DDIA:
[drm:intel_bios_port_aux_ch [i915]] using AUX A for port A (VBT)
[drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:275:DDI A]
[drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:275:DDI A]
[drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x1 for port A (VBT)

DDIB:
[drm:intel_bios_port_aux_ch [i915]] using AUX B for port B (platform default)
[drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:291:DDI B]
[drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x2 for port B (VBT)

DDI USBC1:
[drm:intel_bios_port_aux_ch [i915]] using AUX D for port D (VBT)
[drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:295:DDI D]
[drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:295:DDI D]
[drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x3 for port D (VBT)

DDI USBC2:
[drm:intel_bios_port_aux_ch [i915]] using AUX E for port E (VBT)
[drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:306:DDI E]
[drm:intel_hdmi_init_connector [i915]] Adding HDMI connector on [ENCODER:306:DDI E]
[drm:intel_hdmi_init_connector [i915]] Using DDC pin 0x9 for port E (VBT)

Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-7-matthew.d.roper@intel.com

drm/i915: significantly reduce the use of <drm/i915_drm.h>

The #include has been splattered all over the place, but there are
precious few places, all .c files, that actually need it.

v2: remove leftover double newlines

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225133131.3301-1-jani.nikula@intel.com

drm/i915/bios: Fix the timing parameters

Fix htotal and vtotal parameters derived from DTD block of VBT. The
values miss the back porch.

Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124125829.16973-1-vandita.kulkarni@intel.com
(cherry picked from commit ad278f358446707d03a1fe89f880e6ac80ca06cd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: Make WARN* drm specific where drm_device ptr is available

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}

@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}

@rule3@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-20-pankaj.laxminarayan.bharadiya@intel.com

drm/i915/bios: Fix the timing parameters

Fix htotal and vtotal parameters derived from DTD block of VBT. The
values miss the back porch.

Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124125829.16973-1-vandita.kulkarni@intel.com

drm/i915/bios: convert to struct drm_device logging macros.

This replaces the printk based logging macros with the struct drm_device
based logging macros.
This conversion was achieved using the following coccinelle script that
transforms based on the existence of a struct drm_i915_private device:
@rule1@
identifier fn, T;
@@

fn(struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
)
...+>
}

@rule2@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
)
...+>
}

Formatting warnings by checkpatch are addressed manually.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121134559.17355-3-wambui.karugax@gmail.com

drm/i915/bios: check DDI port presence based on child device

Report port presence based on port presence in VBT alone, relaxing the
requirements on supported encoders (DP, DVI, or HDMI). The goal is to
make future changes easier, however there is a small risk of reporting
more ports present than before in case of dubious VBT.

Regarding the current callers of intel_bios_is_port_present(), the
potential issue might be caused by DVO_PORT_CRT being identified as port
E in dvo_port_to_port(). Hopefully no VBT has that on SKL+ which support
DP/DVI/HDMI on port E; the current CRT init code on HSW/BDW does not
care.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4338a29e4ed49e69f859dff1490fd85f6ae6177e.1579270868.git.jani.nikula@intel.com

drm/i915/bios: add intel_bios_port_supports_*()

Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/21549ff74e8e5746917b0e2be4afbfb141e26657.1579270868.git.jani.nikula@intel.com

drm/i915/bios: add intel_bios_alternate_ddc_pin()

Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9e4fcb625cec26ee88245aad7ae80bfe93b14e59.1579270868.git.jani.nikula@intel.com

drm/i915/bios: add intel_bios_dp_max_link_rate()

Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8c30e1183afdd469c95b01f64ca0458b9e832404.1579270868.git.jani.nikula@intel.com

drm/i915/bios: intel_bios_hdmi_boost_level()

Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6d61a5bc60c995d2ee812ef61d3c5c93b61453e7.1579270868.git.jani.nikula@intel.com

drm/i915/bios: intel_bios_dp_boost_level()

Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fb8645cecadbc4ebeea1c0de94cb3116a769d9bf.1579270868.git.jani.nikula@intel.com

drm/i915/bios: add intel_bios_hdmi_level_shift()

Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/da8ca144020fe165af33992661568d0586a2fdeb.1579270868.git.jani.nikula@intel.com

drm/i915/bios: add intel_bios_max_tmds_encoder()

Don't access i915->vbt.ddi_port_info[] directly.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c52c39df43374b51f56439daf8047079afae7749.1579270868.git.jani.nikula@intel.com

drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER

Renaming to match the BSpec and struct name.

BSpec: 20150
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110235045.176640-1-jose.souza@intel.com

drm/i915/bios: remove extra debug messages

Just like in commit 523e0cc89b83 ("drm/i915/tgl: allow DVI/HDMI on port
A"), the port checks when reading the VBT can easily not match what the
platform really exposes. However here we only have some additional debug
messages that are not adding much value: in the previous debug message
we already print everything we know about the VBT.

Instead of keep fixing the possible port assignments according to the
platform, just nuke the additional messages.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206190552.8818-1-lucas.demarchi@intel.com

drm/i915/bios: fix off by one in parse_generic_dtd()

The "num_dtd" variable is the number of elements in the
generic_dtd->dtd[] array so the > needs to be >= to prevent reading one
element beyond the end of the array.

Fixes: 33ef6d4fd8df ("drm/i915/vbt: Handle generic DTD block")
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191212091130.zf2g53njf5u24wk6@kili.mountain

drm/i915/bios: add support for querying DSC details for encoder

Add function for retrieving the DSC data for an encoder.

Initially, this is DSI specific, as DP does not use VBT settings for DSC
at all. It's also not very pretty.

In the future we might have a pointer from encoder to the child device,
which would make the child device list query here so much more sensible.

v3:
- use crtc_state instead of pipe_config
- return true by default from intel_bios_get_dsc_params()
- expand the comment about rc_buffer_block_size and rc_buffer_size

v2:
- make more robust, debug log errors better

Bspec: 29885
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b895c349d964d70e4cad26f12a629ea1898bfcc2.1575974743.git.jani.nikula@intel.com

drm/i915/bios: parse compression parameters block

Check for child devices that specify compression, and store the device
specific compression parameters in the display device data struct for
later use. Warn if compression is requested but not available.

Use fairly rigid checks for compression data for starters. These can be
made more dynamic later.

Log about DSC presence in DDI port parse, though this is not universal
across platforms or port types (DSI).

v2: amended debug logging

Bspec: 29885
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/357d685ba047faf2285138c2f7014a8dee9a12b7.1575974743.git.jani.nikula@intel.com

drm/i915/bios: pass devdata to parse_ddi_port

Allow accessing the parent structure later on. Drop const for allowing
future modification as well.

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3318b09aaccbbe141e233ca510d581b421259a2a.1575974743.git.jani.nikula@intel.com

drm/i915/bios: assume vbt is 4-byte aligned into oprom

The unaligned ioread32() will make us read byte by byte looking for the
vbt. We could just as well have done a ioread8() + a shift and avoid the
extra confusion on how we are looking for "$VBT".

However when using ACPI it's guaranteed the VBT is 4-byte aligned
per spec, so we can probably assume it here as well.

v2: do not try to simplify the loop by eliminating the auxiliary counter
(Jani and Ville)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-4-lucas.demarchi@intel.com

drm/i915/bios: fold pci rom map/unmap into copy function

We don't need to keep the pci rom mapped during the entire
intel_bios_init() anymore. Move it to the previous copy_vbt() function
and rename it to oprom_get_vbt() since now it's responsible to to all
operations related to get the vbt from the oprom.

v2: fix double __iomem attribute detected by sparse
v3: fix missing unmap on success (Ville)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-3-lucas.demarchi@intel.com

drm/i915/bios: do not discard address space

When we map the VBT through pci_map_rom() we may not be allowed
to simply discard the address space and go on reading the memory.
That doesn't work on my test system, but by dumping the rom via
sysfs I can can get the correct vbt. So change our find_vbt() to do
the same as done by pci_read_rom(), i.e. use memcpy_fromio().

v2: the just the minimal changes by not bothering with the unaligned io
reads: this can be done on top (from Ville and Jani)

v3: drop const in function return since now we are copying the vbt,
rather than just finding it

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-2-lucas.demarchi@intel.com

drm/i915/vbt: Parse power conservation features block

From VBT 228+ this is block that PSR and other power saving
features configuration should be read from.

v3:
Using DRRS from this new block

v4:
Using BIT()
Fixing DRRS comment in parse_power_conservation_features()

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-5-jose.souza@intel.com

drm/i915/vbt: Handle generic DTD block

VBT revision 229 adds a new "Generic DTD" block 58 and deprecates the
old LFP panel mode data in block 42. Let's start parsing this block to
fill in the panel fixed mode on devices with a >=229 VBT.

v2:
* Update according to the recent updates:
- DTD size is now 16 bits instead of 24
- polarity is now just a single bit for hsync and vsync and is
properly documented
* Minor checkpatch fix

v3:
* Now that panel options are parsed separately from the previous patch,
move generic DTD parsing into a function parallel to
parse_lfp_panel_dtd. We'll still fall back to looking at the legacy
LVDS timing block if the generic DTD fails. (Jani)
* Don't forget to actually set lfp_lvds_vbt_mode! (Jani)
* Drop "bdb_" prefix from dtd entry structure. (Jani)
* Follow C99 standard for structure's flexible array member. (Jani)

v4:
* Add "positive" to polarity field names for clarity. (Jani)
* Move VBT version check and fallback to legacy DTD parsing logic to a
helper to keep top-level VBT parsing uncluttered. (Jani)
* Restructure reserved bit packing at end of generic_dtd_entry from
"u32 rsvd:24" to "u8 rsvd[3]" to prevent copy/paste mistakes in the
future. (Jani)

Bspec: 54751
Bspec: 20148
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-3-matthew.d.roper@intel.com

drm/i915/vbt: Parse panel options separately from timing data

Newer VBT versions will add an alternate way to read panel DTD
information, so let's split parsing of the general panel information
from the timing data in preparation.

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jesse Barnes <jsbarnes@google.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-2-matthew.d.roper@intel.com

drm/i915/tgl: allow DVI/HDMI on port A

Tiger Lake supports HDMI on port A. For other platforms we ignore what
the VBT says regarding HDMI to workaround broken VBTs, see
commit 2ba7d7e04371 ("drm/i915/bios: ignore HDMI on port A"). Make this
apply gen12+ so they inherit the TGL behavior.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113021935.41547-1-lucas.demarchi@intel.com

drm/i915/bios: make sure to check vbt size

When we call intel_bios_is_valid_vbt(), size may not actually be the
size of the VBT, but rather the size of the blob the VBT is contained
in. For example, when mapping the PCI oprom, size will be the entire
oprom size. We don't want to read beyond what is reported to be the
VBT. So make sure we vbt->vbt_size makes sense and use that for
the latter checks.

v2: check for vbt_size after checking for vbt signature and give it a
more meaningful error message (from Jani)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-3-lucas.demarchi@intel.com

drm/i915/bios: rename bios to oprom when mapping pci rom

oprom is actually a better name to use when using
pci_map_rom(). "bios" is way too generic and confusing.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-2-lucas.demarchi@intel.com

drm/i915/bios: store child devices in a list

Using the array is getting clumsy. Make things a bit more dynamic.

Remove early returns on not having child devices when the end result
after "iterating" the empty list would be the same.

v3:
- use list_add_tail to not reverse the child device list (Ville)

v2:
- stick to previous naming of child devices (Ville)
- use kzalloc, handle failure
- initialize list head earlier to keep intel_bios_driver_remove() safe

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3e72da0b412354ed8be6719df55b0e0cc4caa61a.1573227240.git.jani.nikula@intel.com

drm/i915/bios: use a flag for vbt hdmi level shift presence

The pre-initialized magic value is a bit silly, switch to a flag
instead.

v2: Reduce paranoia to a single sanity check (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/74fe24ab6d5f0ea2ff2059cdf044d6d3006080fc.1573227240.git.jani.nikula@intel.com

drm/i915: add for_each_port() and use it

Add another for_each style macro to the pile of custom looping macros.

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

drm/i915/tgl: Enable DDI/Port G

In TGL there we are missing the initialization of port G.
Do the same as for other ports.

Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008220905.18278-1-khaled.almahallawy@intel.com

drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin

The first come first served apporoach to handling the VBT
child device AUX ch conflicts has backfired. We have machines
in the wild where the VBT specifies both port A eDP and
port E DP (in that order) with port E being the real one.

So let's try to flip the preference around and let the last
child device win once again.

Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: Masami Ichikawa <masami256@gmail.com>
Tested-by: Torsten <freedesktop201910@liggy.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966
Fixes: 36a0f92020dc ("drm/i915/bios: make child device order the priority order")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011202030.8829-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 41e35ffb380bde1379e4030bb5b2ac824d5139cf)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin

The first come first served apporoach to handling the VBT
child device AUX ch conflicts has backfired. We have machines
in the wild where the VBT specifies both port A eDP and
port E DP (in that order) with port E being the real one.

So let's try to flip the preference around and let the last
child device win once again.

Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: Masami Ichikawa <masami256@gmail.com>
Tested-by: Torsten <freedesktop201910@liggy.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966
Fixes: 36a0f92020dc ("drm/i915/bios: make child device order the priority order")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011202030.8829-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/vbt: Child device size remains unchanged through VBT 229

The latest documented version of the VBT is 229, but no further data has
been added to the child device definition in block 2. Update the child
device version test to eliminate the "Expected child device config size
for VBT version XXX not known; assuming 39" debug messages from the
logs.

Bspec: 20124
Bspec: 20157
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191002192258.1013-1-matthew.d.roper@intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: introduce INTEL_DISPLAY_ENABLED()

Prepare for making a distinction between not having display and having
disabled display. Add INTEL_DISPLAY_ENABLED() and use it where
HAS_DISPLAY() is used after intel_device_info_runtime_init(). This is
initially duplication, as disabling display still leads to ->pipe_mask =
0 and HAS_DISPLAY() being false.

Note that ever since i915.display_disable was introduced, it has not
affected PCH detection even if it uses HAS_DISPLAY(), as display disable
happens after that.

Since INTEL_DISPLAY_ENABLED() will not make sense unless HAS_DISPLAY()
is true, include a warning for catching misuses making decisions on
INTEL_DISPLAY_ENABLED() when HAS_DISPLAY() is false.

v2: Remove INTEL_DISPLAY_ENABLED() check from intel_detect_pch() (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190913100407.30991-1-jani.nikula@intel.com

drm/i915/gen11: Allow usage of all GPIO pins

Our pin mapping tables for ICP and MCC currently only list the standard
GPIO pins used for various output ports. Even through ICP's standard
pin usage only utilizes pins 1, 2, and 9-12, and MCC's standard pin
usage only uses pins 1, 2, and 9, these platforms do still have GPIO
registers to address pins in the range 1-3 and 9-14. OEM's may remap
GPIO usage in non-standard ways (and provide the actual mapping via VBT
settings), so we shouldn't exclude pins on these platforms just because
they aren't part of the standard mappings.

TGP's standard pin tables contains all the possible pins, so let's
rename them to "icp" and use them for all PCH >= PCH_ICP. This will
prevent intel_gmbus_is_valid_pin from rejecting non-standard pin usage
that an OEM specifies via the VBT.

Note that this will cause pin 9 to be labeled as "tc1" instead of "dpc"
in debug messages on platforms with the MCC PCH, but that may actually
help avoid confusion since the text strings will now be the same on all
gen11+ platforms instead of being different on just EHL.

v2: Drop now-unused MCC_DDC_BUS_DDI_* names.

v3: We want to compare against INTEL_PCH_TYPE, not INTEL_PCH_ID.

Bspec: 8417
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190817005041.20651-1-matthew.d.roper@intel.com

drm/i915/vbt: Fix VBT parsing for the PSR section

A single 32-bit PSR2 training pattern field follows the sixteen element
array of PSR table entries in the VBT spec. But, we incorrectly define
this PSR2 field for each of the PSR table entries. As a result, the PSR1
training pattern duration for any panel_type != 0 will be parsed
incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
version >= 226 will also be wrong.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org #v5.2
Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: François Guerraz <kubrick@fgv6.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
(cherry picked from commit b5ea9c9337007d6e700280c8a60b4e10d070fb53)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/vbt: Fix VBT parsing for the PSR section

A single 32-bit PSR2 training pattern field follows the sixteen element
array of PSR table entries in the VBT spec. But, we incorrectly define
this PSR2 field for each of the PSR table entries. As a result, the PSR1
training pattern duration for any panel_type != 0 will be parsed
incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
version >= 226 will also be wrong.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org #v5.2
Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: François Guerraz <kubrick@fgv6.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com

drm/i915: Propagate "_remove" function name suffix down

Similar to the "_release" case, consistently replace mixed
"_cleanup"/"_fini"/"_fini_hw" components found in names of functions
called from i915_driver_remove() with "_remove" or "_driver_remove"
suffixes for better code readability.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190712112429.740-6-janusz.krzysztofik@linux.intel.com

drm/i915/tgl: Add vbt value mapping for DDC Bus pin

Add VBT-value to DDC bus pin mapping for the same.

Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190711173115.28296-20-lucas.demarchi@intel.com

drm/i915: Transition port type checks to phy checks

Transition the remaining uses of intel_port_is_* over to the equivalent
intel_phy_is_* functions and drop the port functions.

v5: Fix a call in a debug function that's only called when
CONFIG_DRM_I915_DEBUG_RUNTIME_PM is on. (CI)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190709183934.445-5-matthew.d.roper@intel.com

drm/i915/ehl: Allow combo PHY A to drive a third external display

EHL has a mux on combo PHY A that allows it to be driven either by an
internal display (DDI-A or DSI DPHY) or by an external display (DDI-D).
This is a motherboard design decision that can not be changed on the
fly. Unfortunately there are no strap registers that allow us to detect
the board configuration directly, so let's use the VBT to try to figure
it out and program the mux accordingly.

For now if we run across a broken VBT that tries to claim that PHY A
is attached to both internal and external displays at the same time,
we'll resolve the conflict in favor of the internal display. To help
debug these kind of bad VBT's, let's also add a quick DRM_DEBUG message
during child device parsing so that it's easier to understand these
cases if they show up in bug reports.

v2:
- Confirmed that VBT's dvo port refers to the DDI and not the PHY.
Thus we can check more explicitly for (ddi_d && !(ddi_a || dsi)). If
a bad VBT contradicts itself, let internal display win. (Ville)

v3:
- Switch condition from !IS_ICELAKE to IS_ELKHARTLAKE. Although the
convention is usually to assume that future platforms will inherit
all current platform behavior, this feels more like a one-platform
quirk. (Ville)
- Update commit message to describe what we do if/when we encounter
broken VBT's, and note that the new debug print during child device
parsing is intentional.

Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190618175131.9139-1-matthew.d.roper@intel.com

drm/i915/ehl: Introduce Mule Creek Canyon PCH

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: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190615004210.16656-1-matthew.d.roper@intel.com

drm/i915: move modesetting core code under display/

Now that we have a new subdirectory for display code, continue by moving
modesetting core code.

display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this
is, again, a surprisingly clean operation.

v2:
- don't move intel_sideband.[ch] (Ville)
- use tabs for Makefile file lists and sort them

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-3-jani.nikula@intel.com