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>
drm_crtc_init() creates the primary plane from a fixed format list
that includes ARGB8888. The display engine programs the primary plane
with DISPPLANE_32BPP_NO_ALPHA, so it does not support per-pixel alpha
and must not advertise alpha formats. Since commit 860e748bdd
("drm: ensure blend mode supported if pixel format with alpha exposed"),
drm_mode_config_validate() warns about this at probe time.
Replace drm_crtc_init() with a driver-owned primary plane that
advertises only XRGB8888. The plane is allocated by
drmm_universal_plane_alloc() and the "pixel blend mode" property is
not needed because no format with alpha is exposed.
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patch.msgid.link/20260903071149.423579-1-oushixiong1025@163.com
Device names for i2c_device_id are not OF compatibles and have a meaning
only for in-tree users (which there are no except the driver itself),
thus vendor prefix in this name is completely redundant.
It is actually a discouraged pattern because for OF platforms it allows
matching driver by I2C bus, instead of OF, thus hiding incomplete
way of obtaining driver match data (lack of i2c_get_match_data() usage).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260825143921.512966-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
parse_hdmi_amd_vsdb() was removed when HDMI FreeSync detection moved to
the common EDID parser, but its declaration and KUnit tests remained,
breaking modpost:
ERROR: modpost: "parse_hdmi_amd_vsdb" [...connector_test.ko] undefined!
Remove the stale declaration and the three dead test cases.
Fixes: f65198b3d0 ("drm/amd/display: Use HDMI FreeSync range from common EDID parser")
Cc: Alex Huang <Alex.Huang2@amd.com>
Cc: Mario Limonciello <superm1@kernel.org>
Assisted-by: Copilot:Claude-Opus-5
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260820142802.1342066-2-rodrigo.vivi@intel.com
'ad->card' was removed in commit 9af2c1d4f8 ("ASoC: ti: omap-hdmi:
remove unused *card"), but commit 699e5975e2 ("drm/omap: Report HDMI
hotplug events to the ASoC HDMI codec") moved that code line. These
commits were applied to different trees, and the merge was not quite
right: assignment to 'ad->card' from the latter commit was left in the
file, causing:
sound/soc/ti/omap-hdmi.c:408:11: error: ‘struct hdmi_audio_data’ has no member named ‘card’
Fix the issue by removing the line.
Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://lore.kernel.org/all/apbbvQSfUbzYRFaw@sirena.org.uk/
Fixes: 1ae7fe832c ("Merge drm/drm-next into drm-misc-next")
Reviewed-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Link: https://patch.msgid.link/20260903-omap-hdmi-fix-v1-1-b0447a1d35d5@ideasonboard.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
There is not much use of warning when port asks to override default
VS/PE since it is already logged. Remove drm_WARN() and child_device
from print_ddi_port() since drm_WARN() was the only user of it.
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260904123148.2165596-9-michal.grzelak@intel.com
Add accessor function for Combo to read requested table from VBT #57.
Parse the requested table and transform data into port's buffer.
Actual data is fully stored in the lowest byte although each entry is 4
bytes wide. Thus convert u32 into u8 and store the data.
For EHL, in cases when eDP encoder uses low vswing, choose 3rd table if
encoder supports HBR3. Otherwise use 2nd table for eDP using low vswing.
In cases when eDP encoder does not use low vswing, choose 2nd table if
encoder supports mode higher or including HBR2. Otherwise use 1st table
for eDP not using low vswing.
For external DP follow same path and use same indices as in eDP without
low vswing case.
For JSL, always use 1st table for external DP. For eDPs not using low
vswing use 1st table as well.
In cases when eDP encoder uses low vswing, choose 1st table if encoder
supports HBR3. When encoder supports HBR2 choose 3rd table. When
encoder supports modes lower than HBR2 choose 2nd table.
There are no changes to intel_ddi_dp_level() since selection of correct
row of intel_ddi_buf_trans_entry is same as when no override request has
been done.
Looking from other OSes, in case when encoder does not support DP we
could theoretically use 1st table. However, as of now, use default
tables.
v11->v12
- don't set vspeo->num_entries per PHY/platform
- check for low vswing eDP for EHL (Sashiko)
- reverse order of indices for JSL (Sashiko)
v10->v11
- initialize local variables at declaration block (Jani)
- branch with 'else` instead of initializing twice (Jani)
v9->v10
- call dedicated VS/PE-O vfunc
- drop deconstifying default tables (Suraj, Jani)
- cache `entries` into const field after data is overwritten (Jani)
v8->v9
- deconstify intel_ddi_buf_trans_entry
v6->v7
- handle VS/PE-O's VBT details in intel_bios_* functions (Jani)
- remove vspeo's cast to (void *) (Jani)
- call encoder->get_buf_trans() once (Jani)
- return NULL from intel_bios_get_* when using default (Jani)
- validate VS/PE-O in intel_bios.c (Jani)
- check devdata->vspeo if VS/PE-O was requested
- inline {jsl,ehl}_combo_get_vspeo_buf_trans()
- remove temporarily LT
v4->v5
- blend index computation with table parsing
- remove enums entirely
- add spaces around operators (Suraj)
- remove spaces after type casting (Suraj)
- remove INTEL_DISPLAY_STATE_WARN (Suraj)
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260907122742.2512901-1-michal.grzelak@intel.com
Add accessor functions for Snps to read requested table from VBT #57.
Parse the requested table and transform data into port's buffer.
Actual data is fully stored in the lowest byte although each entry is 4
bytes wide. Thus convert u32 into u8 and store the data.
For C20, use 6th table if encoder supports DP 2.0 or higher. Otherwise
use 5th table for DP.
For C20, tables 1-4 are not used at all and are most likely to be
zeroed. 5th table is used for any mode below DP 2.0 (exclusive). 6th
table is used for any mode above DP 2.0 (inclusive).
For C10, use 2nd table for external DP if encoder supports any mode
beyond or including HBR2. Use 1st table if external DP encoder supports
anything lower than HBR2. For eDP, use 4th table if encoder supports
HBR3. Otherwise use 3rd table for eDP.
For C10, 1st table is used for external DP with modes below HBR2
(exclusive). 2nd table is used for external DP with modes higher than
HBR2 (inclusive). 3rd table is used for eDP with modes lower than HBR3
(exclusive). 4th table is used for eDP with modes higher than HBR3
(inclusive).
Indices for other tables have not yet been observed to be used as of
now.
There are no changes to intel_ddi_dp_level() since selection of correct
row of intel_ddi_buf_trans_entry is same as when no override request has
been done.
v11->v12
- don't set vspeo->num_entries per PHY
- don't refer to 1st table as fallback for non-DP for C10 (Sashiko)
v10->v11
- remove no-longer-relevant check for NULL devdata (Jani)
- initialize local variables at declaration block (Jani)
- branch with 'else` instead of initializing twice (Jani)
- use blank line before 'return` (Jani)
v9->v10
- call dedicated VS/PE-O vfunc
- drop deconstifying default tables (Suraj, Jani)
- cache `entries` into const field after data is overwritten (Jani)
v8->v9
- init vspeo before using it
- deconstify intel_ddi_buf_trans_entry
v7->v8
- remove comments (Suraj)
- add check for LT (Suraj)
v6->v7
- handle VS/PE-O's VBT details in intel_bios_* functions (Jani)
- remove vspeo's cast to (void *) (Jani)
- check devdata->vspeo if VS/PE-O was requested
- call encoder->get_buf_trans() once (Jani)
- return NULL from intel_bios_get_* when using default (Jani)
- validate VS/PE-O in intel_bios.c (Jani)
- inline mtl_{c10,c20}_get_vspeo_buf_trans()
- remove temporarily LT
v4->v5
- blend index computation with table parsing
- remove enums entirely
- change funcs prefix from snps_ to mtl_ (Suraj)
- add spaces around operators (Suraj)
- remove spaces after type casting (Suraj)
- remove INTEL_DISPLAY_STATE_WARN (Suraj)
v3->v4
- stick to solely changing VBT data into current structures (Jani)
- move iterator declaration to declaration block (Suraj)
v2->v3
- remove unnecessary braces from if block (Suraj)
- return -EINVAL instead of -1 (Suraj)
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260904123148.2165596-7-michal.grzelak@intel.com
Choosing correct table for Vswing / Pre-emphasis Override is platform
specific. It also requires different checks that are already used for
choosing predefined tables.
Add new get_buf_trans_override() vfunc into intel_encoder returning
deparsed table from VBT#57. In next patches, set it inside already
present if-ladder from intel_ddi_buf_trans_init() instead of duplicating
it.
Note that get_buf_trans() cannot be overwritten since there are cases
when we need to rollback although VS/PE-O was requested, eg. DP is not
connected or feature is not yet implemented for the platform. Assume
that vfunc returns NULL on rollback and return predefined tables.
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260904123148.2165596-6-michal.grzelak@intel.com
Every devdata needs VS/PE-O dedicated buffers since each port can
request an override. Add intel_ddi_buf_trans{,_entry} pointers into
intel_bios_encoder_data.
Allocate struct intel_ddi_buf_trans{,_entry} for the port if VS/PE-O was
requested and is supported. Keep NULL in vspeo if any allocation failed
or VS/PE-O was not requested. It will be used later for checking if
override should actually take place.
Note that we theoretically could store intel_ddi_buf_trans_entry inside
`entries` field of newly allocated intel_ddi_buf_trans. However it will
be impossible to overwrite the buffer during intel_ddi_get_buf_trans()
without discarding const qualifier of `entries` field. This would
involve either void casting or deconstifying entries field and in turn
all predefined tables as well. Thus add a separate non-const qualified
field into intel_bios_encoder_data for the buffer, which after
overwriting will be promoted to be const qualified.
Deallocate the buffer as well as entries if requested.
v11->v12
- set vspeo->num_entries once (Sashiko)
- free allocated vspeo->entries (Sashiko)
v9->v10
- add separate non-const field for `entries` caching
- cache `entries` into const field after data is overwritten (Jani)
v4->v5
- set devdata->vspeo->num_entries in intel_bios.c
Signed-off-by: Michał Grzelak <michal.grzelak@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260904123148.2165596-5-michal.grzelak@intel.com
