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
drm/i915/display: Use the recomended min_hblank values
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)
drm/i915/fbc: fix the implementation of wa_18038517565
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.
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.
drm/i915/display: Remove unused declarations of intel_io_*
Declarations for both intel_io_mmio_fw_write and intel_io_reg_write
were added with commit 01389846f7d6 ("drm/i915: Plumb 'dsb' all way to
the plane hooks"), but they never got used. Let's remove them.
Imre Deak [Thu, 24 Jul 2025 18:29:00 +0000 (21:29 +0300)]
drm/i915/dp: Fix disabling training pattern at end of UHBR link training
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: 11fab5a2a1ad ("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
Imre Deak [Thu, 24 Jul 2025 09:02:37 +0000 (12:02 +0300)]
drm/i915: Fix selecting CONFIG_DRM_KUNIT_TEST in debug builds
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.
drm/i915/display: Fix dma_fence_wait_timeout() return value handling
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: d59cf7bb73f3c ("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
drm/i915/display: Write PHY_CMN1_CONTROL only when using AUXLess ALPM
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.
drm/i915: replace DRM_DEBUG_SELFTEST with DRM_KUNIT_TEST
DRM_DEBUG_SELFTEST was removed in commit fc8d29e298cf (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.
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).
drm/i915/psr: Do not disable Early Transport when enable_psr is set
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.
Ville Syrjälä [Thu, 17 Jul 2025 17:13:52 +0000 (20:13 +0300)]
drm/i915: Don't pass crtc_state to foo_plane_ctl() & co.
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.
Ville Syrjälä [Thu, 17 Jul 2025 17:13:50 +0000 (20:13 +0300)]
drm/i915: Use i915_vma_offset() in intel_dpt_offset()
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.
Ville Syrjälä [Thu, 17 Jul 2025 20:32:16 +0000 (23:32 +0300)]
drm/i915: Precompute plane SURF address
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()
Ville Syrjälä [Fri, 18 Jul 2025 11:29:28 +0000 (14:29 +0300)]
drm/i915/dsi: Don't set/read the DSI C clock divider on GLK
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.
Ville Syrjälä [Thu, 10 Jul 2025 20:17:17 +0000 (23:17 +0300)]
drm/i915/dp: Implement .set_idle_link_train() for everyone
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
Ville Syrjälä [Thu, 10 Jul 2025 20:17:14 +0000 (23:17 +0300)]
drm/i915/dp: Clear DPCD training pattern before transmitting the idle pattern
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.
Ville Syrjälä [Thu, 10 Jul 2025 20:17:13 +0000 (23:17 +0300)]
drm/i915/dp: Don't switch to idle pattern before disable on pre-hsw
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 5eb08b69f510 ("drm/i915: enable
DisplayPort support on IGDNG"), and it was accompanied by a 17ms delay
which got changed to vbl wait in commit ab527efc2fea ("drm/i915: use
wait_for_vblank instead of msleep(17)"), and was later completely removed
in commit 93c9c19b3d25 ("drm/i915: remove unexplained vblank wait in
the DP off code").
Ville Syrjälä [Thu, 10 Jul 2025 20:17:12 +0000 (23:17 +0300)]
drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4x
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.
drm/i915/gmbus: Add Wa_16025573575 for PTL/WCL for bit-bashing
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)
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)
Sebastian Andrzej Siewior [Mon, 14 Jul 2025 15:39:48 +0000 (17:39 +0200)]
drm/i915: Don't check for atomic context on PREEMPT_RT
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.
Imre Deak [Tue, 8 Jul 2025 21:23:31 +0000 (00:23 +0300)]
drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET
Commit a40c5d727b81 ("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: a40c5d727b81 ("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
drm/i915/dp: Add device specific quirk to limit eDP rate to HBR2
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].
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
Revert "drm/i915/dp: Reject HBR3 when sink doesn't support TPS4"
This reverts commit 584cf613c24a4250d9be4819efc841aa2624d5b6.
Commit 584cf613c24a ("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.
We only support resolution up to 4k for single pipe when using
YUV420 format so we prune these modes and restrict the plane size
at src. This is because pipe scaling will not support YUV420 scaling
for hwidth > 4096.
--v2
-Use output format to check [Ville]
-Add Bspec references
-Modify commit messge to point to why this is needed
--v3
-Use a function skl_scaler_mode_valid which is routed throug
intel_pfit_mode_valid [Ville]
-Combine the check conditons [Jonathan]
--v4
-mode_valid functions should return drm_mode_status [Jani]
Sequence 2 - MIPI_SEQ_INIT_OTP
GPIO index 9, source 0, set 0 (0x00)
Delay: 50000 us
GPIO index 9, source 0, set 1 (0x01)
Delay: 6000 us
GPIO index 9, source 0, set 0 (0x00)
Delay: 6000 us
GPIO index 9, source 0, set 1 (0x01)
Delay: 25000 us
Send DCS: Port A, VC 0, LP, Type 39, Length 5, Data ff aa 55 a5 80
Send DCS: Port A, VC 0, LP, Type 39, Length 3, Data 6f 11 00
...
Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 29
Delay: 120000 us
Sequence 4 - MIPI_SEQ_DISPLAY_OFF
Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 28
Delay: 105000 us
Send DCS: Port A, VC 0, LP, Type 05, Length 2, Data 10 00
Delay: 10000 us
Sequence 5 - MIPI_SEQ_ASSERT_RESET
Delay: 10000 us
GPIO index 9, source 0, set 0 (0x00)
Notice how there is no MIPI_SEQ_DEASSERT_RESET, instead the deassert
is done at the beginning of MIPI_SEQ_INIT_OTP, which is exactly what
the fixup from vlv_fixup_mipi_sequences() fixes up.
Extend it to also apply to v2 sequences, this fixes the panel not working
on the Acer Iconia One 8 A1-840.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14605 Signed-off-by: Hans de Goede <hansg@kernel.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250703143824.7121-1-hansg@kernel.org Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Jani Nikula [Thu, 26 Jun 2025 19:26:32 +0000 (22:26 +0300)]
drm/i915/power: use intel_de_wait_for_clear() instead of wait_for()
Prefer the register read specific wait function over i915 wait_for_us().
The existing condition is quite complicated. Simplify by checking for
requesters first, and determine timeout based on that. Refresh
requesters in case of timeouts, should one have popped up during the
wait. The downside is that this does not cut the wait short if
requesters show up *during* the wait, but we're talking about 1 ms so
shouldn't be an issue.
v2: Refresh requesters only if there were none before (Imre)
Jani Nikula [Thu, 26 Jun 2025 10:16:36 +0000 (13:16 +0300)]
drm/i915/display: drop a number of dependencies on i915_drv.h
With the switch to an unordered workqueue dedicated to display, we've
stopped using struct drm_i915_private in a number of places, and can
drop the dependencies on i915_drv.h.
Lucas De Marchi [Fri, 27 Jun 2025 20:30:34 +0000 (13:30 -0700)]
drm/xe: Fix conflicting intel_pcode_* symbols
If CONFIG_DRM_XE_DISPLAY is set, the xe module can only be built as
module to avoid duplicate symbols from i915. The interface for pcode was
added without considering that, so the build breaks if both xe and i915
are built-in.
Since the intel_pcode_* functions should only be called from the display
side (xe side should call the xe interface directly) and there's already
a protection in Kconfig to avoid the problematic configuration, ifdef it
out in case CONFIG_DRM_XE_DISPLAY is disabled.
Closes: https://lore.kernel.org/r/3667a992-a24b-4e49-aab2-5ca73f2c0a56@infradead.org Fixes: d9465cc8ac2d ("drm/xe/pcode: add struct drm_device based interface") Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250627-xe-kunit-v2-1-756fe5cd56cf@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Ville Syrjälä [Tue, 24 Jun 2025 17:00:46 +0000 (20:00 +0300)]
drm/i915/flipq: Implement Wa_18034343758
Implement the driver side of Wa_18034343758, which is supposed to
prevent the DSB and DMC from accessing registers in parallel, and
thus potentially corrupting the registers due to a hardware issue
(which should be fixed in PTL-B0).
The w/a sequence goes as follows:
DMC starts the DSB
| \
DMC halts itself | DSB waits a while for DMC to have time to halt
. | DSB executes normally
. | DSB unhalts the DMC at the very end
. /
DMC resumes execution
v2: PTL-B0+ firmware no longer has the w/a since the hw got fixed
v3: Do the w/a on all PTL for now since we only have the A0 firmware
binaries which issues the halt instructions unconditionally
v4: PTL DMC binaries do in fact have the A0 vs. B0 split, so skip
the w/a on PTL-B0+
Ville Syrjälä [Tue, 24 Jun 2025 17:00:45 +0000 (20:00 +0300)]
drm/i915/flipq: Implement flip queue based commit path
Support commits via the flip queue (as opposed to DSB or MMIO).
As it's somewhat unknown if we can actually use it is currently
gated behind the new use_flipq modparam, which defaults to disabled.
The implementation has a bunch of limitations that would need
real though to solve:
- disabled when PSR is used
- disabled when VRR is used
- color management updates not performed via the flip queue
v2: Don't use flip queue if there is no dmc
v3: Use intel_flipq_supported()
v3: Configure PKG_C_LATENCY appropriately
Ignore INT_VECTOR if there is a real PIPEDMC interrupt
(nothing in the hw appears to clear INT_VECTOR)
v4: Leave added_wake_time=0 when flip queue isn't used, to
avoid needleslly increasing pkg_c_latency on lnl/ptl due
to Wa_22020432604. This is a bit racy though...
Use IS_DISPLAY_VER()
Ville Syrjälä [Tue, 24 Jun 2025 17:00:44 +0000 (20:00 +0300)]
drm/i915/flipq: Provide the nuts and bolts code for flip queue
Provide the lower level code for PIPEDMC based flip queue.
We'll use the so called semi-full flip queue mode where the
PIPEDMC will start the provided DSB on a scanline a little
ahead of the vblank. We need to program the triggering scanline
early enough so that the DSB has enough time to complete writing
all the double buffered registers before they get latched (at
start of vblank).
The firmware implements several queues:
- 3 "plane queues" which execute a single DSB per entry
- 1 "general queue" which can apparently execute 2 DSBs per entry
- 1 vestigial "fast queue" that replaced the "simple flip queue"
on ADL+, but this isn't supposed to be used due to issues.
But we only need a single plane queue really, and we won't actually
use it as a real queue because we don't allow queueing multiple commits
ahead of time. So the whole thing is perhaps useless. I suppose
there migth be some power saving benefits if we would get the flip
scheduled by userspace early and then could keep some hardware powered
off a bit longer until the DMC kicks off the flipq programming. But that
is pure speculation at this time and needs to be proven.
The code to hook up the flip queue into the actual atomic commit
path will follow later.
TODO: need to think how to do the "wait for DMC firmware load" nicely
need to think about VRR and PSR
etc.
v2: Don't write DMC_FQ_W2_PTS_CFG_SEL on pre-lnl
Don't oops at flipq init if there is no dmc
v3: Adapt to PTL+ flipq changes (different queue entry
layout, different trigger event, need VRR TG)
Use the actual CDCLK frequency
Ask the DSB code how long things are expected to take
v3: Adjust the cdclk rounding (docs are 100% vague, Windows
rounds like this)
Initialize some undocumented magic DMC variables on PTL
v4: Use PIPEDMC_FQ_STATUS for busy check (the busy bit in
PIPEDMC_FQ_CTRL is apparently gone on LNL+)
Based the preempt timeout on the max exec time
Preempt before disabling the flip queue
Order the PIPEDMC_SCANLINECMP* writes a bit more carefully
Fix some typos
v5: Try to deal with some clang-20 div-by-zero false positive (Nathan)
Add some docs (Jani)
Ville Syrjälä [Tue, 24 Jun 2025 17:00:43 +0000 (20:00 +0300)]
drm/i915/dmc: Define flip queue related PIPEDMC registers
Add the register definitions for a bunch of flip queue related
PIPEDMC registers.
v2: The layout of flip queue entries changed on PTL
Bump the DMC_FQ_W2_PTS_CFG_SEL bitfields sizes (Uma)
Reduce the scanlines to 21 bits for now (Uma)
v3: Also define some undocumented DMC variables we need on PTL
v3: Drop PIPEDMC_FQ_CTRL_BUSY as it seems to no longer exist
on LNL+
Fix up some typos
Ville Syrjälä [Tue, 24 Jun 2025 17:00:42 +0000 (20:00 +0300)]
drm/i915: Try to program PKG_C_LATENCY more correctly
The current PKG_C_LATENCY stuff looks busted in several ways:
- doesn't account for multiple pipes from different commits
correctly
- WM_LINETIME is in units of 0.125usec, PKG_C_LATENCY wants
units on 1 usec
- weird VRR state stuff being checked
- use of pointless RMW
Fix it all up. Note that it's still a bit unclear how all this
works, especially how the added_wake_time ties into the flipq
triggers in DMC, and how we need to sequence updates to
PKG_C_LATENCY when enabling/disabling pipes/etc. We may also
need to think what to about the WM1+ disabling and the related
PSR chicken bits when we can use PKG_C_LATENCY for early wake...
Hans de Goede [Thu, 26 Jun 2025 14:33:17 +0000 (16:33 +0200)]
drm/i915/dsi: Fix NULL pointer deref in vlv_dphy_param_init()
Commit 77ba0b856225 ("drm/i915/dsi: convert vlv_dsi.[ch] to struct
intel_display") added a to_intel_display(connector) call to
vlv_dphy_param_init() but when vlv_dphy_param_init() gets called
the connector object has not been initialized yet, so this leads
to a NULL pointer deref:
Use to_intel_display(&intel_dsi->base) instead to fix this.
Fixes: 77ba0b856225 ("drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display") Signed-off-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://lore.kernel.org/r/20250626143317.101706-1-hansg@kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:19 +0000 (11:01 +0200)]
drm/i915/display: Add drm_panic support for 4-tiling with DPT
On Alder Lake and later, it's not possible to disable tiling when DPT
is enabled.
So this commit implements 4-Tiling support, to still be able to draw
the panic screen.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:18 +0000 (11:01 +0200)]
drm/i915/display: Add drm_panic support for Y-tiling with DPT
On Alder Lake and later, it's not possible to disable tiling when DPT
is enabled.
So this commit implements Y-Tiling support, to still be able to draw
the panic screen.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:17 +0000 (11:01 +0200)]
drm/i915/display: Add drm_panic support
This adds drm_panic support for a wide range of Intel GPU. I've
tested it only on 4 laptops, Haswell (with 128MB of eDRAM),
Comet Lake, Raptor Lake, and Lunar Lake.
For hardware using DPT, it's not possible to disable tiling, as you
will need to reconfigure the way the GPU is accessing the
framebuffer, so this will be handled by the following patches.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:16 +0000 (11:01 +0200)]
drm/i915: Add intel_bo_panic_setup() and intel_bo_panic_finish()
Implement both functions for i915 and xe, they prepare the work for
drm_panic support.
They both use kmap_try_from_panic(), and map one page at a time, to
write the panic screen on the framebuffer.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:15 +0000 (11:01 +0200)]
drm/i915: Add intel_bo_alloc_framebuffer()
Encapsulate the struct intel_framebuffer into an xe_framebuffer
or i915_framebuffer, and allow to add specific fields for each
variant for the panic use-case.
This is particularly needed to have a struct xe_res_cursor available
to support drm panic on discrete GPU.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:14 +0000 (11:01 +0200)]
drm/ttm: Add ttm_bo_kmap_try_from_panic()
If the ttm bo is backed by pages, then it's possible to safely kmap
one page at a time, using kmap_try_from_panic().
Unfortunately there is no way to do the same with ioremap, so it
only supports the kmap case.
This is needed for proper drm_panic support with xe driver.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:13 +0000 (11:01 +0200)]
drm/i915/display: Add a disable_tiling() for skl planes
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
This assumes that the alignment restriction is always smaller in
linear than in tiled.
It also assumes that the linear framebuffer size is always smaller
than the tiled.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:12 +0000 (11:01 +0200)]
drm/i915/display/i9xx: Add a disable_tiling() for i9xx planes
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
This assumes that the alignment restriction is always smaller in
linear than in tiled.
It also assumes that the linear framebuffer size is always smaller
than the tiled.
Jocelyn Falempe [Tue, 24 Jun 2025 09:01:11 +0000 (11:01 +0200)]
drm/i915/fbdev: Add intel_fbdev_get_map()
The vaddr of the fbdev framebuffer is private to the struct
intel_fbdev, so this function is needed to access it for drm_panic.
Also the struct i915_vma is different between i915 and xe, so it
requires a few functions to access fbdev->vma->iomap.
Move the {SKL,ICL}_PW_CTL_IDX_TO_PG() macros from intel_display_regs.h
to intel_display_power_well.c. The mapping from index to PG can be
hidden there.
Dan Carpenter [Wed, 25 Jun 2025 15:21:58 +0000 (10:21 -0500)]
drm/i915/selftests: Change mock_request() to return error pointers
There was an error pointer vs NULL bug in __igt_breadcrumbs_smoketest().
The __mock_request_alloc() function implements the
smoketest->request_alloc() function pointer. It was supposed to return
error pointers, but it propogates the NULL return from mock_request()
so in the event of a failure, it would lead to a NULL pointer
dereference.
To fix this, change the mock_request() function to return error pointers
and update all the callers to expect that.
Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/685c1417.050a0220.696f5.5c05@mx.google.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Luca Coelho [Fri, 20 Jun 2025 09:15:30 +0000 (12:15 +0300)]
drm/i915/display: move unordered works to new private workqueue
Create a new unordered workqueue to be used by the display code
instead of relying on the i915 one. Then move all the unordered works
used in the display code to use this new queue.
Since this is an unordered workqueue, by definition there can't be any
order dependency with non-display works, so no extra care is needed
in regard to that.
This is part of the effort to isolate the display code from i915.
Jani Nikula [Wed, 25 Jun 2025 10:32:34 +0000 (13:32 +0300)]
drm/i915/cdclk: make struct intel_cdclk_state opaque
With all the code touching struct intel_cdclk_state moved inside
intel_cdclk.c, we move the struct definition there too, and make the
type opaque. This nicely reduces includes from intel_cdclk.h.
Jani Nikula [Wed, 25 Jun 2025 10:32:33 +0000 (13:32 +0300)]
drm/i915/cdclk: abstract intel_cdclk_actual() and intel_cdclk_actual_voltage_level()
Add intel_cdclk_actual() and intel_cdclk_actual_voltage_level() helpers
to avoid looking at struct intel_cdclk_state internals outside of
intel_cdclk.c.
Jani Nikula [Wed, 25 Jun 2025 10:32:26 +0000 (13:32 +0300)]
drm/i915/bw: make struct intel_bw_state opaque
With all the code touching struct intel_bw_state moved inside
intel_bw.c, we move the struct definition there too, and make the type
opaque. to_intel_bw_state() needs to be turned into a proper
function. All of this nicely reduces includes from intel_bw.h.
Jani Nikula [Wed, 25 Jun 2025 10:32:23 +0000 (13:32 +0300)]
drm/i915/bw: relocate intel_can_enable_sagv() and rename to intel_bw_can_enable_sagv()
Prefer only looking at struct intel_bw_state internals inside
intel_bw.c. To that effect, move intel_can_enable_sagv() there, and
rename to intel_bw_can_enable_sagv() to have consistent naming.
Jani Nikula [Wed, 25 Jun 2025 10:32:21 +0000 (13:32 +0300)]
drm/i915/wm: make struct intel_dbuf_state opaque type
With all the code touching struct intel_dbuf_state moved inside
skl_watermark.c, we move the struct definition there too, and make the
type opaque. This nicely reduces includes from skl_watermark.h.
Jani Nikula [Wed, 25 Jun 2025 10:32:20 +0000 (13:32 +0300)]
drm/i915/wm: add more accessors to dbuf state
Add intel_dbuf_num_enabled_slices() and intel_dbuf_num_active_pipes()
helpers to avoid looking at struct intel_dbuf_state internals outside of
skl_watermark.c.
Nemesa Garg [Wed, 25 Jun 2025 07:49:11 +0000 (13:19 +0530)]
drm/i915/display: Implement wa_16011342517
While doing voltage swing for type-c phy
for DP 1.62 and HDMI write the
LOADGEN_SHARING_PMD_DISABLE bit to 1.
-v2: Update commit.
Add bspec[Suraj]
-v3: Move w/a before DKL_TX_PMD_LANE_SUS.
Use DKL_TX_DPCNTL2[Ville]
-v4: Use intel_encoder_is_dp and
intel_encoder_is_hdmi. [Suraj]
Arun R Murthy [Tue, 24 Jun 2025 06:54:58 +0000 (12:24 +0530)]
drm/i915/panel: register drm_panel and call prepare/unprepare for eDP
Allocate and register drm_panel to allow the panel_follower framework to
detect the eDP panel and pass drm_connector::kdev device to drm_panel
allocation for matching.
Call drm_panel_prepare/unprepare in ddi_enable for eDP to allow the
followers to get notified of the panel power state changes.
Note: This is for eDP with DDI platforms only.
v2: remove backlight setup from panel_register (Jani)
v3: Updated the commit message (Jani)
projects / users / willy / xarray.git / log