Jani Nikula [Tue, 5 Aug 2025 11:56:56 +0000 (14:56 +0300)]
drm/i915: silence rpm wakeref asserts on GEN11_GU_MISC_IIR access
Commit 8d9908e8fe9c ("drm/i915/display: remove small micro-optimizations
in irq handling") not only removed the optimizations, it also enabled
wakeref asserts for the GEN11_GU_MISC_IIR access. Silence the asserts by
wrapping the access inside intel_display_rpm_assert_{block,unblock}().
Reported-by: "Jason A. Donenfeld" <Jason@zx2c4.com> Closes: https://lore.kernel.org/r/aG0tWkfmxWtxl_xc@zx2c4.com Fixes: 8d9908e8fe9c ("drm/i915/display: remove small micro-optimizations in irq handling") Cc: stable@vger.kernel.org # v6.13+ Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://lore.kernel.org/r/20250805115656.832235-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Imre Deak [Tue, 5 Aug 2025 07:36:59 +0000 (10:36 +0300)]
drm/i915/tc: Cache the pin assignment value
Cache the pin assignment value. This is more consistent with the way the
max lane count value is tracked and a bit more efficient than reading
out the same value from HW each time it's queried.
Imre Deak [Tue, 5 Aug 2025 07:36:58 +0000 (10:36 +0300)]
dmc/i915/tc: Report pin assignment NONE in TBT-alt mode
The pin assignment is only relevant in case the PHY is owned by the
display, that is in legacy and DP-alt mode. In TBT-alt mode the PHY is
owned by the TBT FW/driver and so the pin assignment/configuration is
managed by those components. A follow-up change will cache the pin
assignment value in all the TypeC modes - querying this by calling
get_pin_assignment() - prepare for that here, by reporting pin
assignment NONE in the TBT-alt mode.
Imre Deak [Tue, 5 Aug 2025 07:36:57 +0000 (10:36 +0300)]
drm/i915/tc: Pass intel_tc_port to internal lane mask/count helpers
Pass the intel_tc_port pointer instead of intel_digital_port to all lane
mask and count query helpers internal to intel_tc.c, to avoid the
redundant intel_digital_port -> intel_tc_port conversions.
While at it shorten the function names, keeping the intel_tc_port_
prefix only for exported functions and use the mtl_, icl_ prefixes
making it clear which platforms a given query function is specific for.
Imre Deak [Tue, 5 Aug 2025 07:36:56 +0000 (10:36 +0300)]
drm/i915/tc: Handle non-TC encoders when getting the pin assignment
For consistency, handle the case where
intel_tc_port_get_pin_assignment() is called for a non-TypeC encoder,
returning the default NONE pin assignment value, similarly to how this
is done in intel_tc_port_max_lane_count().
Imre Deak [Tue, 5 Aug 2025 07:36:53 +0000 (10:36 +0300)]
drm/i915/tc: Validate the pin assignment on all platforms
Validate the pin assignment on ICL-TGL, similarly to how this is done on
MTL+. ICL supports all the pin assignments, while TGL+ supports only the
NONE, C, D, E pin assignments.
Imre Deak [Tue, 5 Aug 2025 07:36:52 +0000 (10:36 +0300)]
drm/i915/tc: Handle pin assignment NONE on all platforms
For consistency, handle pin assignment NONE on all platforms similarly
to LNL+. On earlier platforms the driver doesn't actually see this pin
assignment - as it's not valid on a connected DP-alt PHY - however it's
a valid HW setting even on those platforms, for instance in legacy mode.
Handle this pin assignment on earlier platforms as well, so that the way
to query the pin assignment can be unified by a follow-up change.
Imre Deak [Tue, 5 Aug 2025 07:36:50 +0000 (10:36 +0300)]
drm/i915/tc: Add an enum for the TypeC pin assignment
Add an enum for the TypeC pin assignment, which is a better way to pass
its value around than a plain integer. While at it add a description for
each pin assignment, based on the DP and DP Alt mode Standards, opting
for more details to ease any future debugging related to a given pin
assignment and the cables / sink types used.
Imre Deak [Tue, 5 Aug 2025 07:36:49 +0000 (10:36 +0300)]
drm/i915/tc: Move asserting the power state after reading TCSS_DDI_STATUS
Move asserting the expected TC cold power state and the read out
register value right after reading the TCSS_DDI_STATUS register,
similarly to how this is done with the other PORT_TX_DFLEXDPSP and
PORT_TX_DFLEXPA1 PHY registers.
Imre Deak [Tue, 5 Aug 2025 07:36:48 +0000 (10:36 +0300)]
drm/i915/tc: Move getting the power domain before reading DFLEX registers
Move getting the required display power domain right before reading the
PORT_TX_DFLEXDPSP and PORT_TX_DFLEXPA1 registers, similarly to how this
is done while reading the other TCSS_DDI_STATUS PHY register.
Imre Deak [Tue, 5 Aug 2025 07:36:47 +0000 (10:36 +0300)]
drm/i915/tc: Use the cached max lane count value
Use the PHY's cached max lane count value on all platforms similarly to
LNL+. On LNL+ using the cached value is mandatory - since the
corresponding HW register field can get cleared by the time the value is
queried - on earlier platforms there isn't a problem with using the HW
register instead. Having a uniform way to query the value still makes
sense and it's also a bit more efficient, so do that.
Dibin Moolakadan Subrahmanian [Thu, 7 Aug 2025 08:24:02 +0000 (13:54 +0530)]
drm/i915/display: Optimize panel power-on wait time
The current wait_panel_status() uses intel_de_wait(),
which internally on Xe platforms calls xe_mmio_wait32().
xe_mmio_wait32() increases poll interval exponentially.
This exponential poll interval increase causes unnessory delays
during resume or power-on when the panel becomes ready earlier,
but polling is delayed due to backoff.
Replace intel_de_wait() with read_poll_timeout() +
intel_de_read() to actively poll the register at a fixed 10ms interval
up to a 5 second timeout. This allows poll to exit
early when panel is ready.
Changes in v2:
Replaced two-phase intel_de_wait() with read_poll_timeout()
+ intel_de_read()
Changes in v3:
- Add poll_interval_ms argument 'wait_panel_status' function.
- Modify 'wait_panel_status' callers with proper poll interval
Changes in v4:
- Change 'wait_panel_off' poll interval to 10ms
Changes in v5:
- Dropped poll_interval_ms parameter,use fixed polling
interval of 10ms (Jani Nikula)
Changes in v6:
- Removed goto in error path
Jani Nikula [Tue, 29 Jul 2025 11:17:08 +0000 (14:17 +0300)]
drm/i915/display: add intel_dig_port_alloc()
Add a common allocator function for struct intel_digital_port, with some
member default initialization to deduplicate them from everywhere
else. This is similar to intel_connector_alloc().
At least for now, place this in intel_encoder.[ch]. We don't have a
dedicated file for dig port stuff, and there wouldn't be much to add
there anyway. A digital port is a sort of subclass of encoder, so the
location isn't far off the mark.
Imre Deak [Mon, 11 Aug 2025 08:01:52 +0000 (11:01 +0300)]
drm/i915/icl+/tc: Convert AUX powered WARN to a debug message
The BIOS can leave the AUX power well enabled on an output, even if this
isn't required (on platforms where the AUX power is only needed for an
AUX access). This was observed at least on PTL. To avoid the WARN which
would be triggered by this during the HW readout, convert the WARN to a
debug message.
Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-6-imre.deak@intel.com
Imre Deak [Mon, 11 Aug 2025 08:01:51 +0000 (11:01 +0300)]
drm/i915/lnl+/tc: Use the cached max lane count value
Use the cached max lane count value on LNL+, to account for scenarios
where this value is queried after the HW cleared the corresponding pin
assignment value in the TCSS_DDI_STATUS register after the sink got
disconnected.
For consistency, follow-up changes will use the cached max lane count
value on other platforms as well and will also cache the pin assignment
value in a similar way.
Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-5-imre.deak@intel.com
Imre Deak [Mon, 11 Aug 2025 08:01:50 +0000 (11:01 +0300)]
drm/i915/lnl+/tc: Fix max lane count HW readout
On LNL+ for a disconnected sink the pin assignment value gets cleared by
the HW/FW as soon as the sink gets disconnected, even if the PHY
ownership got acquired already by the BIOS/driver (and hence the PHY
itself is still connected and used by the display). During HW readout
this can result in detecting the PHY's max lane count as 0 - matching
the above cleared aka NONE pin assignment HW state. For a connected PHY
the driver in general (outside of intel_tc.c) expects the max lane count
value to be valid for the video mode enabled on the corresponding output
(1, 2 or 4). Ensure this by setting the max lane count to 4 in this
case. Note, that it doesn't matter if this lane count happened to be
more than the max lane count with which the PHY got connected and
enabled, since the only thing the driver can do with such an output -
where the DP-alt sink is disconnected - is to disable the output.
v2: Rebased on change reading out the pin configuration only if the PHY
is connected.
Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-4-imre.deak@intel.com
Imre Deak [Mon, 11 Aug 2025 08:01:49 +0000 (11:01 +0300)]
drm/i915/icl+/tc: Cache the max lane count value
The PHY's pin assignment value in the TCSS_DDI_STATUS register - as set
by the HW/FW based on the connected DP-alt sink's TypeC/PD pin
assignment negotiation - gets cleared by the HW/FW on LNL+ as soon as
the sink gets disconnected, even if the PHY ownership got acquired
already by the driver (and hence the PHY itself is still connected and
used by the display). This is similar to how the PHY Ready flag gets
cleared on LNL+ in the same register.
To be able to query the max lane count value on LNL+ - which is based on
the above pin assignment - at all times even after the sink gets
disconnected, the max lane count must be determined and cached during
the PHY's HW readout and connect sequences. Do that here, leaving the
actual use of the cached value to a follow-up change.
v2: Don't read out the pin configuration if the PHY is disconnected.
Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-3-imre.deak@intel.com
Imre Deak [Mon, 11 Aug 2025 08:01:48 +0000 (11:01 +0300)]
drm/i915/lnl+/tc: Fix handling of an enabled/disconnected dp-alt sink
The TypeC PHY HW readout during driver loading and system resume
determines which TypeC mode the PHY is in (legacy/DP-alt/TBT-alt) and
whether the PHY is connected, based on the PHY's Owned and Ready flags.
For the PHY to be in DP-alt or legacy mode and for the PHY to be in the
connected state in these modes, both the Owned (set by the BIOS/driver)
and the Ready (set by the HW) flags should be set.
On ICL-MTL the HW kept the PHY's Ready flag set after the driver
connected the PHY by acquiring the PHY ownership (by setting the Owned
flag), until the driver disconnected the PHY by releasing the PHY
ownership (by clearing the Owned flag). On LNL+ this has changed, in
that the HW clears the Ready flag as soon as the sink gets disconnected,
even if the PHY ownership was acquired already and hence the PHY is
being used by the display.
When inheriting the HW state from BIOS for a PHY connected in DP-alt
mode on which the sink got disconnected - i.e. in a case where the sink
was connected while BIOS/GOP was running and so the sink got enabled
connecting the PHY, but the user disconnected the sink by the time the
driver loaded - the PHY Owned but not Ready state must be accounted for
on LNL+ according to the above. Do that by assuming on LNL+ that the PHY
is connected in DP-alt mode whenever the PHY Owned flag is set,
regardless of the PHY Ready flag.
This fixes a problem on LNL+, where the PHY TypeC mode / connected state
was detected incorrectly for a DP-alt sink, which got connected and then
disconnected by the user in the above way.
v2: Rename tc_phy_in_legacy_or_dp_alt_mode() to tc_phy_owned_by_display().
(Luca, Jani)
Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org # v6.8+ Reported-by: Charlton Lin <charlton.lin@intel.com> Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
[Imre: Add one-liner function documentation for tc_phy_owned_by_display()] Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250811080152.906216-2-imre.deak@intel.com
Jani Nikula [Mon, 11 Aug 2025 15:25:47 +0000 (18:25 +0300)]
drm/i915/vbt: split up DSI VBT defs to a separate file
The DSI VBT definitions have ended up in intel_bios.h, because
intel_vbt_defs.h is supposed to be internal to intel_bios.c, but the DSI
VBT definitions are needed in more places.
Split out the DSI VBT definitions to intel_dsi_vbt_defs.h. This will
also help keep the definitions in sync with IGT.
Jouni Högander [Fri, 1 Aug 2025 06:29:05 +0000 (09:29 +0300)]
drm/i915/psr: Do not trigger Frame Change events from frontbuffer flush
We want to get rid of triggering "Frame Change" events from
frontbuffer flush calls. We are about to move using TRANS_PUSH
register for this on LunarLake and onwards. Touching TRANS_PUSH
register from fronbuffer flush would be problematic as it's written by
DSB as well.
Fix this by using intel_psr_exit when flush or invalidate is done on
LunarLake and onwards. This is not possible on AlderLake and
MeteorLake due to HW bug in PSR2 disable.
This patch is also fixing problems with cursor plane where cursor is
disappearing or duplicate cursor is seen on the screen.
Jani Nikula [Tue, 29 Jul 2025 09:57:39 +0000 (12:57 +0300)]
drm/i915: use drm->debugfs_root for creating debugfs files
Since commit 0b30d57acafc ("drm/debugfs: rework debugfs directory
creation v5") we should be using drm->debugfs_root instead of
minor->debugfs_root for creating debugfs files.
Jani Nikula [Tue, 29 Jul 2025 09:57:38 +0000 (12:57 +0300)]
drm/i915/gvt: use drm->debugfs_root for creating debugfs files
Since commit 0b30d57acafc ("drm/debugfs: rework debugfs directory
creation v5") we should be using drm->debugfs_root instead of
minor->debugfs_root for creating debugfs files.
Jani Nikula [Tue, 29 Jul 2025 09:57:37 +0000 (12:57 +0300)]
drm/i915/display: use drm->debugfs_root for creating debugfs files
Since commit 0b30d57acafc ("drm/debugfs: rework debugfs directory
creation v5") we should be using drm->debugfs_root instead of
minor->debugfs_root for creating debugfs files.
As a rule of thumb, use a local variable when there are two or more
uses, otherwise just have the single reference inline.
Jani Nikula [Thu, 31 Jul 2025 09:19:21 +0000 (12:19 +0300)]
drm/i915/display: make struct __intel_global_objs_state opaque
With struct __intel_global_objs_state only being accessed in
intel_global_state.c, we can make it opaque. The double underscore to
indicate internal becomes redundant, drop it.
Jani Nikula [Thu, 31 Jul 2025 09:19:20 +0000 (12:19 +0300)]
drm/i915/display: hide global state iterators, remove unused
for_each_{new,old,oldnew}_global_obj_in_state() are only used within
intel_global_state.c, hide them there. intel_for_each_global_obj() is
unused, remove it.
Nemesa Garg [Fri, 1 Aug 2025 12:58:35 +0000 (18:28 +0530)]
drm/i915/display: WA_14011503117
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]
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()
projects / users / willy / xarray.git / log