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>
Periodic AS SDP (skip frames) drives a Panel Replay panel down toward its
minimum refresh rate. It is a new, panel- and platform-sensitive behaviour,
so keep it opt-in rather than enabling it unconditionally.
Expose it as a per-device debugfs knob, enable_periodic_assdp, rather than a
module parameter. The behaviour is panel-specific, so the correct granularity
is per-device, not per-module. The knob is added through the intel_display_params
infrastructure (shared by i915 and xe) with a debugfs entry only. It defaults to
false (feature disabled); write 1 to the debugfs file to enable periodic AS SDP
at runtime.
Gate the feature at its single choke point, intel_pr_as_sdp_skip_frames():
returning a zero skip count when the knob is off makes both the PR_ALPM_CTL
programming (intel_alpm_configure_pr_as_sdp()) and the DC3co force-disable
predicate (intel_alpm_pr_as_sdp_skip_frames_enabled()) a no-op, so AS SDP
continues to be sent on every frame as before.
v2: Switch to debugfs entry and drop module param
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Tested-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Link: https://patch.msgid.link/20260909080810.2202879-5-uma.shankar@intel.com
The AS SDP skip-frame count is written to PR_ALPM_CTL only from
lnl_alpm_configure(), which runs from intel_psr_enable_locked() on a
Panel Replay disabled->enabled transition. VRR, however, can be enabled
and disabled seamlessly - without a modeset and without cycling Panel
Replay (intel_crtc_vrr_enabling()/disabling() in the pipe update path).
As a result, when a panel comes up with VRR off the non-zero skip count
is programmed, and when VRR is later turned on seamlessly PR stays
enabled, lnl_alpm_configure() is not re-invoked, and the stale skip
count is left in the register. This also leaves the coupled AS SDP
transmission / DC3CO idle-protocol bits inconsistent with the DC3co
state, which is recomputed on every commit.
Factor the PR_ALPM_CTL AS SDP programming out of lnl_alpm_configure()
into intel_alpm_configure_pr_as_sdp() and expose
intel_alpm_pr_as_sdp_update(), which recomputes those fields for the
current VRR state. Call it from the seamless VRR enable and disable
sites (non-modeset only; a modeset re-runs PR enable anyway) so the skip
counter always matches whether VRR is actively driving the refresh rate.
v2: Fixed Sashiko review comments
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Tested-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Link: https://patch.msgid.link/20260909080810.2202879-4-uma.shankar@intel.com
Periodic AS SDP (skip frames) relies on the AS SDP still being
transmitted while Panel Replay is active. DC3co uses the idle protocol
which suppresses AS SDP transmission entirely, so the two are mutually
exclusive: leaving DC3co enabled while skip frames is programmed breaks
the periodic AS SDP and the panel never sees the slower refresh.
Add intel_alpm_pr_as_sdp_skip_frames_enabled() as the single predicate
for "skip frames will be programmed" (mirroring the gating in
lnl_alpm_configure(), including that it only applies when VRR is not
active) and use it in intel_display_power_dc3co_compute() to force the
DC3co trigger to NONE. This drops the pipe onto the
DC_STATE_EN_UPTO_DC6 target instead of DC3co whenever skip frames is
active, without touching the DC state module parameter or the allowed
DC mask, and only for the skip-frame case.
v2: Fixed Sashiko review findings
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Tested-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Link: https://patch.msgid.link/20260909080810.2202879-3-uma.shankar@intel.com
When Panel Replay is active the transcoder timing generator runs at the
panel's maximum refresh rate. To drive the panel down to its minimum
refresh rate the Adaptive-Sync SDP (AS SDP) only needs to reach the panel
once per minimum-rate frame, so transmitting it on every (maximum-rate)
frame is redundant and shows up as repeated SDPs on the link.
Xe3p_LPD adds a HW skip-frame counter in PR_ALPM_CTL that lets the source
send a single AS SDP and then suppress it for a programmed number of
frames. Program this counter so that one AS SDP is followed by
(max_vrefresh / min_vrefresh - 1) idle frames, i.e. one AS SDP per
slowest panel frame, allowing the link to be driven down to as low as
1Hz when the hardware supports it.
The maximum and minimum refresh rates come from the panel's adaptive-sync
monitor range, so the skip count is a function of the sink's capabilities
and independent of the current content/flip rate. If the panel does not
advertise a usable range the skip counter is left at zero, i.e. the
feature is a no-op and AS SDP continues to be sent on every frame.
Periodic AS SDP drives the panel down to its minimum refresh rate on its
own, so it is only programmed when VRR is not actively driving the
refresh rate.
The skip-frame mechanism relies on the AS SDP still being transmitted
(just less often) while Panel Replay is active, so when a non-zero
skip-frame count is programmed both
PR_ALPM_CTL_AS_SDP_TRANSMISSION_IN_ACTIVE_DISABLE and
PR_ALPM_CTL_USE_DC3CO_IDLE_PROTOCOL are left cleared. The previous
behaviour (honouring disable_as_sdp_when_pr_active and the DC3CO idle
protocol) is retained for the non skip-frame case.
v3: Fixed Sashiko review findings
v2: Decoupled CMMRR dependency and using sink refresh rate range for
skip frame claculations. This addresses Dibin's review feedback as well.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Tested-by: Naladala Ramanaidu <ramanaidu.naladala@intel.com>
Link: https://patch.msgid.link/20260909080810.2202879-2-uma.shankar@intel.com
Do not send the vblank event when the page flip completes, but when
the vblank interrupt fires. Sending the vblank event at the wrong time
can break synchronization of the display update with the vblank period.
Use the vblank helper drm_crtc_vblank_atomic_flush(), which sets up
the vblank event accordingly. In case of an error, it still sends out
the vblank event immediately; thus not starving consumers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Yongbang Shi <shiyongbang@huawei.com>
Link: https://patch.msgid.link/20260827082915.61176-3-tzimmermann@suse.de
Let the kernel know if hibmc did not handle an interrupt. Allows
the kernel to detect spurious interrupts and maintain diagnostics.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Yongbang Shi <shiyongbang@huawei.com>
Link: https://patch.msgid.link/20260827082915.61176-2-tzimmermann@suse.de
Add support for using SN65DSI84 in single-link mode with output to LVDS
Channel B.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Esben Haabendal <esben@geanix.com>
Link: https://patch.msgid.link/20260831-ti-sn65dsi83-fixes-v5-2-e712765d6c4f@geanix.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Parse the optional 'data-lanes' device tree property to support
custom physical lane mapping configuration.
If no valid configuration is found, fall back to the default
lane map (0, 1, 2, 3) automatically and keep the driver running.
Lane mapping is mainly used for below scenarios:
1. Correct PCB lane swap and differential line routing crossover
without hardware changes;
2. Adapt mismatched lane pin definitions between SoC and eDP panel;
3. Support multiple panel hardware variants on the same board
by configuring data-lanes in device tree only.
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260828065153.590802-6-damon.ding@rock-chips.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Revert the change that made samsung,link-rate and samsung,lane-count
optional for Exynos DP. Add error checking to fail probe early if the
required DT properties are missing.
If these properties are missing, video_info->max_link_rate and
video_info->max_lane_count remain zero, and so do link_train.link_rate
and link_train.lane_count used in the subsequent link training flow,
resulting in link training failure.
There is no way at all a device can work without these properties.
Here is the code flow when either max_link_rate or max_lane_count is 0:
analogix_dp_commit()
-> analogix_dp_full_link_train(dp, max_lanes = 0, max_rate = 0)
analogix_dp_full_link_train(max_lanes, max_rate):
// Read sink capabilities via DPCD and sanitize them
link_rate = read_dpcd(DP_MAX_LINK_RATE); // >= 0x06 after fixup
lane_count = read_dpcd(DP_MAX_LANE_COUNT); // >= 1 after fixup
// Clamp by the limits from DT
if (link_rate > max_rate) // 0x06 > 0, always true
link_rate = max_rate; // link_rate = 0
if (lane_count > max_lanes) // 1 > 0, always true
lane_count = max_lanes; // lane_count = 0
// Configure TX with the zeroed values
set_link_bandwidth(link_rate = 0)
// writel() is only executed for bwtype == 0x06/0x0a,
// so LINK_BW_SET is never written and stays at
// reset value; phy_configure() gets link_rate = 0.
set_lane_count(lane_count = 0)
// writel(0, ANALOGIX_DP_LANE_COUNT_SET) enables 0 lanes;
// phy_configure() is called with lanes = 0.
// Program sink for link training
drm_dp_dpcd_write(DP_LINK_BW_SET, {link_rate = 0/lane_count = 0})
// DP spec requires link rate in {0x06, 0x0a, 0x14} and
// lane count in {1, 2, 4}. Writing zeros is illegal, so
// the sink cannot enter the training state.
// Training loop
for (lane = 0; lane < lane_count /* 0 */; lane++)
// loop body never executes; training_lane[] stays
// uninitialized and no training register is programmed
Since the sanitized sink values are always non-zero (link_rate >= 0x06,
lane_count >= 1), the clamping with a zero maximum unconditionally
forces the training parameters to zero. Clock recovery can never be
achieved, so link training fails deterministically.
Consequently, making these properties mandatory again cannot break
any existing device: a DT without them could never have worked in
the first place. Failing probe early with a clear error message is
more helpful than a silent link training failure at runtime.
Fixes: 0d0abd894e ("drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288")
Cc: stable@vger.kernel.org
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://patch.msgid.link/20260828065153.590802-4-damon.ding@rock-chips.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Add a generic helper function drm_dp_lane_count_is_valid() to check
if a DisplayPort lane count is valid. According to the DP specification,
only 1, 2, or 4 lanes are supported.
This helper avoids duplicating DP lane count validation logic across
individual DisplayPort drivers.
Suggested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://patch.msgid.link/20260828065153.590802-3-damon.ding@rock-chips.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Add data-lanes property support to the port@1 endpoint for physical
lane mapping configuration.
Lane mapping is mainly used for below scenarios:
1. Correct PCB lane swap and differential line routing crossover
without hardware changes;
2. Adapt mismatched lane pin definitions between SoC and eDP panel;
3. Support multiple panel hardware variants on the same board
by configuring data-lanes in device tree only.
Additionally, add data-lanes setting in Rockchip eDP DT node example
to show actual lane mapping usage.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://patch.msgid.link/20260828065153.590802-2-damon.ding@rock-chips.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
