drm/i915/display: Allow fastset for change in HDR infoframe

Changes in Dynamic Range and Mastering infoframe
should not trigger a full modeset. Therefore, allow
fastset. DP SDP programming is already hooked up in the
fastset flow but HDMI AVI infoframe update is not, add it.
Any other infoframe that can be fastset should be added to
the helper intel_hdmi_fastset_infoframes().

v3:
 - Create a wrapper intel_ddi_update_pipe_hdmi to stick to
   uniform naming (Jani)
 - Do not disable HDMI AVI infoframe if already disabled (Uma)

v2:
 - Update HDMI AVI infoframe during fastset.

Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241023044122.3889137-1-chaitanya.kumar.borah@intel.com

drm/i915/psr: WA for panels stating bad link status after PSR is enabled

We are currently seeing unexpected link trainings with several different
eDP panels. These are caused by these panels stating bad link status in
their dpcd registers. This can be observed by doing following test:

1. Boot up without Xe module loaded

2. Load Xe module with PSR disabled:
    $ modprobe xe  enable_psr=0

3. Read panel link status register
    $ dpcd_reg read --offset 0x200e --count=1
    0x200e:  00

4. Enable PSR, sleep for 2 seconds and disable PSR again:

    $ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug
    $ echo "-1" > /sys/kernel/debug/dri/0000:00:02.0/xe_params/enable_psr
    $ echo 0x0 > /sys/kernel/debug/dri/0/i915_edp_psr_debug
    $ sleep 2
    $ cat /sys/kernel/debug/dri/0/i915_edp_psr_status | grep status
    $ echo 0x1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug
    Source PSR/PanelReplay status: DEEP_SLEEP [0x80310030]

5. Now read panel link status registers again:
    $ dpcd_reg read --offset 0x200e --count=1
    0x200e:  80

Workaround this by not trusting link status registers after PSR is enabled
until first short pulse interrupt is received.

v2:
  - clear link_ok flag on pipe disable
  - remove useless comment
  - modify intel_dp_needs_link_retrain return statement

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241029122415.1789528-1-jouni.hogander@intel.com

drm/i915/dp: Add FEC Enable Retry mechanism

Currently, even though there is a bit to control FEC enable/disable
individually, the FEC Decode Enable sequence is sent by the SOC only
once TRANS_CONF enable is set. This ties the FEC enabling too tightly
to modeset and therefore cannot be re-issued (in case of failure)
without a modeset.

From PTL, FEC_DECODE_EN sequence can be sent to a DPRX independent
of TRANS_CONF enable. This allows us to re-issue an FEC_DECODE_EN
sequence without a modeset. Hence allowing us to have a retry
mechanism in case the DPRX does not respond with an FEC_ENABLE
within certain amount of time.

While at it, replace struct drm_i915_private with struct intel_display

v4:
 - More code refactor [Jani]
 - use struct intel_display [Jani]
 - Optimize logging [Jani]

v3:
 - Make the commit message more legible [Jani]
 - Refactor code to re-use existing code [Jani]
 - Do away with platform dependent FEC enable checks [Jani]

v2:
 - Refactor code to avoid duplication and improve readability [Jani]
 - In case of PTL, wait for FEC status directly after FEC enable [Srikanth]
 - Wait for FEC_ENABLE_LIVE_STATUS to be cleared before
   re-enabling FEC [Srikanth]

Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241024061002.4085137-1-chaitanya.kumar.borah@intel.com

drm/i915/display: Fuse bit for power management disable removed

Starting with display version 13 the fuse bit to disable Display PM has
been removed.

v2: Bit removed starting with display version 13 (MattR)
v3: DG2 still uses this fuse bit (MattR)

Bspec: 50075, 69464
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241030195507.2753404-1-clinton.a.taylor@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Implement Dbuf overlap detection feature starting from LNL

From LNL onwards there is a new hardware feature, which
allows to detect if the driver wrongly allocated DBuf
entries and they happen to overlap. If enabled this will
cause a specific interrupt to occur.
We now handle it in the driver, by writing correspondent
error message to kernel log.

v2: Initialize dbuf overlap flag in runtime_defaults (Jani Nikula)

v3: Unmask the overlap detection interrupt (Uma)

v4: use display over i915 (Jani Nikula)

v5: Use display instead of dev_priv (Jani Nikula)

v6: rebased to resolve merge conflicts

Bspec: 69450, 69464
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241030103319.207235-1-vinod.govindapillai@intel.com

drm/i915/dp: Write the source OUI for non-eDP sinks as well

At least the i-tec USB-C Nano 2x Display Docking Station (containing a
Synaptics MST branch device) requires the driver to update the source
OUI DPCD registers to expose its DSC capability. Accordingly update the
OUI for all sink types (besides eDP where this has been done already).

v2: Rebased on latest patch version.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11776
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-9-imre.deak@intel.com

drm/i915/dp: Write the source OUI during connector detection

The DP sink's capabilities, like DSC, may depend on the source OUI
written to the sink. On eDP this OUI value could have been reset before
the detection started if the panel power on it got disabled. Make sure
the OUI is re-written at the beginning of detection in this case, before
the sink capabilities are read out.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-8-imre.deak@intel.com

drm/i915/dp: Write the source OUI for eDP before detecting sink capabilities

The eDP sink's capabilities, like DSC, may depend on the source OUI
written to the sink, so ensure the OUI is written before reading out the
capabilities.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-7-imre.deak@intel.com

drm/i915/dp: Reuse intel_dp_detect_dsc_caps() for eDP

Reuse intel_dp_detect_dsc_caps() which already checks for the source's
DSC cap and retrieves the DPCD version from the DPRX caps.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-6-imre.deak@intel.com

drm/i915/dp: Track source OUI validity explicitly

