Mika Kahola [Thu, 12 Mar 2026 08:06:46 +0000 (08:06 +0000)]
drm/i915/lt_phy: Add xe3plpd .get_hw_state hook
Add .get_hw_state hook to xe3plpd platform for dpll framework
and update intel_lt_phy_pll_readout_hw_state() function
accordingly to support dpll framework.
Mika Kahola [Thu, 12 Mar 2026 08:06:44 +0000 (08:06 +0000)]
drm/i915/lt_phy: Add xe3plpd .dump_hw_state hook
Add .dump_hw_state function pointer for xe3plpd platform
to support dpll framework. While at it, switch to use
drm_printer structure to print hw state information.
Mika Kahola [Thu, 12 Mar 2026 08:06:37 +0000 (08:06 +0000)]
drm/i915/lt_phy: Refactor LT PHY PLL handling to use explicit PLL state
The LT PHY implementation currently pulls PLL and port_clock
information directly from the CRTC state. This ties the PHY
programming logic too tightly to the CRTC state and makes it
harder to clearly express the PHY’s own PLL configuration.
Introduce an explicit "struct intel_lt_phy_pll_state" argument
for the PHY functions and update callers accordingly.
No functional change is intended — this is a preparatory cleanup for
to bring LT PHY PLL handling as part of PLL framework.
v2: DP, HDMI 2.0, and HDMI FRL modes are port of the VDR configuration 0
register. These modes are defined by bits 2:0. Decode these to
differentiate DP and HDMI modes when programming PLL's. (Imre, Suraj)
v3: Pass port_clock as argument instead of recalculating it (Suraj)
v4: Fix checkpatch warning of line length exceeding 100 columns
Imre Deak [Fri, 20 Mar 2026 09:29:00 +0000 (11:29 +0200)]
drm/i915/dp_tunnel: Fix error handling when clearing stream BW in atomic state
Clearing the DP tunnel stream BW in the atomic state involves getting
the tunnel group state, which can fail. Handle the error accordingly.
This fixes at least one issue where drm_dp_tunnel_atomic_set_stream_bw()
failed to get the tunnel group state returning -EDEADLK, which wasn't
handled. This lead to the ctx->contended warn later in modeset_lock()
while taking a WW mutex for another object in the same atomic state, and
thus within the same already contended WW context.
Moving intel_crtc_state_alloc() later would avoid freeing saved_state on
the error path; this stable patch leaves that simplification for a
follow-up.
Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.9+ Fixes: a4efae87ecb2 ("drm/i915/dp: Compute DP tunnel BW during encoder state computation") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7617 Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260320092900.13210-1-imre.deak@intel.com
Ville Syrjälä [Thu, 19 Mar 2026 11:40:33 +0000 (13:40 +0200)]
drm/i915/wm: Include ddb_y in skl_print_wm_changes() on pre-icl
Pre-icl doesn't use a separate hardware plane for Y scanout,
and instead it's all handled magically by the hardware. We
do still need to allocate DDB space for the Y color plane
though (PLANE_NV12_BUF_CFG). Include that information in the
debugs so that we know where it ended up.
On icl+ the equivalent information is dumped as the hardware
Y plane's normal ddb allocation.
We have skl_print_plane_wm_changes() but the DDB counterpart is
just inline in the main loop. Extract it into a function. We'll
have a second use for this soon.
The "ddb" part is already parametrized in anticipation of the
second user.
Ville Syrjälä [Thu, 19 Mar 2026 11:40:30 +0000 (13:40 +0200)]
drm/i915/wm: Nuke wm->uv_wm[]
We currently keep around the full watermarks for the UV plane
on pre-icl, even though the hardware doesn't need most of this
information. The only thing we need to keep is the min_ddb_alloc
for the UV plane. Move that into the main wm->wm[].min_ddb_alloc_uv
alongside the other min_ddb_alloc (used for Y/RGB).
This makes our state tracking match the hardware more closely,
and avoids having to justify everwhere why uv_wm[] is being
ignored.
Extract skl_allocate_plane_ddb_nv12() as the compute counterpart to
skl_check_wm_level_nv12(). Mainly to hide some of the clutter from
skl_crtc_allocate_plane_ddb().
Rename skl_check_nv12_wm_level() to skl_check_wm_level_nv12(). There
will be a sort of DDB counterparts to skl_check_wm_level*(), and
putting the "nv12" part to the end will allow consistent naming.
Ville Syrjälä [Thu, 19 Mar 2026 11:40:27 +0000 (13:40 +0200)]
drm/i915/wm: Reorder the arguments to skl_allocate_plane_ddb()
Group the ddb and data_rate together in the skl_allocate_plane_ddb()
arguments. Upcoming changes will adjust the UV plane handling and
keeing the ddb allocation and the data rate used to calculate it
together will help with clarity.
Ville Syrjälä [Mon, 16 Mar 2026 16:39:53 +0000 (18:39 +0200)]
drm/i915: Skip redundant NV12 plane unlinking
plane_atomic_check() will already have unlinked the
old NV12 planes by the time icl_check_nv12_planes()
gets called. Drop the redundant second unlinking.
Ville Syrjälä [Mon, 16 Mar 2026 16:39:51 +0000 (18:39 +0200)]
drm/i915: Unlink NV12 planes earlier
unlink_nv12_plane() will clobber parts of the plane state
potentially already set up by plane_atomic_check(), so we
must make sure not to call the two in the wrong order.
The problem happens when a plane previously selected as
a Y plane is now configured as a normal plane by user space.
plane_atomic_check() will first compute the proper plane
state based on the userspace request, and unlink_nv12_plane()
later clears some of the state.
This used to work on account of unlink_nv12_plane() skipping
the state clearing based on the plane visibility. But I removed
that check, thinking it was an impossible situation. Now when
that situation happens unlink_nv12_plane() will just WARN
and proceed to clobber the state.
Rather than reverting to the old way of doing things, I think
it's more clear if we unlink the NV12 planes before we even
compute the new plane state.
Ville Syrjälä [Fri, 13 Mar 2026 11:07:40 +0000 (13:07 +0200)]
drm/i915: Order OP vs. timeout correctly in __wait_for()
Put the barrier() before the OP so that anything we read out in
OP and check in COND will actually be read out after the timeout
has been evaluated.
Currently the only place where we use OP is __intel_wait_for_register(),
but the use there is precisely susceptible to this reordering, assuming
the ktime_*() stuff itself doesn't act as a sufficient barrier:
Jouni Högander [Tue, 17 Mar 2026 06:24:02 +0000 (08:24 +0200)]
drm/i915/psr: Disable Panel Replay on Dell XPS 14 DA14260 as a quirk
Add new quirk (QUIRK_DISABLE_PANEL_REPLAY) for disabling Panel Replay as
quirk for problematic setups. Apply this newly added quirk on Dell XPS 14 DA14260 if specific panel model is installed.
We are observing problems with Dell XPS 14 DA14260. This device has certain
LGD panel model which seems to be problematic. We have seen other LGD panel
model with same OUI is working fine. Due to this we can't apply the quirk
only based on panel OUI. There are also cases where same device model has
differing panel model. We don't want to disable Panel Replay on such
devices. Best we can do is to apply the quirk based on both device model
and panel model.
drm/i915/gmbus: fix spurious timeout on 512-byte burst reads
When reading exactly 512 bytes with burst read enabled, the
extra_byte_added path breaks out of the inner do-while without
decrementing len. The outer while(len) then re-enters and gmbus_wait()
times out since all data has been delivered. Decrement len before the
break so the outer loop terminates correctly.
Suraj Kandpal [Mon, 16 Mar 2026 03:18:51 +0000 (08:48 +0530)]
drm/i915/backlight: Check if VESA backlight is possible
Check if BACKLIGHT_BRIGHTNESS_AUX_SET_CAPABLE bit is
set then EDP_PWMGEN_BIT_COUNT_CAP_MIN and EDP_PWMGEN_BIT_COUNT_CAP_MAX
follow the eDP 1.4b Section 10.3. Which states min should
be >= 1 and max should be >= min. Some legacy panels
do not follow this properly. They set the
BACKLIGHT_BRIGHTNESS_AUX_SET_CAPABLE bit while not correctly
populating the min and max fields leading to a 0 max value.
Jonathan Cavitt [Wed, 4 Feb 2026 16:19:46 +0000 (16:19 +0000)]
drm/i915/gvt: Swap read and write checks
The function intel_gvt_i2c_handle_aux_ch_write currently does not
support the DP_AUX_I2C_WRITE operation. Notably, we check if
op & 0x1 == DP_AUX_I2C_WRITE (one), and if it does not, assert that
op & 0x1 == DP_AUX_I2C_READ (zero). This is unnecessary because if
op & 0x1 != 1, then op & 0x1 == 0. But beyond that, it probably makes
more sense to check for the condition that is implemented, rather than
check for the condition that is not.
Swap the conditions. We can also get rid of the unnecessary drm_WARN_ON
while we're here.
Jonathan Cavitt [Fri, 23 Jan 2026 15:21:22 +0000 (15:21 +0000)]
drm/i915/display: PORT_NONE is not valid
Static analysis issue:
In assert_port_valid, add a check to ensure port != PORT_NONE, as that
is not a valid port. The check must be explicit to prevent a bad bit
shift operation in the general case via short-circuiting. It's not
likely this will ever come up in a real use case, but it's at least
worth guarding against.
It would probably also be pertinent to modify the behavior of the
port_name function to correctly print PORT_NONE in this case, as
currently the port would be reported as 'port @' by the debugger. But
that should be done separately, and given port_name is mostly just a
debug printing helper function anyways, fixing it is a low priority.
v2:
- Conditional check was backwards. Fix it. (Jani)
Jouni Högander [Thu, 12 Mar 2026 08:37:10 +0000 (10:37 +0200)]
drm/i915/psr: Compute PSR entry_setup_frames into intel_crtc_state
PSR entry_setup_frames is currently computed directly into struct
intel_dp:intel_psr:entry_setup_frames. This causes a problem if mode change
gets rejected after PSR compute config: Psr_entry_setup_frames computed for
this rejected state is in intel_dp:intel_psr:entry_setup_frame. Fix this by
computing it into intel_crtc_state and copy the value into
intel_dp:intel_psr:entry_setup_frames on PSR enable.
Fixes: 2b981d57e480 ("drm/i915/display: Support PSR entry VSC packet to be transmitted one frame earlier") Cc: Mika Kahola <mika.kahola@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260312083710.1593781-3-jouni.hogander@intel.com
Jouni Högander [Thu, 12 Mar 2026 08:37:09 +0000 (10:37 +0200)]
drm/i915/psr: Disable PSR on update_m_n and update_lrr
PSR/PR parameters might change based on update_m_n or update_lrr. Disable
on update_m_n and update_lrr to ensure proper parameters are taken into use
on next PSR enable in intel_psr_post_plane_update.
Jani Nikula [Wed, 11 Mar 2026 14:18:18 +0000 (16:18 +0200)]
drm/{i915,xe}: move framebuffer bo to parent interface
Add .framebuffer_init, .framebuffer_fini and .framebuffer_lookup to the
bo parent interface. While they're about framebuffers, they're
specifically about framebuffer objects, so the bo interface is a good
enough fit, and there's no need to add another interface struct.
Jani Nikula [Wed, 11 Mar 2026 14:18:16 +0000 (16:18 +0200)]
drm/{i915, xe}/bo: move display bo calls to parent interface
Continue i915 and xe separation from display by moving the bo calls to
the display parent interface. Instead of adding all these functions to
intel_parent.[ch], reuse the now vacated intel_bo.[ch], and avoid mass
renames to calls of these functions. This is similar to
intel_display_rpm.[ch].
Make many of the hooks optional to avoid having to implement dummy
functions in xe. Indeed now we can remove many of the existing dummy
functions.
Imre Deak [Wed, 11 Mar 2026 15:31:52 +0000 (17:31 +0200)]
drm/i915/dp: Simplify forcing a link retraining
Since both the DP SST and MST HPD IRQ handlers call
intel_dp_handle_link_service_irq() with LINK_STATUS_CHANGED set in
irq_mask if intel_dp->link.force_retrain is set, checking for the former
flag is sufficient to determine if the link status needs to be checked
(which includes retraining the link if this is forced); remove checking
for the latter flag.
Since LINK_STATUS_CHANGED is currently set unconditionally for DP SST,
extend the related comment to note that it must be set if
intel_dp->link.force_retrain is set (in case setting LINK_STATUS_CHANGED
becomes conditional on DPCD_REV).
Imre Deak [Wed, 11 Mar 2026 15:31:51 +0000 (17:31 +0200)]
drm/i915/dp_mst: Fix forced link retrain handling in MST HPD IRQ handler
Handling of a forced link retraining debugfs request via the DP MST HPD
IRQ handler is incorrectly skipped, if the IRQ handler doesn't see any
HPD IRQs raised by the sink. Fix this by ensuring that the request is
always handled (in the Fixes: commit below by directly calling
intel_dp_check_link_state(), later by the same call moved to
intel_dp_handle_link_service_irq()).
Cc: Luca Coelho <luciano.coelho@intel.com> Fixes: db4855d90363 ("drm/i915/dp_mst: Reuse intel_dp_check_link_state() in the HPD IRQ handler") Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260311153152.133744-1-imre.deak@intel.com
Suraj Kandpal [Wed, 25 Feb 2026 06:50:45 +0000 (12:20 +0530)]
drm/i915/hdcp: Take force_hdcp14 into account during check_link
During intel_hdcp_check_link phase we need to take into account
if we are currently forcing HDCP 1.4 or not. This is because
we check for HDCP 2.x Link first and only if HDCP 2.x is not being
used check for HDCP 1.4. With force_hdcp14 in picture we should not
be going into intel_hdcp2_check_link because of which we may end
up trying to disable HDCP2.x even if HDCP 1.4 was enabled causing
a lot of issues while IGT tests this.
Imre Deak [Mon, 9 Mar 2026 16:48:03 +0000 (18:48 +0200)]
drm/i915/dmc: Fix an unlikely NULL pointer deference at probe
intel_dmc_update_dc6_allowed_count() oopses when DMC hasn't been
initialized, and dmc is thus NULL.
That would be the case when the call path is
intel_power_domains_init_hw() -> {skl,bxt,icl}_display_core_init() ->
gen9_set_dc_state() -> intel_dmc_update_dc6_allowed_count(), as
intel_power_domains_init_hw() is called *before* intel_dmc_init().
However, gen9_set_dc_state() calls intel_dmc_update_dc6_allowed_count()
conditionally, depending on the current and target DC states. At probe,
the target is disabled, but if DC6 is enabled, the function is called,
and an oops follows. Apparently it's quite unlikely that DC6 is enabled
at probe, as we haven't seen this failure mode before.
It is also strange to have DC6 enabled at boot, since that would require
the DMC firmware (loaded by BIOS); the BIOS loading the DMC firmware and
the driver stopping / reprogramming the firmware is a poorly specified
sequence and as such unlikely an intentional BIOS behaviour. It's more
likely that BIOS is leaving an unintentionally enabled DC6 HW state
behind (without actually loading the required DMC firmware for this).
The tracking of the DC6 allowed counter only works if starting /
stopping the counter depends on the _SW_ DC6 state vs. the current _HW_
DC6 state (since stopping the counter requires the DC5 counter captured
when the counter was started). Thus, using the HW DC6 state is incorrect
and it also leads to the above oops. Fix both issues by using the SW DC6
state for the tracking.
This is v2 of the fix originally sent by Jani, updated based on the
first Link: discussion below.
Do away with the redundant intel_frontbuffer_get(),
intel_frontbuffer_put(), and intel_frontbuffer_ref() functions, and call
the parent interface functions directly.
Jani Nikula [Mon, 2 Mar 2026 18:17:37 +0000 (20:17 +0200)]
drm/{i915, xe}/frontbuffer: move frontbuffer handling to parent interface
Move the get/put/ref/flush_for_display calls to the display parent
interface.
For i915, move the hooks next to the other i915 core frontbuffer code in
i915_gem_object_frontbuffer.c. For xe, add new file xe_frontbuffer.c for
the same.
Note: The intel_frontbuffer_flush() calls from
i915_gem_object_frontbuffer.c will partially route back to i915 core via
the parent interface. This is less than stellar.
Jani Nikula [Mon, 2 Mar 2026 18:17:35 +0000 (20:17 +0200)]
drm/i915/overlay: convert from struct intel_frontbuffer to i915_frontbuffer
The intel_frontbuffer_get() and intel_frontbuffer_put() calls are routed
through intel_frontbuffer.c to i915_gem_object_frontbuffer.c. We might
as well call the functions directly, instead of going through display
code. This would only get worse with get/put being moved to the parent
interface.
To make this easier, convert overlay code from struct intel_frontbuffer
to struct i915_frontbuffer, and add a
i915_gem_object_frontbuffer_track() wrapper for clarity.
Jani Nikula [Mon, 2 Mar 2026 18:17:34 +0000 (20:17 +0200)]
drm/i915/gem: unify i915 gem object frontbuffer function names
Many of the i915 gem object frontbuffer function names follow the file
name as prefix. Follow suit with the remaining functions, renaming them
i915_gem_object_frontbuffer_*().
Move __i915_gem_object_{flush,invalidate}_frontbuffer() to
i915_gem_object_frontbuffer.c. All the other i915 gem object frontbuffer
functions are there already, and the relevant declarations are in
i915_gem_object_frontbuffer.h too.
Simon Richter [Fri, 6 Mar 2026 15:13:16 +0000 (00:13 +0900)]
drm/i915: handle failure from vga_get_uninterruptible()
The vga_get_uninterruptible() function can return an error if it fails to
set up VGA decoding for the requested device.
If VGA decoding is unavailable, we don't need to be careful to leave the
VGA emulation in a usable state, as vgacon will also be unable to get
access later on, so just skip over the VGA accesses and the vga_put() call
matching the failed vga_get_uninterruptible().
Randy Dunlap [Fri, 6 Mar 2026 22:10:32 +0000 (14:10 -0800)]
iopoll: fix function parameter names in read_poll_timeout_atomic()
Correct the function parameter names to avoid kernel-doc warnings
and to emphasize this function is atomic (non-sleeping).
Warning: include/linux/iopoll.h:169 function parameter 'sleep_us' not
described in 'read_poll_timeout_atomic'
Warning: ../include/linux/iopoll.h:169 function parameter
'sleep_before_read' not described in 'read_poll_timeout_atomic'
Fixes: 9df8043a546d ("iopoll: Generalize read_poll_timeout() into poll_timeout_us()") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260306221033.2357305-1-rdunlap@infradead.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Luca Coelho [Thu, 5 Mar 2026 09:59:19 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in skl_watermark.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:18 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in skl_universal_plane.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:17 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_psr.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:16 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_pmdemand.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:15 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_modeset_setup.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:14 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_flipq.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:13 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_fbc.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:12 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_dp_mst.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:11 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_display_device.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:10 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_display.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:09 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_ddi.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:08 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_cursor.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:07 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_cdclk.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:06 +0000 (11:59 +0200)]
drm/i915/display: convert W/As in intel_display_power.c to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:05 +0000 (11:59 +0200)]
drm/i915/display: convert audio workaround to new framework
Convert the low-hanging fruits of workaround checks to the workaround
framework. Instead of having display structure checks for the
workarounds all over, concentrate the checks in intel_display_wa.c.
Luca Coelho [Thu, 5 Mar 2026 09:59:04 +0000 (11:59 +0200)]
drm/i915/display: remove enum macro magic in intel_display_wa()
There's not much use in passing a number to the macro and let it
convert that into the enum and a string. It just hides the symbols.
Remove the number to enum conversion magic in intel_display_wa().
This has the side-effect of changing the print in the drm_WARN() that
is issued when the number is not implemented, but that is moot anyway
and can be changed later to something cleaner if needed.
Arun R Murthy [Wed, 4 Mar 2026 07:21:57 +0000 (12:51 +0530)]
drm/i915/dp: Read ALPM caps after DPCD init
For eDP read the ALPM DPCD caps after DPCD initalization and just before
the PSR init.
v2: Move intel_alpm_init to intel_edp_init_dpcd (Jouni)
v3: Add Fixes with commit-id (Jouni)
v4: Separated the alpm dpcd read caps from alpm_init and moved to
intel_edp_init_dpcd.
v5: Read alpm_caps always for eDP irrespective of the eDP version (Jouni)
v6: replace drm_dp_dpcd_readb with drm_dp_dpcd_read_byte (Jouni)
Fixes: 15438b325987 ("drm/i915/alpm: Add compute config for lobf") Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patch.msgid.link/20260304072157.1123283-1-arun.r.murthy@intel.com
Jouni Högander [Wed, 4 Mar 2026 11:30:11 +0000 (13:30 +0200)]
drm/i915/psr: Write DSC parameters on Selective Update in ET mode
There are slice row per frame and pic height parameters in DSC that needs
to be configured on every Selective Update in Early Transport mode. Use
helper provided by DSC code to configure these on Selective Update when in
Early Transport mode. Also fill crtc_state->psr2_su_area with full frame
area on full frame update for DSC calculation.
v2: move psr2_su_area under skip_sel_fetch_set_loop label
Bspec: 68927, 71709 Fixes: 467e4e061c44 ("drm/i915/psr: Enable psr2 early transport as possible") Cc: <stable@vger.kernel.org> # v6.9+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260304113011.626542-5-jouni.hogander@intel.com
Add definitions for DSC_SU_PARAMETER_SET_0_DSC0 and
DSC_SU_PARAMETER_SET_0_DSC1 registers. These are for Selective Update Early
Transport configuration.
Jouni Högander [Wed, 4 Mar 2026 11:30:08 +0000 (13:30 +0200)]
drm/i915/psr: Repeat Selective Update area alignment
Currently we are aligning Selective Update area to cover cursor fully if
needed only once. It may happen that cursor is in Selective Update area
after pipe alignment and after that covering cursor plane only
partially. Fix this by looping alignment as long as alignment isn't needed
anymore.
v2:
- do not unecessarily loop if cursor was already fully covered
- rename aligned as su_area_changed
Fixes: 1bff93b8bc27 ("drm/i915/psr: Extend SU area to cover cursor fully if needed") Cc: <stable@vger.kernel.org> # v6.9+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260304113011.626542-2-jouni.hogander@intel.com
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
This patch continues the effort to refactor worqueue APIs, which has
begun with the change introducing new workqueues:
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
drm/i915: replace use of system_wq with system_percpu_wq in the documentation
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
This patch continues the effort to refactor worqueue APIs, which has
begun with the change introducing new workqueues:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
The old wq (system_wq) will be kept for a few release cycles.
This change only update the documentation of drm/i915.
drm/i915: replace use of system_unbound_wq with system_dfl_wq
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
This patch continues the effort to refactor worqueue APIs, which has
begun with the change introducing new workqueues:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
The old system_unbound_wq will be kept for a few release cycles.
Ville Syrjälä [Tue, 3 Mar 2026 09:54:14 +0000 (11:54 +0200)]
drm/i915/vrr: Configure VRR timings after enabling TRANS_DDI_FUNC_CTL
Apparently ICL may hang with an MCE if we write TRANS_VRR_VMAX/FLIPLINE
before enabling TRANS_DDI_FUNC_CTL.
Personally I was only able to reproduce a hang (on an Dell XPS 7390
2-in-1) with an external display connected via a dock using a dodgy
type-C cable that made the link training fail. After the failed
link training the machine would hang. TGL seemed immune to the
problem for whatever reason.
BSpec does tell us to configure VRR after enabling TRANS_DDI_FUNC_CTL
as well. The DMC firmware also does the VRR restore in two stages:
- first stage seems to be unconditional and includes TRANS_VRR_CTL
and a few other VRR registers, among other things
- second stage is conditional on the DDI being enabled,
and includes TRANS_DDI_FUNC_CTL and TRANS_VRR_VMAX/VMIN/FLIPLINE,
among other things
So let's reorder the steps to match to avoid the hang, and
toss in an extra WARN to make sure we don't screw this up later.
BSpec: 22243 Cc: stable@vger.kernel.org Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reported-by: Benjamin Tissoires <bentiss@kernel.org> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15777 Tested-by: Benjamin Tissoires <bentiss@kernel.org> Fixes: dda7dcd9da73 ("drm/i915/vrr: Use fixed timings for platforms that support VRR") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260303095414.4331-1-ville.syrjala@linux.intel.com Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Jani Nikula [Wed, 25 Feb 2026 17:57:09 +0000 (19:57 +0200)]
drm/intel: add pick.h for the various "picker" helpers
Add a shared header that's used by i915, xe, and i915 display.
This allows us to drop the compat-i915-headers/i915_reg_defs.h include
from xe_reg_defs.h. All the register macro helpers were subtly pulled in
from i915 to all of xe through this.
Jani Nikula [Wed, 25 Feb 2026 17:57:07 +0000 (19:57 +0200)]
drm/xe/oa: prefer REG_MASKED_FIELD_ENABLE() and REG_MASKED_FIELD_DISABLE()
Using REG_MASKED_FIELD_ENABLE() and REG_MASKED_FIELD_DISABLE() is more
obvious to the reader than having the ternary expression inside
REG_MASKED_FIELD().
Jani Nikula [Wed, 25 Feb 2026 17:57:06 +0000 (19:57 +0200)]
drm/i915/perf: prefer REG_MASKED_FIELD_ENABLE() and REG_MASKED_FIELD_DISABLE()
Using REG_MASKED_FIELD_ENABLE() and REG_MASKED_FIELD_DISABLE() is more
obvious to the reader than having the ternary expression inside
REG_MASKED_FIELD().
Jani Nikula [Wed, 25 Feb 2026 17:57:05 +0000 (19:57 +0200)]
drm/{i915, xe}/reg: rename masked field helpers REG_MASKED_FIELD*()
The underscore prefixed masked field helper names aren't great. Rename
them REG_MASKED_FIELD(), REG_MASKED_FIELD_ENABLE(), and
REG_MASKED_FIELD_DISABLE(). This is more in line with the existing
REG_FIELD_PREP() etc. helpers, and using "field" instead of "bit" is
more accurate for the functionality.
This is done with:
sed -i 's/_MASKED_FIELD/REG_MASKED_FIELD/g' $(git grep -wl _MASKED_FIELD)
sed -i 's/_MASKED_BIT_ENABLE/REG_MASKED_FIELD_ENABLE/g' $(git grep -wl _MASKED_BIT_ENABLE)
sed -i 's/_MASKED_BIT_DISABLE/REG_MASKED_FIELD_DISABLE/g' $(git grep -wl _MASKED_BIT_DISABLE)
Jani Nikula [Wed, 25 Feb 2026 17:57:04 +0000 (19:57 +0200)]
drm/i915/lrc: switch to _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE()
Since it's now possible to use _MASKED_BIT_ENABLE() and
_MASKED_BIT_DISABLE() in the array initializer, switch to them. This
allows us to remove __MASKED_FIELD() macro.
Jani Nikula [Wed, 25 Feb 2026 17:57:03 +0000 (19:57 +0200)]
drm/i915/reg: make masked field helpers constexpr
Make it possible to use _MASKED_FIELD(), _MASKED_BIT_ENABLE() and
_MASKED_BIT_DISABLE() in contexts that require integer constant
expressions. This increases their usefulness at the small cost of making
the warnings from build time checks less helpful.
Jouni Högander [Wed, 25 Feb 2026 07:42:21 +0000 (09:42 +0200)]
drm/i915/psr: Fix for Panel Replay X granularity DPCD register handling
DP specification is saying value 0xff 0xff in PANEL REPLAY SELECTIVE UPDATE
X GRANULARITY CAPABILITY registers (0xb2 and 0xb3) means full-line
granularity. Take this into account when handling Panel Replay X
granularity informed by the panel.
Fixes: 1cc854647450 ("drm/i915/psr: Use SU granularity information available in intel_connector") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/7284 Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260225074221.1744330-2-jouni.hogander@intel.com
Jouni Högander [Wed, 25 Feb 2026 07:42:20 +0000 (09:42 +0200)]
drm/dp: Add definition for Panel Replay full-line granularity
DP specification is saying value 0xff 0xff in PANEL REPLAY SELECTIVE UPDATE
X GRANULARITY CAPABILITY registers (0xb2 and 0xb3) means full-line
granularity. Add definition for this.
Ville Syrjälä [Tue, 3 Mar 2026 10:14:17 +0000 (12:14 +0200)]
drm/i915/overlay: Fix oops on unload
Apparently I failed to test the unload case properly and
thus didn't notice that the i915_overlay_is_active() needs
i915->overlay after fetch_and_zero() already cleared it.
Stop using fetch_and_zero() and only clear the pointer at
the end to avoid the oops.
Imre Deak [Wed, 25 Feb 2026 16:46:18 +0000 (18:46 +0200)]
drm/i915/dp: Ack only the handled link service IRQs
Ack only those SST link service IRQs that will be handled, similarly to
device service IRQs. While at it add asserts that only the known/acked
link service IRQs are handled both in the MST and SST case.
Imre Deak [Wed, 25 Feb 2026 16:46:17 +0000 (18:46 +0200)]
drm/i915/dp: Ack only the handled device service IRQs
Only those IRQs should be acked that are handled, however for SST all
IRQs triggered by the sink are acked. This can be a problem for flags
that are reserved/reading zero at a given moment, but become used for
some purpose - with a side-effect if set - in a future DPCD revision.
Fix the above by acking only those device service IRQs that will be
handled. While at it add asserts that only the known/acked device
service IRQs are handled both in the MST and SST case.
projects / thirdparty / kernel / linux.git / log
