VSC SDP revision 7 (Panel Replay + Pixel Encoding/Colorimetry Format)
unpacking is missing in intel_dp_vsc_sdp_unpack(). This causes pipe
state mismatches during state readout because the VSC SDP state is not
properly recovered when Panel Replay is active with colorimetry.
Add the missing case for revision 7 to intel_dp_vsc_sdp_unpack()
so that the state is correctly recovered.
v2: Rebase onto latest upstream
v3: Fix git commit description
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chaitanya Borah <chaitanya.kumar.borah@intel.com>
Cc: Gil Dekel <gildekel@google.com>
Signed-off-by: Juasheem Sultan <jdsultan@google.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260602205422.1792007-1-jdsultan@google.com
Prefer the str_high_low() and str_read_write() helper functions
over ternary operators with hardcoded strings.
No functional changes.
Signed-off-by: Lalit Shankar Chowdhury <lalitshankarch@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260918042325.17700-1-lalitshankarch@gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
From Xe2Lpd we removed the step to disable DC5/6 because as per Bspec
for SNPS PHY Aux will be always up. But from Xe3p LT PHY was introduced
which powers down the PHY. Which means we need to make sure
"Disable DC5/6" of AUX Programming sequence is honored.
Add the AUX power domains to the DC_off power well on Xe3p_LPD+, so that
DC5/6 stays disabled for as long as an AUX power domain is held.
Bspec: 68851, 68967
Suggested-by: Imre Deak <imre.deak@intel.com>
Co-developed-by: Ramanaidu Naladala <ramanaidu.naladala@intel.com>
Signed-off-by: Ramanaidu Naladala <ramanaidu.naladala@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patch.msgid.link/20260921022016.1525322-1-suraj.kandpal@intel.com
Once CMN_SDP_TL is enabled, GMP/PPS/VSC/VSC_EXT/AS SDPs are no longer
positioned relative to the guardband: they are anchored via
CMN_SDP_TL/CMN_SDP_TL_STGR_CTL instead. As per Bspec 68921, SDP Setup is
0 in this mode, so the old per-packet guardband sizing (based on
GMP/PPS/AS-SDP being enabled) no longer applies for GMP/PPS/VSC/VSC_EXT.
Since we are using the default stagger values for now, size the guardband
such that the max default transmission line can be supported, similar to
when CMN SDP TL is not set:
base : 2nd line of delayed vblank
GMP : 2 + GMP_STAGGER
VSC_EXT: 2 + VSC_EXT_STAGGER
VSC : 2
PPS : 2 + PPS_STAGGER
SDP Setup = 1 + MAX(GMP, VSC_EXT, VSC, PPS setup lines)
Add intel_dp_get_lines_for_cmn_sdp_tl() and route it via the existing
intel_dp_get_lines_for_sdp().
The AS SDP check in intel_dp_sdp_min_guardband() still adds
vrr.vsync_start + 1 to the guardband, since AS SDP positioning is
unaffected by CMN_SDP_TL.
v2: Add VSC min SDP guardband. (Sashiko)
Bspec: 68921
Assisted-by: Copilot:claude-sonnet-4.5
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-14-ankit.k.nautiyal@intel.com
The transmission line for VSC SDP is the same as AS SDP
(EMP_AS_SDP_TL) when AS SDP is enabled. Otherwise, it uses the
second line of delayed vblank. For VSC without AS SDP, this
requires 2 lines plus 1 setup line, so the VRR guardband must be
at least 3 lines.
When both AS SDP and VSC SDP are enabled, the guardband
requirement is already accounted for during optimized guardband
calculation and the final guardband validation in
compute_config_late(). However, when VSC SDP is enabled without
AS SDP, the VSC SDP requirement is not checked explicitly.
Even in the unlikely case where the optimized guardband is
clamped to vblank length, it cannot fall below 5 lines since such
modes are already pruned. Still, for completeness, account for
VSC SDP and ensure a minimum guardband of 3 lines.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-13-ankit.k.nautiyal@intel.com
Enable programming of the common SDP transmission line on platforms that
support it. Compute and program the common base transmission line and
per-SDP stagger values from the crtc state during modeset, and disable the
feature on pipe disable.
Currently, the stagger values are set as per the default policy of the
Hardware. This can be optimized later if we come up with a specific driver
policy to sequence the SDPs better.
v2: Add WARN if the Common Transmission Line is more than Guardband +
SCL. (Suraj)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-12-ankit.k.nautiyal@intel.com
Introduce helpers to program or disable CMN_SDP_TL and stagger registers
using the state stored in crtc_state.
v2:
- Use HAS_COMMON_SDP_TL(display) instead of checking
crtc_state->dip.cmn_sdp_tl, since 0 is a valid transmission line value.
(Sashiko)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-11-ankit.k.nautiyal@intel.com
Currently the driver only programs the transmission line for the
Adaptive-Sync SDP, while the hardware controls the transmission lines for
other SDPs.
Starting with Xe3p_lpd, the hardware allows the driver to program
transmission lines for additional DP SDPs. Prepare for this by adding
fields to struct intel_crtc_state to store SDP transmission lines, and
include them in pipe config comparison.
The SDP transmission line fields track vrr.vsync_start/vtotal, which are
allowed to change during a seamless LRR fastset. Guard their pipe config
comparison under !fastset, same as vrr.vsync_start/vsync_end, so a fastset
is not unnecessarily turned into a full modeset.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-10-ankit.k.nautiyal@intel.com
Add a helper macro to detect CMN SDP TL support on platforms with display
version 35 and above.
v2: Use prefix drm/i915/dip. (Suraj)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-9-ankit.k.nautiyal@intel.com
Add registers definitions for common SDP transmission line CMN_SDP_TL
and CMN_SDP_TL_STGR_CTL.
v2: Move all registers to intel_dip_regs.h (Ankit)
Bspec: 74384
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-8-ankit.k.nautiyal@intel.com
The driver currently computes the Adaptive Sync SDP transmission line
directly at programming time. Instead, compute and store the
AS SDP transmission line in the crtc state and use it when programming the
EMP_AS_SDP_TL register.
We get the clear picture about the SDPs and guardband only in
intel_dp_sdp_compute_config_late() therefore we must configure the
AS SDP transmission line at this point when AS SDP is enabled in
crtc_state.
This prepares the ground for supporting programmable transmission lines
for additional DP SDPs.
While moving the helper into intel_dip.c, drop the
intel_crtc_has_dp_encoder() check instead of relocating it. It was
needed in the old VRR write path shared by other encoderes as well, but
intel_dip_sdp_tl_compute_config_late() is only reached via DP, so HDMI
never sets crtc_state->dip.emp_as_sdp_tl and it stays 0 by default.
v2:
- Move the helper into intel_dip.c and drop the
intel_crtc_has_dp_encoder() check.
- Drop the redundant checks. (Suraj)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-7-ankit.k.nautiyal@intel.com
The Adaptive Sync SDP is currently the only packet with a programmable
transmission line.
Make a structure struct intel_dip for Data Island Packets. Add a member to
track Adaptive-Sync SDP transmission line. Include the new member in the
pipe configuration comparison.
This will pave the way for supporting more packets' programmable
transmission lines, including the common base SDP transmission line
introduced with Xe3p_lpd.
v2:
- Move struct intel_dip from intel_dip.h to intel_display_types.h (Jani)
- Move PIPE_CONF_CHECK for emp_as_sdp_tl in !fastset block. (Sashiko)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> (#v1)
Link: https://patch.msgid.link/20260915164657.3429075-6-ankit.k.nautiyal@intel.com
Introduce a DIP helper to compute the Adaptive Sync SDP transmission line
and use it when programming the EMP_AS_SDP_TL register.
Currently the AS SDP transmission line is programmed to the T1 position.
This can be extended in the future to support programming the T2 position
as well.
While at it, improve the documentation: the AS SDP transmission line
corresponds to the T1 position, which maps to the start of the VSYNC
pulse.
v2:
- Move the helper into intel_dip.c and make it static, since intel_dip.c
is its only caller.
- Drop the now unused prototype from intel_dp.h.
- Add the check HAS_EMP_AS_SDP_TL(). (Suraj)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> (#v1)
Link: https://patch.msgid.link/20260915164657.3429075-5-ankit.k.nautiyal@intel.com
At the moment, the common register for programming Transmission line for
Extended Metadata Packet and Adaptive-Sync Secondary Data Packet
(EMP_AS_SDP_TL) is only used to program Adaptive-Sync SDP (AS SDP).
Since VRR and Video Timing Extended Metadat Packet (VTEMP) are not yet
implemented for HDMI, add an explicit check to write the register only
for DP encoders (that may use AS SDP) and reset the register for non-DP
encoders.
In subsequent changes, instead of directly writing the value,
appropriate helpers will be called, that will supply the transmission line
for these packets.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-4-ankit.k.nautiyal@intel.com
Now that intel_dip_write_emp_as_sdp_tl() exists, use it instead of
the open-coded EMP_AS_SDP_TL programming sequence in
intel_vrr_set_transcoder_timings().
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-3-ankit.k.nautiyal@intel.com
Add new files intel_dip.c, intel_dip.h, and intel_dip_regs.h to handle
low level hardware programming related to Data Island Packets.
Currently only programming of the Transmission Line for HDMI 2.1
Extended Metadata Packet (EMP) and DP Adaptive-Sync Secondary Data
Packet (SDP) is added (MMIO register EMP_AS_SDP_TL).
This will serve as a common place for DIP related code, which is currently
scattered across DP and HDMI files. A TODO has been added for extracting
the remaining DIP helpers.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915164657.3429075-2-ankit.k.nautiyal@intel.com
Currently there's no indication if fence wait failed. Debug log about
it.
v2: Rebase, no timeout anymore
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/6b670a146bfcfd0cc2c7641cc8d72df96e356ef9.1789069102.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The struct intel_atomic_state * pointer variables and parameters are
named "state" everywhere. Follow suit in
intel_atomic_commit_fence_wait().
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/988f1253004e68d565f3915cbd24182ca95dee49.1789069102.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
i915 has the Kconfig option DRM_I915_FENCE_TIMEOUT, defaulting to 10
seconds. xe doesn't use it, instead defaulting to
MAX_SCHEDULE_TIMEOUT. Unify the behaviour by switching to
dma_fence_wait() which defaults to MAX_SCHEDULE_TIMEOUT.
As dma_fence_wait() returns 0 when the fence was signaled, update the
return value check.
This should be possible now that commit 3aef9c94c0 ("drm/i915: Perform
full wedge on display reset") has been merged, and we no longer rely on
the timeout.
v3: Try this again with full wedge
v2: Use dma_fence_wait(), fix return value check (Maarten)
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/1880e49c9270049d5dfd944a1cbf712d664d02aa.1789069102.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Its observed that on AUX_CH failure, even if the retry is increased to
1000, it does not succeed. Either the command might be wrong or sink in
an unknown/sleep state can cause this. So try waking the sink device.
Before reading the DPCD caps wake the sink for eDP.
v2: Use poll_timeout_us (Jani N)
Add the reason, why this change is required (Ville)
v3: Wake sink only for eDP
Remove the dpcd probe set to true/false in wake_sink (Imre)
v4: make edp_wake_sinc() static and dpcd_readb -> dpcd_reab_byte (Suraj)
v5: Drop poll_timeout_us. drm_dp_dpcd_read_byte() already retries the AUX
transaction internally (up to ~16ms), so the outer 6ms poll could
never iterate and only added a pre-read delay on the hot path; read
DP_SET_POWER once instead. Wake the sink before reading the DPCD
caps, otherwise a sleeping sink fails the caps read and returns
early before the wake ever runs. (Suraj, Jani, Sashiko)
v6: Mask and write DP_SET_POWER (Sashiko)
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/4391
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16654
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260915042300.2201757-1-arun.r.murthy@intel.com
In supported devices, HPDs can generate PME and which in turn
can invoke runtime resume calls for xe. No need to keep the
HPD polling in such PME capable devices.
v2: use intel_display_rpm_pme_enabled() directly (JaniN)
Bspec: 52979, 52980, 68857, 68867, 68970
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-6-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
If a device supports generating PME from HPDs, resetting HPD IRQs
will be counter productive as HPDs itself will be lost. During
suspend routines, all the IRQs are reset. So if the device is
capable of generating PME rom HPDs, keep the HPD related IRQs from
reset based on the PME capability of the device on a target power
state. PME capability will be assessed and updated separately.
v2: change keep_hpd to reset_hpd
v3: use intel_display_rpm_pme_enabled() directly (JaniN)
v4: remove the unused include file from the previous revision
Bspec: 52979, 52980, 68857, 68867, 68970
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-5-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Plug the pme_enabled query for xe. It will return the current
PME status for the device. For supported platforms, PME is
enabled during runtime suspend calls if the device is PME is capable.
v2: use the xe_pm_pme_enabled()
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-4-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
PME capabiliy need to be assessed very early during runtime suspend
routine to avoid resetting HPDs during IRQ resets. As display
runtime pm routines are being executed in the independent intel
display driver entry points, we need to have independent access
to the pme status as well. Add a provision to query the optional
pme_enabled to the parent interface so that it could be called
independently based on xe/i915's pme_enabled() implementation.
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-3-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Introduce PME support for PME capable devices. Whether device is
PME capable is assessed during PCI probe routine. And the whether
PME is enabled for a specific context is assessed during the PM
runtime suspend call if the device is PME capable.
If the PME is enabled, HPDs can generate PME which in turn call
the runtime resume call and do the wakeup routines. Till now
the driver was relying on HPD polling to wakeup in case of any
HPDs. HPD polling can be avoided in platforms with PME support
and instead rely on this PCI PME for HPD induced wakeup.
v2: access functions for xe.pme.enabled status and clear the pme.
enabled in case of error in xe_pm_runtime_suspend()
v3: use the local pme_enabled flag to clear the device wakeup
incase of error
v4: call the devm_device_init_wakeup() only if device is PME
capable to avoid false wakeup capable reporting in platforms
where PME is not supported.
Squash the patch which handled the lockdep deadlock handling
Bspec: 52979, 52980, 68857, 68867, 68970
Assisted-by: GitHub_Copilot:claude-opus-5
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patch.msgid.link/20260915092518.639448-2-vinod.govindapillai@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Use EXPORT_SYMBOL_IF_KUNIT() instead of the regular EXPORT_SYMBOL() to
export the symbols to the kunit namespace. Otherwise, the symbols get
exported for all the kernel to see, and the corresponding
MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING") in the tests is
meaningless.
Fixes: 2eb9982ff1 ("drm/i915/kunit: Export link training and caps funcs for testing")
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260915160620.779372-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
During an atomic commit after all the MST stream CRTC state is computed
the driver ensures that the sum of TUs of all the streams on a given MST
topology link is within limits (63 for 8b10 and 64 for 128b132b). For a
disconnected stream the DRM MST core's BW verification doesn't ensure
this, because the topology state it uses for this is destroyed as soon
as the stream (i.e. MST connector/port) is disconnected. The driver
should keep the link state valid even for such disconnected streams, as
userspace may disable them one-by-one only in a deferred way. Ensure the
link's sum of TUs stays within limits in this case by simply reusing the
maximum link BPP limit from the stream's (i.e. CRTC's) old state.
The disconnection can happen either via the whole topology getting
disconnected or via only the given stream's port getting disconnected.
Check for both of these conditions separately, as a connector gets
unregistered after a link disconnect event only in a deferred way.
Cc: stable@vger.kernel.org # v6.10+
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16073
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16384
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260907174413.741851-2-imre.deak@intel.com
During an atomic commit after all the MST stream CRTC state is computed
the driver ensures that the FEC is configured the same way (enabled or
disabled) for all the streams on a given MST topology's link.
drm_dp_mst_port_downstream_of_parent() used to determine if a stream is
downstream of an MST port will return false if the whole topology is
disconnected, since in that case it can't verify that the port/
parent_port passed to it is in the given MST topology. This is a problem
during the above FEC configuration check, since
intel_dp_mst_check_dsc_change()->get_pipes_downstream_of_mst_ports()
will not return all the stream CRTCs/pipes for the topology as expected.
Since passing parent_port==NULL to get_pipes_downstream_of_mst_port()
is meant to return all the streams for the given topology (i.e. mst_mgr)
skip checking if an MST port is downstream of a parent port in this
case.
This fixes a problem where the FEC configuration check explained above
failed to ensure that all streams' FEC is configured the same way if the
topology was disconnected, leading to a FEC state mismatch error.
Cc: stable@vger.kernel.org # v6.10+
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16073
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16384
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260907174413.741851-1-imre.deak@intel.com
The eDP panel on the HP Pavilion Plus Laptop 14-ew1xxx advertises HBR3
while leaving the TPS4 support bit clear. The output however flickers, once
link is trained with HBR3.
Until commit 8c9006283e ("Revert "drm/i915/dp: Reject HBR3 when sink
doesn't support TPS4"") such sinks were capped at HBR2 by the TPS4 check
which incidentally kept this panel stable. That check was reverted because
other panels legitimately need HBR3 without advertising TPS4, and the
per-machine QUIRK_EDP_LIMIT_RATE_HBR2 was introduced to handle the affected
machines instead.
Add the machine to the list of devices that need the
QUIRK_EDP_LIMIT_RATE_HBR2.
Fixes: 8c9006283e ("Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"")
Reported-by: Annoy Cc <annoycc@gmail.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16743
Cc: <stable@vger.kernel.org> # v6.18+
Tested-by: Annoy Cc <annoycc@gmail.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://patch.msgid.link/20260907034555.2753846-1-ankit.k.nautiyal@intel.com
Add the INTEL_PLANE_CB_CSC_FF (fixed function CSC) color block as the
first stage for the HDR planes. This enables YUV-to-RGB color space
conversion on HDR planes via the color pipeline.
Also in icl_program_input_csc(), account for the color pipeline
programming, in addition to FB format.
v2:
- Increase MAX_COLOROP to 5 (Sashiko)
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260902075417.656673-10-chaitanya.kumar.borah@intel.com
Move HDR plane post-CSC LUT programming to improve code organization.
While at it, remove the segment 0 index register writes as it is not
currently programmed.
Signed-off-by: Pranay Samala <pranay.samala@intel.com>
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260902075417.656673-7-chaitanya.kumar.borah@intel.com
Extend the SDR plane color pipeline to post-CSC 1D LUT block.
v2:
- In preparation of a simple pipeline
[YUV Full/Limited -> RGB] -> [1D LUT]
Drop pre-CSC LUT from the pipeline as it has no use in a YUV -> RGB
pipeline. This makes the pipeline simple since the block lies between
the YUV range correct block and Fixed function CSC. It can be added back
when [RGB709 -> RGB2020] capability is added. Then it can be used for
linearization.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260902075417.656673-6-chaitanya.kumar.borah@intel.com
When a color pipeline is active, program the SDR plane fixed-function
CSC based on the Fixed Matrix Colorop's state. Re-use the existing plane
state variables for color_range and color_encoding. Track the bypass state
explicitly as a boolean since bypass is managed separately from the
FIXED_MATRIX enum value in the colorop framework. Keep the programming
based on color_encoding/color_range legacy properties intact.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260902075417.656673-5-chaitanya.kumar.borah@intel.com
Add early return for non-YUV formats and hoist the duplicated
color_range check out of the if/else branches. No functional change.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260902075417.656673-4-chaitanya.kumar.borah@intel.com
Extract the input CSC and YUV range correction logic from
glk_plane_color_ctl() into a dedicated glk_plane_color_ctl_input_csc()
helper. No functional change.
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260902075417.656673-3-chaitanya.kumar.borah@intel.com
Add the fixed-function CSC block to color pipeline in SDR planes
as a DRM_COLOROP_FIXED_MATRIX colorop.
v2:
- s/DRM_COLOROP_FM_YCBCR2020_FULL_RGB_NC/
DRM_COLOROP_FM_YCBCR2020_NC_FULL_RGB
- Inline icl_is_hdr_plane() instead of storing in local variable
v3:
- In preparation of a simple pipeline
[YUV Full/Limited -> RGB]
Make the Fixed Matrix ColorOp support Limited Range enums
(DRM_COLOROP_FM_YCBCRXXX_LIMITED_RGB) too.
- Therefore s/sdr_plane_pipeline/sdr_plane_yuv_pipeline
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260902075417.656673-2-chaitanya.kumar.borah@intel.com
Selective fetch is dropped while pipe CRC is active, and the planes keep
their SEL_FETCH_PLANE_CTL / SEL_FETCH_CUR_CTL enable bit set in hardware
over that. A plane disabled while selective fetch is off never gets the
bit cleared, as the disable path is guarded by enable_psr2_sel_fetch.
Once selective fetch comes back the hardware resumes fetching for a
plane that is no longer enabled and keeps its DDB range reserved.
Clear the bits as selective fetch is turned off instead. Atomic check
has both the old and the new crtc state, so record the transition there
and let the plane and cursor arm paths write the registers to 0 for that
commit.
v2: Drop the old_crtc_state->hw.active check. [Jouni]
Fixes: b1f5279b59 ("drm/i915/psr: Move plane sel fetch configuration into plane source files")
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8739
Assisted-by: Copilot:Claude-Opus-5
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260909110332.3528029-3-nemesa.garg@intel.com
This reverts commit 7f1172a2ac.
This commit replaced the crtc_state->enable_psr2_sel_fetch guard in
icl_plane_disable_sel_fetch_arm() and i9xx_cursor_disable_sel_fetch_arm()
with HAS_PSR2_SEL_FETCH(). This is a display version check and
says nothing about the pipe, so every plane and cursor disable on a
display 12+ platform started writing SEL_FETCH_PLANE_CTL() /
SEL_FETCH_CUR_CTL(), including on pipes that do not implement them.
It shows up as an unclaimed register access on pipes driving HDMI where
selective fetch was never enabled.
The stale selective fetch enable bit that commit addressed is handled
in the next patch.
Fixes: 7f1172a2ac ("drm/i915/display: Clear SEL_FETCH_PLANE_CTL on plane disable")
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16876
Cc: stable@vger.kernel.org
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260909110332.3528029-2-nemesa.garg@intel.com
Sysfb drivers currently use the given display mode for looking up the
panel orientation. But the look-up table stores the native geometry of
the panels, so the lookup fails if the current mode sizes differs.
Get the panel's native geometry with drm_edid_detect_panel_size() from
the EDID and use it for looking up the panel orientation.
v2:
- ofdrm: validate EDID header before using it (Sashiko)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-4-tzimmermann@suse.de
Add drm_edid_detect_panel_size() to extract the panel's preferred
display resolution from a given EDID. Required for setting up DRM's
panel orientation quirks in sysfb drivers.
v4:
- fix test for EDID PTD (Jani)
v3:
- mention use case in documentation (Jani)
- use is_detailed_timing_descriptor() (Jani)
- rename helper to drm_edid_detect_panel_size()
v2:
- handle EDID without pixel timing descriptor (Sashiko)
- fix checks for width and height pointers
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-3-tzimmermann@suse.de
The Lenovo D330 is a notebook with detachable display. The display
is installed in landscape orientation, but the display mode is in
portrait orientation. By default, the display output is rotated to
the left by 90°.
The sysfb quirk breaks the display by swapping display width and
height; and thus mixing up the display geometry. Fix this by keeping
the display as-is. The sysfb DRM drivers, usually efidrm, will pick
the correct panel orientation for the display.
The exact behavior might depend on the version of the BIOS release,
but the exact version numbers of broken and good releases are unknown.
Users are advised to update to the latest firmware.
Tested on a Lenovo D330-10IGM IdeaPad with firmware 8NCN43WW.
v3:
- mention possible dependency on BIOS release in commit description
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20260904090850.43060-2-tzimmermann@suse.de
We lost the proper display reset deadlock handling in
commit d59cf7bb73 ("drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence").
Currently the only thing that eventually breaks the deadlock is the
10 second fence timeout, which is very slow.
I tried to essentially restore the previous mechanism via a custom
dma_fence in
https://lore.kernel.org/intel-gfx/20260408233458.22666-6-ville.syrjala@linux.intel.com/
but Christian didn't want it.
The ideal solution would be to allow the reset time modesets to proceed
ahead of any already queued atomic commits, but that is quite involved
since we need to be able to track the already committed (to the
hardware) atomic states in addition to the userspace queued atomic states.
Years ago I did implement something like that in
https://lore.kernel.org/intel-gfx/20170629134948.5614-1-ville.syrjala@linux.intel.com/
but Sima didn't want it.
In order to get rid of the dependency on the timeout, and make things
faster, let's just effectively revert the remainders of
commit 9db529aac9 ("drm/i915: More surgically unbreak the modeset vs reset deadlock").
The upside is that the reset is fast again, but the downside is that
we now do a full wedge on all display resets, which will also kill
innocent batches. But perhaps no one really cares since this is
currently only needed for old pre-g4x hardware. But if anyone has plans on
using eg. FLR as a backup GPU reset on new hardware then we probably need
to come up with something better...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260903130116.19089-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
The calc_allowed_config_filter() function passes the return value of
iter_pos_to_idx() directly to BIT(), but the helper can return -1 for
an invalid iterator.
The iterator already rejects negative indices before doing a
configuration, so this should not matter in normal flows. In any
case, for robustness, check the index explicitly and warn if it is
negative, avoiding an undefined shift.
Fixes: 39e30bdf2f ("drm/i915/dp_link_caps: Add link configuration iterator")
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patch.msgid.link/20260908100659.113555-1-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