While updating the source OUI on the sink the driver should avoid
writing the OUI if it's already up-to-date to prevent the sink from
resetting itself in response to the update. On eDP - the only output
type where the OUI was updated so far - the driver ensured this by
comparing the current source OUI DPCD register values with the expected
Intel OUI value, skipping the update in case of a match. On some non-eDP
sinks - at least on Synaptics branch devices - this method doesn't work,
since the source OUI DPCD registers read back as all 0, even after
updating the registers.

Handle the above kind of sinks by tracking when the OUI was updated and
so should be valid, regardless of what the DPCD registers contain.

eDP sinks reset the written source OUI value when the panel power is
disabled, invalidate the OUI state accordingly.

This is required by a follow-up patch updating the source OUI for
non-eDP sink types as well.

v2: Fix setting intel_dp::oui_valid=true, if the DPCD register contains
    already the expected value.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-5-imre.deak@intel.com

drm/i915/dp: Initialize the source OUI write timestamp always

If the source OUI DPCD register value matches the expected Intel OUI
value, the write timestamp doesn't get updated leaving it at the 0
initial value if the OUI wasn't written before. This can lead to an
incorrect wait duration in intel_dp_wait_source_oui(), since jiffies is
not inited to 0 in general (on a 32 bit system INITIAL_JIFFIES is set to
5 minutes ahead of wrap-around). Fix this by intializing the write
timestamp in the above case as well.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-4-imre.deak@intel.com

drm/i915/dp: Ensure panel power remains enabled during connector detection

The sink's capabilities, like the DSC caps, depend on the source OUI
written to the sink's DPCD registers and so this OUI value should be
valid for the whole duration of the detection. An eDP sink will reset
this OUI value when the panel power is disabled, so prevent the
disabling - happening by default after a 1 sec idle period - for the
whole duration of detection.

v2: Update the documentation for intel_pps_on(). (Jani)

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

drm/i915/dp: Flush modeset commits during connector detection

Make sure that a DP connector detection doesn't happen in parallel
with an ongoing modeset on the connector. The reasons for this are:

- Besides reading the capabilities, EDID etc. the detection may change
  the state of the sink (via the AUX bus), for instance by setting the
  LTTPR mode or the source OUI (the latter introduced by an upcoming
  patch). It's better to avoid such changes affecting an onging modeset
  in any way.

- During a modeset's link training any access to DPCD registers, besides
  the registers used for link training should be avoided, at least in
  the LTTPR non-transparent and transparent link training modes.

  Such asynchronous accesses - besides connector detection - can also
  happen via the AUX device node for instance, for those a parallel
  modeset will have to be avoided in a similar way to the change in this
  patch. (A topic for a follow-up change.)

- The source OUI written to an eDP sink is valid only while the panel
  power is enabled. A modeset on eDP will enable/disable the panel power
  synchronously; this should be prevented in the middle of the connector
  detection, to ensure a consistent sink state (which depends on the
  source OUI) for the whole duration of detection. The panel power could
  still get disabled during detection after an idle period (1 sec), this
  will be prevented by the next patch.

v2: (Ville)
- s/wait_for_crtc_hw_done/wait_for_connector_hw_done
- Get drm_device using an intel_display instead of drm_i915_private ptr.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241025160259.3088727-2-imre.deak@intel.com

drm/i915/display: use x100 version for full version and release

Use x100, or ver * 100 + rel, versions for full IP version checks,
similar to what xe driver does:

- Replace IP_VER(14, 1) inline with 1401, etc.

- Convert DISPLAY_VER_FULL() to DISPLAY_VERx100()

- Convert IS_DISPLAY_VER_FULL() to IS_DISPLAY_VERx100()

- Convert IS_DISPLAY_VER_STEP() to IS_DISPLAY_VERx100_STEP()

This makes ver.rel versions easier to use, follows the xe driver
pattern, and drops the dependency on the IP_VER() macro.

v2: Rebase, drop IP_VER() from xe compat headers

v3: Rebase

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241029155536.753413-1-jani.nikula@intel.com

drm/i915/de: remove unnecessary generic wrappers

With many of the intel_de_* callers switched over to struct
intel_display, we can remove some of the unnecessary generic wrappers.

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

drm/i915/dsi: convert to struct intel_display

struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch ICL DSI code over to it.

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

drm/i915/ips: convert to struct intel_display

struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch HSW IPS code over to it.

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

drm/i915/power: convert assert_chv_phy_status() to struct intel_display

struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch assert_chv_phy_status() and its
callers to it. Main motivation to do just one function is to stop
passing i915 to intel_de_wait(), so its generic wrapper can be removed.

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

drm/i915/display: convert vlv_wait_port_ready() to struct intel_display

struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch vlv_wait_port_ready() over to
it. The main motivation to do just one function is to stop passing i915
to intel_de_wait(), so its generic wrapper can be removed.

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

drm/i915/crt: convert to struct intel_display

struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch CRT code over to it.

v2: Rebase

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

drm/i915/dp/hdcp: convert to struct intel_display

struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch DP HDCP code over to it.

v2: Rebase

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

drm/i915/hdcp: further conversion to struct intel_display

There are some unconverted stragglers left in the HDCP API still using
struct drm_i915_private. Convert to struct intel_display.

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

drm/i915/dpio: convert to struct intel_display

struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch DPIO PHY code over to it.

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

drm/i915/cx0: convert to struct intel_display

struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch Cx0 PHY code over to it.

v2: Rebase, split out the include cleanups (Rodrigo)

v3: Rebase

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

drm/i915/cx0: remove unnecessary includes

There's nothing in the header that requires the bit or bitfield
headers. Remove.

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

drm/i915/gmbus: convert to struct intel_display

struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch gmbus code over to it.

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

drm/i915/vblank: use display->platform.<platform> instead of IS_<PLATFORM>()

