This introduces and uses a variable id which is just uninitialized.
What really needs to be used is the scaler_id.
Fixes: 73309ed9d5 ("drm/i915/display: WA_14011503117")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Link: https://lore.kernel.org/r/20250806030856.3514127-1-suraj.kandpal@intel.com
Mask the ERR_FATAL_MASK before scaler initialization.
After enabling the scaler and waiting for one frame,
unmask the previously masked bits, PS_ECC and
ERR_FATAL_MASK
Unmasking of ERR_FATAL_MASK bit is use for
validation purpose. There is no functional
impact.
v2: Remove intel_display_need_wa[Jani]
Optimize the ecc_unmask call[Animesh]
v3: Add intel_display_wa[Jani]
Signed-off-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250801125835.2337614-1-nemesa.garg@intel.com
It has been observed that during `xe_display_pm_suspend()` execution,
an HPD interrupt can still be triggered, resulting in `dig_port_work`
being scheduled. The issue arises when this work executes after
`xe_display_pm_suspend_late()`, by which time the display is fully
suspended.
This can lead to errors such as "DC state mismatch", as the dig_port
work accesses display resources that are no longer available or
powered.
To address this, introduce 'intel_encoder_block_all_hpds' and
'intel_encoder_unblock_all_hpds' functions, which iterate over all
encoders and block/unblock HPD respectively.
These are used to:
- Block HPD IRQs before calling 'intel_hpd_cancel_work' in suspend
and shutdown
- Unblock HPD IRQs after 'intel_hpd_init' in resume
This will prevent 'dig_port_work' being scheduled during display
suspend.
Continuation of previous patch discussion:
https://patchwork.freedesktop.org/patch/663964/
Changes in v2:
- Add 'intel_encoder_block_all_hpds' to 'xe_display_pm_shutdown'.(Imre
Deak)
- Add 'intel_hpd_cancel_work' to 'xe_display_fini_early' to cancel
any HPD pending work at late driver removal. (Imre Deak)
Changes in v3:
- Move 'intel_encoder_block_all_hpds' after intel_dp_mst_suspend
in 'xe_display_pm_shutdown'.(Imre Deak)
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250724083928.2298199-1-dibin.moolakadan.subrahmanian@intel.com
Display has switched to its own workqueue, no longer using
xe->unordered_wq.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250731111214.1130130-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use recommended values as per wa_14021694213 to compare with the
calculated value and choose minimum of them.
v2: corrected checkpatch warning and retain the restriction for
min_hblank (Jani)
v3: use calculated value to compare with recomended value and choose
minimum of them (Imre)
v4: As driver supported min bpc is 8, omit the condition check for
bpc6 with ycbcr420. Added a note for the same (Imre)
v5: Add a warn for the unexpected case of 6bpc + uhbr + ycbcr420
v6: Reworded the comments and check fo anything < compressed bpp 8(Imre)
v7: Fix checkpatch warning. (Ankit)
Bspec: 74379
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250730-min_hblank-v7-1-179360220ced@intel.com
There is an extraneous space before a newline in a drm_dbg_kms message.
Remove the space.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Link: https://lore.kernel.org/r/20250801164658.2438212-1-colin.i.king@gmail.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
As per the wa_18038517565, we need to disable FBC compressor
clock gating before enabling FBC and enable after disabling
FBC. Placing the enabling of clock gating in the fbc deactivate
function can make the above wa logic go wrong in case of
frontbuffer rendering FBC mechanism. FBC deactivate can get
called during fb invalidate and then the corresponding FBC
activate can get called without properly disabling the clock
gating and can result in compression stalled. So move the
enable clock gating at the end of one FBC session after FBC
is completely disabled for a pipe.
Bspec: 74212, 72197, 69741, 65555
Fixes: 010363c461 ("drm/i915/display: implement wa_18038517565")
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20250729124648.288497-1-vinod.govindapillai@intel.com
Let Potential update error just be a log instead of a big error
we already have Atomic Update error log which shouts out if
something really goes wrong.
--v2
-Fix typo in commit message [Mitul]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Link: https://lore.kernel.org/r/20250724102954.2573715-1-suraj.kandpal@intel.com
Declarations for both intel_io_mmio_fw_write and intel_io_reg_write
were added with commit 01389846f7 ("drm/i915: Plumb 'dsb' all way to
the plane hooks"), but they never got used. Let's remove them.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Link: https://lore.kernel.org/r/20250717-drop-unused-intel_io-declarations-v1-1-bdea2c749571@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
The Fixed: commit below overlooked the fact that
intel_dp_link_train_all_phys() is only used for non-UHBR link rates, but
intel_dp_stop_link_train() is used for both non-UHBR and UHBR link
rates. Hence, after removing the disabling of the training pattern from
intel_dp_stop_link_train(), the commit missed adding this back to the
end of UHBR link training in intel_dp_128b132b_link_train(). This left
the sink in link training mode at the end of an UHBR rate link training.
Fix things by disabling the training pattern at the end of UHBR link
training as well.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 11fab5a2a1 ("drm/i915/dp: Clear DPCD training pattern before transmitting the idle pattern")
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250724182900.160891-1-imre.deak@intel.com
Selecting an option which depends on other options only works if the
dependencies are guaranteed to be selected (as these dependencies will
not be automatically selected). CONFIG_DRM_KUNIT_TEST depends on DRM,
MMU and KUNIT the first two of which are guaranteed to be selected for
i915, but the last one is not. Hence, selecting CONFIG_DRM_KUNIT_TEST in
i915 debug builds may result in CONFIG_DRM_KUNIT_TEST being selected
without the CONFIG_KUNIT dependency being selected. This causes at least
the following compile error:
drivers/gpu/drm/tests/drm_bridge_test.c: In function ‘drm_test_bridge_alloc_init’:
drivers/gpu/drm/tests/drm_bridge_test.c:449:21: error: implicit declaration of function ‘kunit_device_register’; did you mean ‘root_device_register’? [-Werror=implicit-function-declaration]
449 | priv->dev = kunit_device_register(test, "drm-bridge-dev");
Fix the above by selecting CONFIG_DRM_KUNIT_TEST only if CONFIG_KUNIT is
also selected.
Fixes: 17133255a3 ("drm/i915: replace DRM_DEBUG_SELFTEST with DRM_KUNIT_TEST")
Cc: Ruben Wauters <rubenru09@aol.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250724090237.92040-1-imre.deak@intel.com
dma_fence_wait_timeout returns a long type but the driver is
only using the lower 32 bits of the retval and discarding the
upper 32 bits.
This is particularly problematic if there are already signalled
or stub fences on some of the hw planes. In this case the
dma_fence_wait_timeout function will immediately return with
timeout value MAX_SCHEDULE_TIMEOUT (0x7fffffffffffffff) since
the fence is already signalled. If the driver only uses the lower
32 bits of this return value then it'll interpret it as an error
code (0xFFFFFFFF or (-1)) and skip the wait on the remaining fences.
This issue was first observed in the xe driver with the Android
compositor where the GPU composited layer was not properly waited
on when there were stub fences in other overlay planes resulting in
visual artifacts.
Fixes: d59cf7bb73 ("drm/i915/display: Use dma_fence interfaces instead of i915_sw_fence")
Signed-off-by: Aakash Deep Sarkar <aakash.deep.sarkar@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250708074540.1948068-1-aakash.deep.sarkar@intel.com
According to C10 VDR Register programming sequence we need set
C10_VDR_CTRL_MSGBUS_ACCESS before accessing PHY internal registers from
MsgBus.
v2: set C10_VDR_CTRL_MSGBUS_ACCESS once for all owned lanes
Bspec: 68962
Fixes: 9dc619680d ("drm/i915/display: Add function to configure LFPS sending")
Suggested-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250722125618.1842615-5-jouni.hogander@intel.com
Ensure phy is accessible on lfps configuration by adding
intel_cx0_phy_transaction_begin/end around it.
Fixes: 9dc619680d ("drm/i915/display: Add function to configure LFPS sending")
Suggested-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250722125618.1842615-4-jouni.hogander@intel.com
Currently we are always calling intel_cx0_get_owned_lane_mask when
intel_lnl_mac_transmit_lfps is called. Avoid this in cases where it's not
needed.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250722125618.1842615-3-jouni.hogander@intel.com
We are seeing "dmesg-warn/abort - *ERROR* PHY * failed after 3 retries"
since we started configuring LFPS sending. According to Bspec Configuring
LFPS sending is needed only when using AUXLess ALPM. This patch avoids
these failures by configuring LFPS sending only when using AUXLess ALPM.
Bspec: 68849
Fixes: 9dc619680d ("drm/i915/display: Add function to configure LFPS sending")
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250722125618.1842615-2-jouni.hogander@intel.com
DRM_DEBUG_SELFTEST was removed in commit fc8d29e298 (drm: selftest:
convert drm_mm selftest to KUnit) and all functions under it were
converted to KUnit, under the DRM_KUNIT_TEST option
This conversion however did not occur in the Kconfig.debug file in the
i915 directory.
This patch replaces the select for DRM_DEBUG_SELFTEST, an option that no
longer exists, with the correct select, DRM_KUNIT_TEST.
Signed-off-by: Ruben Wauters <rubenru09@aol.com>
Link: https://lore.kernel.org/r/20250701115511.5445-1-rubenru09@aol.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Add new module parameter enable_panel_replay. This can be used to
enable/disable Panel Replay. 0=disabled, 1=enabled. -1=use per-chip default
(default).
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250715105509.4146806-4-jouni.hogander@intel.com
Current approach is that Early Transport is disabled in case enable_psr
module parameter is set. Let's ignore enable_psr parameter when choosing if
Early Transport can be used.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250715105509.4146806-2-jouni.hogander@intel.com
The *_plane_ctl() functions only consider the state of the
plane (the state of the crtc is handled by the corresponding
*_plane_ctl_crtc()), and thus they don't need the crtc_state
at all. Don't pass it in.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250717171353.23090-7-ville.syrjala@linux.intel.com
Replace the open coded vma mm node stuff in intel_dpt_offset()
with i915_vma_offset(). This will also include the VT-d guard
in the result. Granted that should always be 0 for DPT, but
it seems prudent to include that in our DPT vma offset check
anyway.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250717171353.23090-5-ville.syrjala@linux.intel.com
Currently we pre-compute the plane surface/base address
partially (only for cursor_needs_physical cases) in
intel_plane_pin_fb() and finish the calculation in the
plane->update_arm(). Let's just precompute the whole thing
instead.
One benefit is that we get rid of all the vma offset stuff
from the low level plane code. Another use I have in mind
is including the surface address in the plane tracepoints,
which should make it easier to analyze display faults.
v2: Deal with xe reuse_vma() hacks
v3: use intel_plane_ggtt_offset() still in reuse_vma()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250717203216.31258-1-ville.syrjala@linux.intel.com
GLK doesn't use the DSI C clock at all, no need to program
the divider for it. Bspec even says: "Do not program this field".
However looks like some firmware versions program this and
some do not. In order to avoid bogus fastset mismatches
we should also filter it out during readout.
v2: Clear all the DSI C clock bits during readout (Jani)
Adjust platform checks for new style, and add
has_dsic_clock() while at it.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250718112928.27669-1-ville.syrjala@linux.intel.com
All platforms are capable of explicitly transmitting the idle
pattern. Implement it for everyone (so far it as implemented
only for HSW+).
The immediate benefit is that we gain the possibility of
implementing the POST_LT_ADJ_REQ sequence for all platforms.
Another potential future use would be a pseudo port sync mode on
pre-BDW where we attempt to sync up multiple ports/pipes by trying
to turn on the transcoders at the same time, and switching the
links to normal pixel transmission at the same time.
I'm not 100% sure the hardware is guaranteed to transmit the
required number of idle patterns (5) when switching away from
training pattern (either via explicit idle pattern, or straight
to the normal pixel output). Would be nice to confirm that at
some point, but for now let's assume it happens correctly in
both cases.
v2: Elaborate a bit more on the min required idle patterns
Tested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-7-ville.syrjala@linux.intel.com
In order to implement the POST_LT_ADJ_REQ sequence we need to
know whether the sink actually requested a changed to the
vswing/pre-emph values.
Tested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-5-ville.syrjala@linux.intel.com
We are supposed to switch off the training pattern in DPCD before
we start transmitting the idle pattern. For LTTPRs we do that
correctly, but for the sink DPRX we only do this correctly
for some platforms.
On pre-HSW (where we don't implement the .set_idle_link_train()
hook), we directly switch from transmitting the training pattern
to normal pixel transmission (the hardware should hopefully
guarantee that the minimum number of required idle patters will
be transmitted during this transition). The DPCD write correctly
precedes the actual switch away from the training pattern.
For HSW+ we start transmitting the idle pattern earlier, and only
switch off the DPCD training pattern after we switch from the idle
pattern to normal pixel transmission. Adjust the code to disable
the DPCD training pattern before we start transmitting the idle
pattern.
v2: Tweak the commit message a bit
Tested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-4-ville.syrjala@linux.intel.com
For some reason we are switching over to the idle pattern before
disabling the DP port on pre-hsw. AFAICS this has never been part
of the documented sequence (and on hsw+ the spec explicitly says
not to do this). Get rid of it.
The code goes all the way back to commit 5eb08b69f5 ("drm/i915: enable
DisplayPort support on IGDNG"), and it was accompanied by a 17ms delay
which got changed to vbl wait in commit ab527efc2f ("drm/i915: use
wait_for_vblank instead of msleep(17)"), and was later completely removed
in commit 93c9c19b3d ("drm/i915: remove unexplained vblank wait in
the DP off code").
Smoke tested on g4x/snb/chv.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
On g4x we currently use the 96MHz non-SSC refclk, which can't actually
generate an exact 2.7 Gbps link rate. In practice we end up with 2.688
Gbps which seems to be close enough to actually work, but link training
is currently failing due to miscalculating the DP_LINK_BW value (we
calcualte it directly from port_clock which reflects the actual PLL
outpout frequency).
Ideas how to fix this:
- nudge port_clock back up to 270000 during PLL computation/readout
- track port_clock and the nominal link rate separately so they might
differ a bit
- switch to the 100MHz refclk, but that one should be SSC so perhaps
not something we want
While we ponder about a better solution apply some band aid to the
immediate issue of miscalculated DP_LINK_BW value. With this
I can again use 2.7 Gbps link rate on g4x.
Cc: stable@vger.kernel.org
Fixes: 665a7b0409 ("drm/i915: Feed the DPLL output freq back into crtc_state")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
As per Wa_16025573575 for PTL/WCL, set the GPIO masks bit before starting
bit-bashing and maintain value through the bit-bashing sequence. After the
bit-bashing sequence is done, clear the GPIO masks bits.
v2:
-Use new helper for display workarounds. (Jani)
-Use a separate if-block for the workaround. (Gustavo)
v3:
-Document the workaround details in intel_display_wa.c
-Extend the workaround to WCL too. (Gustavo)
v4:
-Fix the platform check. (Gustavo)
-Avoid read when preserve bits are 0. (Gustavo)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250715142211.3145299-1-ankit.k.nautiyal@intel.com
Introduce a generic helper to check display workarounds using an enum.
Convert Wa_16023588340 to use the new interface, simplifying WA checks
and making future additions easier.
v2: Use drm_WARN instead of MISSING_CASE and simplify intel_display_wa
macro. (Jani)
v3: Print Missing wa number, instead of enum value. (Gustavo, Jani)
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://lore.kernel.org/r/20250711041901.1607823-2-ankit.k.nautiyal@intel.com
The !in_atomic() check in _wait_for_atomic() triggers on PREEMPT_RT
because the uncore::lock is a spinlock_t and does not disable
preemption or interrupts.
Changing the uncore:lock to a raw_spinlock_t doubles the worst case
latency on an otherwise idle testbox during testing.
Ignore _WAIT_FOR_ATOMIC_CHECK() on PREEMPT_RT.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Link: https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20250714153954.629393-4-bigeasy@linutronix.de
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Commit a40c5d727b ("drm/dp: Change AUX DPCD probe address from
DPCD_REV to LANE0_1_STATUS") stopped using the DPCD_REV register for
DPCD probing, since this results in link training failures at least when
using an Intel Barlow Ridge TBT hub at UHBR link rates (the
DP_INTRA_HOP_AUX_REPLY_INDICATION never getting cleared after the failed
link training). Since accessing DPCD_REV during link training is
prohibited by the DP Standard, LANE0_1_STATUS (0x202) was used instead,
as it falls within the Standard's valid register address range
(0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) and it fixed the link
training on the above TBT hub.
However, reading the LANE0_1_STATUS register also has a side-effect at
least on a Novatek eDP panel, as reported on the Closes: link below,
resulting in screen flickering on that panel. One clear side-effect when
doing the 1-byte probe reads from LANE0_1_STATUS during link training
before reading out the full 6 byte link status starting at the same
address is that the panel will report the link training as completed
with voltage swing 0. This is different from the normal, flicker-free
scenario when no DPCD probing is done, the panel reporting the link
training complete with voltage swing 2.
Using the TRAINING_PATTERN_SET register for DPCD probing doesn't have
the above side-effect, the panel will link train with voltage swing 2 as
expected and it will stay flicker-free. This register is also in the
above valid register range and is unlikely to have a side-effect as that
of LANE0_1_STATUS: Reading LANE0_1_STATUS is part of the link training
CR/EQ sequences and so it may cause a state change in the sink - even if
inadvertently as I suspect in the case of the above Novatek panel. As
opposed to this, reading TRAINING_PATTERN_SET is not part of the link
training sequence (it must be only written once at the beginning of the
CR/EQ sequences), so it's unlikely to cause any state change in the
sink.
As a side-note, this Novatek panel also lacks support for TPS3, while
claiming support for HBR2, which violates the DP Standard (the Standard
mandating TPS3 for HBR2).
Besides the Novatek panel (PSR 1), which this change fixes, I also
verified the change on a Samsung (PSR 1) and an Analogix (PSR 2) eDP
panel as well as on the Intel Barlow Ridge TBT hub.
Note that in the drm-tip tree (targeting the v6.17 kernel version) the
i915 and xe drivers keep DPCD probing enabled only for the panel known
to require this (HP ZR24w), hence those drivers in drm-tip are not
affected by the above problem.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Fixes: a40c5d727b ("drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS")
Reported-and-tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14558
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250708212331.112898-1-imre.deak@intel.com
Some ICL/TGL platforms with combo PHY ports suffer from signal integrity
issues at HBR3. While certain systems include a Parade PS8461 mux to
mitigate this, its presence cannot be reliably detected. Furthermore,
broken or missing VBT entries make it unsafe to rely on VBT for enforcing
link rate limits.
To address this introduce a device specific quirk to cap the eDP link rate
to HBR2 (540000 kHz). This will override any higher advertised rates from
the sink or DPCD for specific devices.
Currently, the quirk is added for Dell XPS 13 7390 2-in-1 which is reported
in gitlab issue #5969 [1].
[1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969
v2: Align the quirk with the intended quirk name and refactor the
condition to use min(). (Jani)
v3: Use condition `rate > 540000`. Drop extra parentheses. (Ville)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250710052041.1238567-3-ankit.k.nautiyal@intel.com
This reverts commit 584cf613c2.
Commit 584cf613c2 ("drm/i915/dp: Reject HBR3 when sink doesn't support
TPS4") introduced a blanket rejection of HBR3 link rate when the sink does
not support TPS4.
While this was intended to address instability observed on certain eDP
panels [1], there seem to be edp panels that do not follow the
specification. These eDP panels do not advertise TPS4 support, but require
HBR3 to operate at their fixed native resolution [2].
As a result, the change causes blank screens on such panels. Apparently,
Windows driver does not enforce this restriction, and the issue is not seen
there.
Therefore, revert the commit to restore functionality for such panels,
and align behaviour with Windows driver.
[1] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/5969
[2] https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517
v2: Update the commit message with better justification. (Ville)
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14517
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250710052041.1238567-2-ankit.k.nautiyal@intel.com