Switch to using the new display->platform.<platform> members for
platform identification in display code.

v2: Split out an unrelated hunk to a separate patch (Rodrigo)

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

drm/i915/vblank: drop unnecessary i915 local variable

Use struct intel_display where possible.

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

drm/i915/vga: use display->platform.<platform> instead of IS_<PLATFORM>()

Switch to using the new display->platform.<platform> members for
platform identification in display code.

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

drm/i915/tv: use display->platform.<platform> instead of IS_<PLATFORM>()

Switch to using the new display->platform.<platform> members for
platform identification in display code.

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

drm/i915/pps: use display->platform.<platform> instead of IS_<PLATFORM>()

Switch to using the new display->platform.<platform> members for
platform identification in display code.

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

drm/i915/bios: use display->platform.<platform> instead of IS_<PLATFORM>()

Switch to using the new display->platform.<platform> members for
platform identification in display code.

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

drm/i915/display: add subplatform group for HSW/BDW ULT

Add support for defining aliases for subplatform groups, such as HSW/BDW
ULT that covers both ULT and ULX.

ULT is a special case, because we slightly abuse the ULT subplatform
both as a subplatform and group, but with the way this is defined, it
should be fairly clear.

This follows i915 core and IS_HASWELL_ULT()/IS_BROADWELL_ULT()
conventions, i.e. "is ULT" also matches ULX platforms.

Note: Pedantically, this should have been done earlier, but it's only
feasible now that we no longer have a subplatform enum and can actually
initialize multiple subplatforms.

v2: Use the subplatform group idea

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

drm/i915/display: add platform group for g4x

Add support for defining aliases for platform groups, such as g4x that
covers both g45 and gm45.

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

drm/i915/display: remove the display platform enum as unnecessary

The display platform enums are not really needed for anything. Remove.

Without the enum, PLATFORM_UNINITIALIZED is also no longer needed for
keeping the first enum 0. Also need to switch from sp->subplatform to
sp->pciidlist as the check for array end.

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

drm/i915/display: add platform member to struct intel_display

Facilitate using display->platform.haswell and
display->platform.haswell_ult etc. for identifying platforms and
subplatforms.

Merge the platform and subplatform bitmaps together, and check that
there's no overlap.

v4:
- Lower case, s/is/platform/

v3:
- Fix sanity check on display->is after merging subplatform members

v2:
- Use bitmap ops
- Add some sanity checks with warnings

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

drm/i915/display: add display platforms structure with platform members

Add a structure with a bitfield member for each platform and
subplatform, and initialize them in platform and subplatform descs.

The structure also contains a bitmap in a union for easier manipulation
of the bits. This, in turn, requires a bit of trickery with
INTEL_DISPLAY_PLATFORMS() to count the number of bits required for
DECLARE_BITMAP().

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

drm/i915/display: convert display platforms to lower case

This will be helpful for follow-up, where the names here become struct
member names.

This does impact debug logs as well, making everything lower case.

v2: Rebase to adapt to PTL

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

drm/i915/display: join the platform and subplatform enums

We'll want to use the subplatforms similar to platforms. Join the
subplatforms next to their corresponding platforms. Update the comment
while at it.

v2: Put the subplatforms next to the platforms

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

drm/i915/display: use a macro to define platform enumerations

We'll be needing a macro based list of platforms for more things in the
future. Start by defining the platform enumerations with it.

v3: Rebase for PTL

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

drm/i915/display: use a macro to initialize subplatforms

Make it easier to change the underlying structures by using a macro
similar to PLATFORM() for initialization.

The subplatform names in debug logs change slightly as they now reflect
the enum rather than manually entered names. For example, RAPTORLAKE_S
rather than RPL-S.

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

drm/i915/display: reindent subplatform initialization

Make the subplatform initialization less cramped, and follow the coding
style more closely. Initialize .pciidlist using designated initializers.

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

drm/i915/display/dp: Reduce log level for SOURCE OUI write failures

Some devices NAK DPCD writes to the SOURCE OUI (0x300) DPCD registers.
Reduce the log level priority to prevent dmesg noise for these devices.

Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241004210816.3976058-1-clinton.a.taylor@intel.com

drm/i915/color: Make color .get_config() mandatory

Every platforms implements the color .get_config() hook. Just
make it mandatory.

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

drm/i915/color: Convert color management code to intel_display

struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the color management
code to use it (as much as possible at this stage).

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

drm/i915: Handle intel_plane and intel_plane_state in to_intel_display()

Allow one to pass intel_plane/intel_plane_state to
to_intel_display(). Works exactly like their crtc
counterparts.

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

drm/i915/color: Pimp debugs

Include the CRTC id+name information in the color management
debug prints to help identify who is at fault. And also specify
which LUT check_lut_size() is unhappy about.

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

drm/xe/ptl: Enable PTL display

At this point we should have enough support landed to turn on and start
basic testing of display functionality.

Signed-off-by: Haridhar Kalvala <haridhar.kalvala@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Acked-by: Jani Saarinen <jani.saarinen@intel.com>
Tested-by: Jani Saarinen<jani.saarinen@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/20241028193015.3241858-10-clinton.a.taylor@intel.com

drm/i915/display/xe3: disable x-tiled framebuffers

Xe3 has no more support for x-tile on display.

v2: Include up to display 29 for X-tiled support. (Gustavo)

Signed-off-by: Heikkila, Juha-pekka <juha-pekka.heikkila@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028193015.3241858-9-clinton.a.taylor@intel.com

drm/i915/xe3: Underrun recovery does not exist post Xe2

From platforms xe3 Underrun recovery does not exist

v2: improve DISPLAY_VER checking

BSpec: 68849
Signed-off-by: Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028193015.3241858-8-clinton.a.taylor@intel.com

drm/i915/xe3lpd: Move async flip bit to PLANE_SURF register

The async flip moved from PLANE_CTL to PLANE_SURF for Xe3_LPD.

Bspec: 69853,69878
Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028193015.3241858-7-clinton.a.taylor@intel.com

drm/i915/cx0: Remove bus reset after every c10 transaction

C10 phy timeouts occur on xe3lpd if the c10 bus is reset every
transaction. Although not required by BSPEC bus resets were added for
prior platforms as a workaround. Starting with xe3_lpd this bus reset is
not necessary.

Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028193015.3241858-6-clinton.a.taylor@intel.com

drm/i915/cx0: Extend C10 check to PTL

When deciding the type of the phy, add PTL support to make
sure the correct path is taken for selection of C10 PHY.
Only port A is connected C10 PHY for Pantherlake.

Bspec:  72571
Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028193015.3241858-5-clinton.a.taylor@intel.com

drm/i915/ptl: Define IS_PANTHERLAKE macro

Common display code requires IS_PANTHERLAKE macro.
Define the macro and set 0 as PTL is no longer support for i915.

Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@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/20241028193015.3241858-4-clinton.a.taylor@intel.com

drm/i915/xe3lpd: Add check to see if edp over type c is allowed

Read PICA register to see if edp over type C is possible and then
add the appropriate tables for it.

--v2
-remove bool from intel_encoder have it in runtime_info [Jani]
-initialize the bool in runtime_info init [Jani]
-dont abbreviate the bool [Jani]

--v3
-Remove useless display version check [Jani]
-change the warn on condition [Jani]
-no need for a different function for edp type c check [Jani]
-dont add register in i915_reg [Jani]

Bspec: 68846
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028193015.3241858-3-clinton.a.taylor@intel.com

drm/i915/xe3lpd: Update pmdemand programming

There are some minor changes to pmdemand handling on Xe3:
 - Active scalers are no longer tracked.  We can simply skip the readout
   and programming of this field.
 - Active dbuf slices are no longer tracked.  We should skip the readout
   and programming of this field and also make sure that it stays 0 in
   our software bookkeeping so that we won't erroneously return true
   from intel_pmdemand_needs_update() due to mismatches.
 - Even though there aren't enough pipes to utilize them, the size of
   the 'active pipes' field has expanded to four bits, taking over the
   register bits previously used for dbuf slices.  Since the lower bits
   of the mask have moved, we need to update our reads/writes to handle
   this properly.

v2: active pipes is no longer always max 3, add in the ability to go to
4 for PTL.
v3: use intel_display for display_ver check, use INTEL_NUM_PIPES
v4: add a conditional for number of pipes macro vs using 3.
v5: reverse conditional order of v4.
v6: undo v5 and fix num_pipes assignment
v7: pass display struct instead of i915, checkpatch fix
v8: Alignment issue

Bspec: 68883, 69125
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028193015.3241858-2-clinton.a.taylor@intel.com

drm/xe: switch to common PCI ID macros

Switch to the shared PCI ID macros in drm/intel/pciids.h. Remove
xe_pciids.h.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/84e08172184bdc6409cf6dd13f6c52971c647dbb.1729590029.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/intel/pciids: rename i915_pciids.h to just pciids.h

In preparation of sharing the PCI ID macros between i915 and xe, rename
i915_pciids.h to pciids.h.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/835143845faa5310e4bb58405a8a0848392bbf06.1729590029.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/pciids: add PVC PCI ID macros

The xe PCI ID macros are a subset of the i915 PCI IDs macros, apart from
the PVC PCI IDs (naturally, because i915 does not and will not support
PVC). In preparation of using a shared file, add PVC PCI IDs to
i915_pciids.h.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bc62e37cbfa3ed4dbfc75a7ca69b87afae6a727b.1729590029.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: convert I915_STATE_WARN() to struct intel_display

Convert I915_STATE_WARN() to struct intel_display *, and rename to
INTEL_DISPLAY_STATE_WARN(). Do some minor opportunistic struct
drm_i915_private to struct intel_display conversions while at it.

v2: crtc_state may be NULL in intel_connector_verify_state()

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

drm/i914/xe3lpd: Increase bigjoiner limitations

With 6k resolution support for a single crtc being added
bigjoiner will only come into picture when hdisplay > 6144

Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028074333.182041-4-suraj.kandpal@intel.com

drm/i915/psr: Change psr size limits check

Change the check to only check for psr size limits till Pre-Xe2
since after that the psr size is equal to maximum pipe size anyways.

--v2
-Check only size limit until pre-Xe2 [Matt]

--v3
-Make sure psr_max_{h,v} and max_bpp are equal to crtc_{h,v}_display
and pipe_bpp [Ankit]

Bspec: 69885, 68858
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028130012.199090-1-suraj.kandpal@intel.com

drm/i915/xe3lpd: Increase resolution for plane to support 6k

DISPLAY_VER >= 30 onwards CRTC can now support 6k resolution.
Increase pipe and plane max width and height to reflect this
increase in resolution.

--v2
-Take care of the subsampling scenario sooner rather than later [Matt]

--v3
-Take care of the joined pipe limits too [Ankit/Matt]

--v4
-Leave the joiner limits check here as is and handle them later [Ville]

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028074333.182041-2-suraj.kandpal@intel.com

drm/i915: Use string enable/disable choice helpers

Replace the last few remaining instances of string enable(d)/disable(d)
choices with the linux string choice helpers to avoid further
cocci warnings.

Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241023054655.4017489-1-sai.teja.pottumuttu@intel.com

drm/i915/xe2lpd: Update C20 algorithm to include tx_misc

There has been an update to the BSpec in which we need to set
tx_misc=0x5 field for C20 TX Context programming for HDMI TMDS for
Xe2_LPD and newer. That field is mapped to the bits 7:0 of
SRAM_GENERIC_<A/B>_TX_CNTX_CFG_1, which in turn translates to tx[1] of
our state struct. Update the algorithm to reflect this change.

v2:
  - Fix Bspec reference (Sai Teja)
  - Use struct intel_display instead of drm_i915_private. (Jani)
  - Use the correct bit width for C20_PHY_TX_MISC_MASK. (Jani)

Bspec: 74491
Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com> #v1
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241023153352.144146-3-gustavo.sousa@intel.com

drm/i915/cx0: Pass crtc_state to intel_c20_compute_hdmi_tmds_pll()

The variable crtc_state already contains everything that
intel_c20_compute_hdmi_tmds_pll() needs. Simplify the function's
signature by passing that struct instead of separate variables.

Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241023153352.144146-2-gustavo.sousa@intel.com

drm/xe/hdcp: Fix gsc structure check in fw check status

Fix the condition for gsc structure validity in
gsc_cs_status_check(). It needs to be an OR and not an AND
condition

Fixes: b4224f6bae38 ("drm/xe/hdcp: Check GSC structure validity")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241025160834.8785-1-suraj.kandpal@intel.com

drm/i915/display: Add Wa_16023981245

Disable the support for odd panning in x direction.

v2: Replace HSD with WA in commit message [Suraj]
    Modified the condition for handling odd panning

v3: Simplified the condition for checking hsub
    Using older framework for wa as rev1[Jani]

v4: Modify the condition for hsub [Sai Teja]
    Initialize hsub in else path [Dan]

v5: Replace IS_LUNARLAKE with display version.
    Resolve nitpicks[Jani]

v6: Replace -EINVAL with hsub [Suraj]
    Remove src_w check as not required

v7: Remove check for NV12.
    Add check for PTL as well [Matt]

v8: Alignment fix

Continuing discussions from:
https://patchwork.freedesktop.org/series/136416/

Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241028044153.1605209-1-nemesa.garg@intel.com

drm/i915/xe3lpd: Load DMC

Load the DMC for Xe3LPD.

Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241022155115.50989-1-gustavo.sousa@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>

drm/i915/display: Cover all possible pipes in TP_printk()

Tracepoints that display frame and scanline counters for all pipes were
added with commit 1489bba82433 ("drm/i915: Add cxsr toggle tracepoint")
and commit 0b2599a43ca9 ("drm/i915: Add pipe enable/disable
tracepoints"). At that time, we only had pipes A, B and C. Now that we
can also have pipe D, the TP_printk() calls are missing it.

As a quick and dirty fix for that, let's define two common macros to be
used for the format and values respectively, and also ensure we raise a
build bug if more pipes are added to enum pipe.

In the future, we should probably have a way of printing information for
available pipes only.

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

drm/i915/display: Do not use ids from enum pipe in TP_printk()

Because much of kernel tracepoints is implemented at the C preprocessor
level, C identifiers used in TP_printk() are saved verbatim in the event
format, even when they represent compile-time constant values.

As an example, we can look at the format for the intel_pipe_enable
event:

    # cat /sys/kernel/debug/tracing/events/i915/intel_pipe_enable/format | grep '^print fmt'
    print fmt: "dev %s, pipe %c enable, pipe A: frame=%u, scanline=%u, pipe B: frame=%u, scanline=%u, pipe C: frame=%u, scanline=%u", __get_str(dev), REC->pipe_name, REC->frame[PIPE_A], REC->scanline[PIPE_A], REC->frame[PIPE_B], REC->scanline[PIPE_B], REC->frame[PIPE_C], REC->scanline[PIPE_C]

We see that PIPE_A, PIPE_B and PIPE_C are pasted directly in the format.
Because tools that interact with kernel tracepoints don't know about
those ids, they'll endup failing to parse the format or produce
corrupted output.

For example, we can see below that trace-cmd repeats PIPE_A's
frame/scanline counts for all pipes (probably because it evaluates
unknown ids as zero):

   $ trace-cmd report -F intel_pipe_enable | tail -n5
        testdisplay-8616  [000] 22048.276758: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=861, scanline=480, pipe B: frame=861, scanline=480, pipe C: frame=861, scanline=480
        testdisplay-8616  [001] 22048.490287: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=867, scanline=480, pipe B: frame=867, scanline=480, pipe C: frame=867, scanline=480
        testdisplay-8616  [003] 22048.700181: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=872, scanline=400, pipe B: frame=872, scanline=400, pipe C: frame=872, scanline=400
        testdisplay-8616  [002] 22049.054220: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=881, scanline=2170, pipe B: frame=881, scanline=2170, pipe C: frame=881, scanline=2170
        testdisplay-8616  [002] 22049.166851: intel_pipe_enable:    dev 0000:00:02.0, pipe B enable, pipe A: frame=887, scanline=1632, pipe B: frame=887, scanline=1632, pipe C: frame=887, scanline=1632

, while in fact we have different values for each pipe, which can be
confirmed with the raw view of the events:

    $ trace-cmd report -R -F intel_pipe_enable | tail -n5
         testdisplay-8616  [000] 22048.276758: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[5d, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
         testdisplay-8616  [001] 22048.490287: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[63, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
         testdisplay-8616  [003] 22048.700181: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[68, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[90, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
         testdisplay-8616  [002] 22049.054220: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[71, 03, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[7a, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=A
         testdisplay-8616  [002] 22049.166851: intel_pipe_enable:     dev=0000:00:02.0 frame=ARRAY[77, 03, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] scanline=ARRAY[60, 06, 00, 00, 39, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe_name=B

To fix that, we need a fix that looks more like a hack: use macros that
result to integer constants instead of enum pipe values. This fixes the
issue, but could break if, for whatever unlikely reason, the underlying
values in the enum are changed.

In the future, we should find a better way to handle this, but for now,
the hack took care of the job:

    $ trace-cmd report -F intel_pipe_enable | tail -n5
         testdisplay-9224  [003] 24324.455375: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=1103, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
         testdisplay-9224  [002] 24324.669845: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=1109, scanline=480, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
         testdisplay-9224  [003] 24324.900105: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=1115, scanline=31, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
         testdisplay-9224  [002] 24325.256408: intel_pipe_enable:    dev 0000:00:02.0, pipe A enable, pipe A: frame=1124, scanline=2171, pipe B: frame=0, scanline=0, pipe C: frame=0, scanline=0
         testdisplay-9224  [003] 24325.380789: intel_pipe_enable:    dev 0000:00:02.0, pipe B enable, pipe A: frame=1131, scanline=979, pipe B: frame=1, scanline=1082, pipe C: frame=0, scanline=0

v2:
  - Statically assert that PIPE_A == _TRACE_PIPE_A. (MattR)

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-5-gustavo.sousa@intel.com

drm/i915/display: Store pipe name in trace events

The first part[1] of the LWN series on using TRACE_EVENT() mentions
about TP_printk():

    "Do not create new tracepoint-specific helpers, because that will
    confuse user-space tools that know about the TRACE_EVENT() helper
    macros but will not know how to handle ones created for individual
    tracepoints."

It seems this is what we ended up doing when using pipe_name() in
TP_printk().

For example, the format for the intel_pipe_update_start event is as
follows:

    # cat /sys/kernel/debug/tracing/events/i915/intel_pipe_update_start/format
    name: intel_pipe_update_start
    ID: 1136
    format:
            field:unsigned short common_type;       offset:0;       size:2; signed:0;
            field:unsigned char common_flags;       offset:2;       size:1; signed:0;
            field:unsigned char common_preempt_count;       offset:3;       size:1; signed:0;
            field:int common_pid;   offset:4;       size:4; signed:1;

            field:__data_loc char[] dev;    offset:8;       size:4; signed:0;
            field:enum pipe pipe;   offset:12;      size:4; signed:1;
            field:u32 frame;        offset:16;      size:4; signed:0;
            field:u32 scanline;     offset:20;      size:4; signed:0;
            field:u32 min;  offset:24;      size:4; signed:0;
            field:u32 max;  offset:28;      size:4; signed:0;

    print fmt: "dev %s, pipe %c, frame=%u, scanline=%u, min=%u, max=%u", __get_str(dev), ((REC->pipe) + 'A'), REC->frame, REC->scanline, REC->min, REC->max

The call to pipe_name(__entry->pipe) is expanted to ((REC->pipe) + 'A')
and that's how the format is saved.

Even though the output from /sys/kernel/debug/tracing/trace will look
correct (because it is generated in the kernel), we will see corrupted
lines when using a tool like trace-cmd to view the data.

While the output looks correct when looking at
/sys/kernel/debug/tracing/trace, we see corrupted lines when viewing the
trace data with "trace-cmd report":

    $ trace-cmd report \
    > | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
    > | cat -v | uniq -c
         34 pipe ^A

, where ^A is a non-printable character.

As a fix, let's store the pipe name directly in the event. The fix was
done by applying the following sed script:

    s/__field\s*(\s*enum\s\+pipe\s*,\s*pipe\s*)/__field(char, pipe_name)/
    s/__entry\s*->\s*pipe\s*=\s*\([^;]\+\);/__entry->pipe_name = pipe_name(\1);/
    s/pipe_name\s*(\s*__entry\s*->\s*pipe\s*)/__entry->pipe_name/

After these changes, using the same example, we have the following:

    $ trace-cmd report \
    > | sed -n 's/.*dev 0000:00:02\.0, \(pipe .\).*/\1/p' \
    > | cat -v | sort | uniq -c
        396 pipe A
         34 pipe B

[1] https://lwn.net/Articles/379903/

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016135300.21428-4-gustavo.sousa@intel.com

drm/i915/display: Zero-initialize frame/scanline counts in tracepoints

In an upcoming change, we will also add support for logging
frame/scanline counts for pipe D in relevant tracepoints.

In [1], Matt mentioned the possibility of having garbage in those counts
for pipe D on a platform containing only 3 pipes. Indeed, it has been
verified that the counts for the extra pipe would not be
zero-initialized by the tracing system.

Since it is also possible that the same would happen for a fused-off
pipe, let's go ahead and add the logic to zero-initialize the arrays
now.

[1] https://lore.kernel.org/all/20240918224927.GU5091@mdroper-desk1.amr.corp.intel.com/

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

drm/i915/display: Fix out-of-bounds access in pipe-related tracepoints

Some display trace events use array members to store frame and scanline
counts for each pipe. However, those arrays are declared with 3 as the
hardcoded size, which cause out-of-bounds access when the trace event is
enabled on a platform that contains pipe D.

For example, when looking at the last 10 intel_pipe_enable events after
running IGT's testdisplay, we see the following on a MTL machine that
has pipe D available:

    $ trace-cmd report -R -F intel_pipe_enable \
    > | tail \
    > | sed 's,\(frame=.*\) \(scanline=.*\),\n\t   \1\n\t\2,'
         testdisplay-6715  [002] 17591.063491: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[83, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [003] 17591.264742: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[89, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [003] 17591.464541: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[8f, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [001] 17591.695827: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[95, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [000] 17591.915841: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[9a, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [000] 17592.127114: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[a0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [002] 17592.358351: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [002] 17592.580467: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [000] 17592.950946: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[b8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-6715  [004] 17593.079597: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[bf, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[00, 00, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00] pipe=1

Which shows zeros for pipe A's scanline counts. That happens because
pipe D's frame counts are overwriting them.

Let's fix that by making the arrays bring able to store info for all
possible pipes.

With the fix, we get the following:

    $ trace-cmd report -R -F intel_pipe_enable \
    > | tail \
    > | sed 's,\(frame=.*\) \(scanline=.*\),\n\t   \1\n\t\2,'
         testdisplay-7040  [003] 18067.489565: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[8c, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[8e, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18067.699312: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[92, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18067.908868: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[98, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18068.122802: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[9d, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[58, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [003] 18068.331019: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[a2, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18068.529067: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[a8, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [003] 18068.742033: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[ae, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[e0, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18068.956229: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[b3, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[1f, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [002] 18069.295322: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[bb, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[7b, 08, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=0
         testdisplay-7040  [010] 18069.423527: intel_pipe_enable:     dev=0000:00:02.0
               frame=ARRAY[c2, 01, 00, 00, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
            scanline=ARRAY[d0, 05, 00, 00, 3a, 04, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] pipe=1

Which makes more sense now.

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

drm/i915: remove all IS_<PLATFORM>_GT<N>() macros

There aren't many users for the IS_<PLATFORM>_GT<N>() macros, and many
of them are in fact unused. Even among the users, the platform check is
often redundant. Just remove the macros.

Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240930124948.3551980-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/xe3lpd: Add condition for EDP to powerdown P2.PG

Add condition for P2.PG power down value.

v2: change subject line to better match patch condition

Bspec: 74494
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241018200311.67324-8-matthew.s.atwood@intel.com

drm/i915/xe3lpd: Add new bit range of MAX swing setup

Add new bit range for Max PHY Swing Setup in PORT_ALPM_CTL
register for DISPLAY_VER >= 30.

v2: implement as two separate macros instead of a single macro
v3: extend previous definition by 2 bits that were previously reserved

Bspec: 70277
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@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/20241018200311.67324-6-matthew.s.atwood@intel.com

drm/i915/xe3lpd: Add C20 Phy consolidated programming table

From DISPLAY_VER() >= 30 C20 PHY consolidated programming table of
DP and eDP been merged and now use the same rates and values. eDP
over TypeC has also been introduced.
Moreover it allows more granular and higher rates. Add new table to
represent this change.

Bspec: 68961
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241018200311.67324-5-matthew.s.atwood@intel.com

drm/i915/xe3lpd: Add cdclk changes

Xe3_LPD has new max cdclk of 691200 which requires reusing the lnl table
and modify/add higher frequencies. Updating the max cdclk supported by
the platform and voltage_level determination is also updated.

There are minor changes in cdclk programming sequence compared to lnl,
where programming cd2x divider needs to be skipped. This is already handled
by the calculations in existing code.

v2: update tables
v3: xe3lpd doesn't supply the power control unit the voltage index

Bspec: 68861, 68863, 68864
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241018200311.67324-3-matthew.s.atwood@intel.com

drm/i915: Remove ckey/format checks from skl_update_scaler_plane()

skl_plane_check() already takes care to reject scaling when an
unsupported pixel format or color keying is used. No need to
replicate that in the scaler code.

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

drm/i915/pfit: Extract intel_pfit.c

The panel fitter code doesn't really have much to do with the
rest of intel_panel.c, so extract it all into its own file.

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

drm/i915/panel: Convert panel code to intel_display

struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the panel code to
use it (as much as possible at this stage).

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

drm/i915/pfit: Check pfit destination window on ILK-BDW

The ILK-BDW panel fitter has several restrictions on the
destination window size. Check for those and reject the
configuration if things aren't entirely proper.

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

drm/i915/pfit: Reject cloning when using pfit on ILK-BDW

The panel fitter lives inside the pipe and so would affect all cloned
outputs. However the relevant properties (scaling mode, TV margins)
are per-connector so we could end up with a situation where each cloned
output wants a different pfit configuration. Let's just reject pfit
usage with cloning entirely.

Currently not an issue as we don't yet expose the TV margin
properties, but if/when we add those to HDMI we could end up
in this situation. For eDP/DP we don't support cloning anyyway.

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

drm/i915/pfit: Check pfit minimum timings in pre-SKL

Transcoder hdisplay/vdisplay have documented minimum limits
when using the panel fitter. Enforce those limits for all
pre-SKL platforms. SKL+ handles everything in the unified
scaler code instead.

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

drm/i915/pfit: Reject pfit downscaling for GMCH platforms

Gen2/3 pfit doesn't support downscaling at all, so reject it.

On i965+ downscaling is supported by the hardware (max scale
factor < 2.0), but as downscaling increases the effective
pixel rate we can't safely allow it unless
intel_crtc_compute_pixel_rate() gets fixed. Probably the
best solution would be to calculate (at least an
apporiximate) pfit destination window and use
ilk_pipe_pixel_rate() for all platforms. For now reject
downscaling on all gmch platforms.

The intel ddx has a similar check for this in userspace,
modesetting ddx does not. And presumably wayland compositors
also do not make such assumptions in userspace.

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

drm/i915/pfit: Check pfit scaling factors on ILK-BDW

Make sure we're not exceeding the max scaling factors for the panel
fitter on ILK-BDW. SKL+ is skipped here since this is all supposed to
be handled by the unified scaler code.

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

drm/i915/pfit: Check pipe source size against pfit limits on ILK-BDW

The ILK-BDW panel fitter imposes extra limits on the maximum
pipe source size we can use. Check for that.

Only HSW/BDW are really affected by this since on older platforms
the max hdisplay/vdisplay matches the max PIPESRC. But we'll
put in the limits for all the platforms just to keep things
clear.

Note that pch_panel_fitting() is also used on SKL+, but we'll
skip the checks for those as it's all supposed to be handled
in the unified scaler code.

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

drm/i915/active: Use try_cmpxchg() in active_fence_cb()

Replace this pattern in active_fence_cb():

    cmpxchg(*ptr, old, new) == old

... with the simpler and faster:

    try_cmpxchg(*ptr, &old, new)

The x86 CMPXCHG instruction returns success in the ZF flag,
so this change saves a compare after the CMPXCHG.

Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20241003084533.871524-1-ubizjak@gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/psr: vbt.psr.enable is only for eDP panels

We don't want to check vbt.psr.enable on DP Panel Replay as it is targeted
for eDP panel usage only.

Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241021073349.1222331-1-jouni.hogander@intel.com

drm/i915/display: Remove kstrdup_const() and kfree_const() usage

kstrdup_const() and kfree_const() can be confusing in code built as a
module. In such a case, it does not do what one could expect from the name
of the functions.

The code is not wrong by itself, but in such a case, it is equivalent to
kstrdup() and kfree().

So, keep thinks simple and straightforward.

This reverts commit 379b63e7e682 ("drm/i915/display: Save a few bytes of
memory in intel_backlight_device_register()")

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/f82be2ee3ac7d18dd9982b5368a88a5bf2aeb777.1727977199.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/gvt: use macros from drm_dp.h instead of duplication

Use the existing macros in drm_dp.h for DPCD and DP AUX instead of
duplicating. Remove unused macros, as well as the duplicate definition
of DPCD_SIZE.

AUX_NATIVE_REPLY_NAK is left unchanged, as it does not match
DP_AUX_NATIVE_REPLY_NACK, and I'm not sure what the right thing to do is
here.

Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Zhi Wang <zhiwang@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240930135342.3562755-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/ddi: use string choice helpers

Use str_enabled_disabled string helpers for better readability and to
fix cocci warning.

Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Closes: https://lore.kernel.org/r/202410071601.TFpXoqgW-lkp@intel.com/
Signed-off-by: R Sundar <prosunofficial@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241007173300.83902-1-prosunofficial@gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/dp: use string choice helpers

Use str_on_off string helpers for better readability and to fix cocci
warning.

Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Closes: https://lore.kernel.org/r/202410071252.cWILJzrH-lkp@intel.com/
Signed-off-by: R Sundar <prosunofficial@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241007174857.85061-1-prosunofficial@gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/xe: fix build failure originating from backmerge

../drivers/gpu/drm/xe/display/xe_display.c: In function ‘xe_display_pm_shutdown’:
../drivers/gpu/drm/xe/display/xe_display.c:382:27: error: passing argument 1 of ‘intel_dmc_suspend’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  382 |         intel_dmc_suspend(xe);
      |                           ^~
      |                           |
      |                           struct xe_device *
In file included from ../drivers/gpu/drm/xe/display/xe_display.c:24:
../drivers/gpu/drm/i915/display/intel_dmc.h:22:46: note: expected ‘struct intel_display *’ but argument is of type ‘struct xe_device *’
   22 | void intel_dmc_suspend(struct intel_display *display);
      |                        ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~

Fixes: c141cf76918e ("Merge drm/drm-next into drm-intel-next")
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241022080943.763580-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/pxp: Add missing tag for Wa_14019159160

Add missing tag for "Wa_14019159160 - Case 2" (for existing
PXP code that ensures run alone mode bit is set to allow
PxP-decryption.

 v5: - remove the max IP_VER check since new platforms that
       i915 supports needs this fix and tag the caller too
       (John Harrison).
 v4: - Include IP_VER 12.71. (Matt Roper)
 v3: - Check targeted platforms using IP_VAL. (John Harrison)
 v2: - Fix WA id number (John Harrison).
     - Improve comments and code to be specific
       for the targeted platforms (John Harrison)

Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241016001658.2671225-1-alan.previn.teres.alexis@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Fix irq related documentation

Also update the function names in the documentation.

Closes:
https://lore.kernel.org/intel-gfx/20241001134331.7b4d4ca5@canb.auug.org.au/

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Fixes: 3de5774cb8c0 ("drm/i915/irq: Rename suspend/resume functions")
Cc: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241011214111.98128-1-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/i915: Remove unused underrun irq/reporting bits

Underrun recovery was defeatured and was never brought into usage.
Thus we can remove the underrun recovery interrupt/reporting
register bits and related logic introduced to detect/report soft,
hard, port underruns.

Essentially this is a revert of the commit 8bcc0840cf7c
("drm/i915/xelpd: Enhanced pipe underrun reporting") which originally
added this functionality. Also note that PIPE_STATUS_UNDERRUN bit in
PIPESTATUS still stays relevant but we would move back to not
clearing this sticky bit as we are not using any information from
this register.

v2: Extend commit message to add more details (Matt Roper)
v3: Fix the old commit mention in commit message

Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241015080503.3521063-1-sai.teja.pottumuttu@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

i915: fix DRM_I915_GVT_KVMGT dependencies

Depending on x86 and KVM is not enough, as the kvm helper functions
that get called here are controlled by CONFIG_KVM_X86, which is
disabled if both KVM_INTEL and KVM_AMD are turned off.

ERROR: modpost: "kvm_write_track_remove_gfn" [drivers/gpu/drm/i915/kvmgt.ko] undefined!
ERROR: modpost: "kvm_page_track_register_notifier" [drivers/gpu/drm/i915/kvmgt.ko] undefined!
ERROR: modpost: "kvm_page_track_unregister_notifier" [drivers/gpu/drm/i915/kvmgt.ko] undefined!
ERROR: modpost: "kvm_write_track_add_gfn" [drivers/gpu/drm/i915/kvmgt.ko] undefined!

Change the dependency to CONFIG_KVM_X86 instead.

Fixes: ea4290d77bda ("KVM: x86: leave kvm.ko out of the build if no vendor module is requested")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20241015152157.2955229-1-arnd@kernel.org
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Merge drm/drm-next into drm-intel-next

Needed to bring some KVM changes to be able to include a fix in our Kconfig.

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