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.
Imre Deak [Wed, 25 Feb 2026 16:46:15 +0000 (18:46 +0200)]
drm/i915/dp: Check SST link status while handling link service IRQs
Move checking the link status for SST to
intel_dp_handle_link_service_irq(). This is the logical place for the
check which should only happen in response to a LINK_STATUS_CHANGE sink
IRQ. This IRQ is only supported by DPCD revision >= 1.2, so for sinks
with an older DPCD revision the link status is checked in response to
any HPD IRQ. For newer DPCD revisions however the link status check can
be made conditional on LINK_STATUS_CHANGE.
For now keep the current behavior of always forcing a link status check
regardless of LINK_STATUS_CHANGE being set or not.
This also prepares for a follow-up change sharing the link service IRQ
handler for SST and MST (on MST the link status check only happening in
response to a LINK_STATUS_CHANGE IRQ).
Imre Deak [Wed, 25 Feb 2026 16:46:14 +0000 (18:46 +0200)]
drm/i915/dp: Print debug message for a sink connected off request
So far the CONNECTED_OFF_ENTRY_REQUESTED request was accepted only
implicitly, by acking all the IRQs raised by the sink. Make this
explicit by printing a debug message.
Imre Deak [Wed, 25 Feb 2026 16:46:13 +0000 (18:46 +0200)]
drm/i915/dp: Read/ack sink count and sink IRQs for SST as it's done for MST
Read and ack the sink count, sink device and link service IRQs for SST
the same way this is done for MST, the read/ack happening in separate
steps via an ESI (Event Status Indicator) vector.
The above way is more efficient, since on newer (DPCD_REV >= 1.2) sinks
the DP_SINK_COUNT_ESI..DP_LINK_SERVICE_IRQ_VECTOR_ESI0 registers can be
read out in one AUX transaction - and the 3 last one written in one
transaction. Also this allows sharing more of the SST and MST IRQ
handling code (done as a follow-up).
For now keep the current behavior of always reading the legacy
DP_SINK_COUNT, DP_DEVICE_SERVICE_IRQ_VECTOR registers and not reading
the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 register.
v2: Document the ESI vector get/ack helper fnuctions' return value.
(Jani, Luca)
Imre Deak [Wed, 25 Feb 2026 16:46:12 +0000 (18:46 +0200)]
drm/i915/dp: Return early if getting/ackink link service IRQs fails
If getting/acking the link service IRQs fail, the short HPD handler
should bail out, falling back to a full connector detection as in case
of any AUX access failures during the HPD handling. Do this by
separating the getting/acking and handling steps of the IRQs.
Imre Deak [Wed, 25 Feb 2026 16:46:11 +0000 (18:46 +0200)]
drm/i915/dp: Return early if getting/acking device service IRQs fails
If getting/acking the device service IRQs fail, the short HPD handler
should bail out, falling back to a full connector detection as in case
of any AUX access failures during the HPD handling. Do this by
separating the getting/acking and handling steps of the IRQs.
Imre Deak [Wed, 25 Feb 2026 16:46:10 +0000 (18:46 +0200)]
drm/i915/dp: Reprobe connector if getting/acking link service IRQs fails
An AUX access failure during HPD IRQ handling should be handled by
falling back to a full connector detection, ensure that if the failure
happens while reading/acking a link service IRQ.
While at it add code comment documenting the return value of
intel_dp_check_link_service_irq().
Imre Deak [Wed, 25 Feb 2026 16:46:09 +0000 (18:46 +0200)]
drm/i915/dp: Reprobe connector if getting/acking device IRQs fails
An AUX access failure during HPD IRQ handling should be handled by
falling back to a full connector detection, ensure that if the failure
happens while reading/acking a device service IRQ.
Imre Deak [Wed, 25 Feb 2026 16:46:07 +0000 (18:46 +0200)]
drm/i915/dp: Fix the device service IRQ DPCD_REV check
The DP_DEVICE_SERVICE_IRQ_VECTOR DPCD register is supported since DPCD
REV 1.0, so read it out always. Flags added only by later DPCD revisions
are defined as reserved/must-be-zero by earlier DP Standard versions.
Imre Deak [Wed, 25 Feb 2026 16:46:06 +0000 (18:46 +0200)]
drm/i915/dp: Remove the device service IRQ handling from connector detect
The device service IRQ handling was added to the connector detect
function by
commit 09b1eb130e43 ("drm/i915: Move Displayport test request and sink
IRQ logic to intel_dp_detect()")
since some Automated Test Request IRQs couldn't be handled in the short
HPD IRQ handler context. This has been fixed meanwhile by deferring the
handling of all test request events from the IRQ handler to the hotplug
handler (intel_dp_short_pulse() -> intel_dp_test_short_pulse() ->
reprobe) and by handling all hotplug events (both for short and long HPD
pulses) in the test application.
Handling device IRQs during connector detection is not standard
compliant (the IRQs should be handled when an HPD IRQ is raised) and it
happens in a racy way with the same device IRQ handling happening from
the HPD IRQ handler (since the detect and HPD IRQ handler can run in
parallel).
Based on the above, remove the redundant call from the detect function.
Imre Deak [Wed, 25 Feb 2026 16:46:05 +0000 (18:46 +0200)]
drm/i915/dp: Don't clobber the encoder state in the HPD IRQ handler
The intel_dp_get_dpcd() function called from an HPD IRQ handler reads
out the DPRX capabilities from the sink and updates these in the
intel_dp encoder state. Since the IRQ handler can run in parallel with
the encoder/connector detection (intel_dp_detect()) which also calls
intel_dp_get_dpcd(), the encoder state can get corrupted, since the two
updates happen in a racy way.
Fix the above by checking only for any change in the sink count value in
the HPD IRQ handler, without updating the encoder state.
Note that any state change in the sink requiring an update of the
encoder state is handled via the sink's SINK_COUNT change,
RX_CAPS_CHANGED, DOWNSTREAM_PORT_STATUS_CHANGED signaling, which all
should result in a full connector detection.
Imre Deak [Wed, 25 Feb 2026 16:46:04 +0000 (18:46 +0200)]
drm/i915/dp: Handle the DOWNSTREAM_PORT_STATUS_CHANGED event
Handle the DOWNSTREAM_PORT_STATUS_CHANGED event a branch device can use
to indicate the state change of a DFP connector on the branch device.
The event is signaled in the DP_LANE_ALIGN_STATUS_UPDATED DPCD register
setting a clear-on-read flag and triggering an HPD IRQ. Accordingly keep
a cached version of the flag, updating it whenever
DP_LANE_ALIGN_STATUS_UPDATED is read. Schedule a full connector
detection from the HPD IRQ handler if the cached flag is set and clear
the cached flag at the start of detection.
Imre Deak [Wed, 25 Feb 2026 16:46:03 +0000 (18:46 +0200)]
drm/i915/dp: Handle the RX_CAP_CHANGED HPD IRQ
Handle the RX_CAP_CHANGED IRQ, which a sink can use to indicate a DPRX
capability change without disconnecting and reconnecting itself (i.e.
through a short vs. long HPD pulse). Handle the IRQ by doing a full
connector detection.
sequence would miss a new interrupt triggered after 2. and before 3.,
since the flag set in the IRQ register for this interrupt would be
cleared in step 3.
Fix the above by handling the IRQ after acking it.
Imre Deak [Wed, 25 Feb 2026 16:46:00 +0000 (18:46 +0200)]
drm/i915/dp_mst: Verify the link status always the same way
The MST link status should be always verified from the same DPCD
registers after link training. Atm, both the legacy (0x202 - 0x205) and
the ESI (0x200C - 0x200F) link status registers are used. Use always the
latter ESI version of link status registers.
v2: Propagate error from intel_dp_read_link_status(). (Jani, Luca)
Jani Nikula [Fri, 27 Feb 2026 17:17:13 +0000 (19:17 +0200)]
drm/xe/compat: remove i915_vma.h from compat
Move compat i915_vma.h to xe_display_vma.h, and remove all extra
cruft. Drop the i915_ggtt_offset() wrapper in favour of using
xe_ggtt_node_addr() directly.
The usefulness of the I915_TILING_X and I915_TILING_Y undef/define is
unclear, since uapi/drm/i915_drm.h is included in other paths as well.
The naming of struct i915_vma is a bit unfortunate in xe, but (at least
for now) a necessity for maintaining type safety on the opaque type.
Jani Nikula [Fri, 27 Feb 2026 17:17:12 +0000 (19:17 +0200)]
drm/i915: add VMA to parent interface
It's unclear what the direction of the VMA abstraction in the parent
interface should be, but convert i915_vma_fence_id() to parent interface
for starters. This paves the way for making struct i915_vma opaque
towards display.
Imre Deak [Mon, 2 Mar 2026 10:28:38 +0000 (12:28 +0200)]
drm/i915/dp: Fix DSC state computation
When computing the encoder/CRTC state multiple times, such as during
iteration over the possible pipe joiner configurations, it must be
ensured that all state is explicitly initialized each time. At the
moment, this is not guaranteed for the DSC/FEC state within the
encoder/CRTC state. In one iteration trying a pipe joiner configuration,
the DSC state may get initialized without computing the full
CRTC/encoder state due to the given joiner configuration being
impossible. When the same CRTC/encoder state is recomputed in a
subsequent iteration, the previously set non-zero - now stale - DSC/FEC
state may still be present, which is unexpected if a non-DSC
configuration is being computed.
This can lead to a DSC state mismatch error if multiple joiner
configurations are evaluated and the working configuration ultimately
turns out to be a non-DSC one.
Follow the existing pattern and compute the full (DSC/FEC) state on all
code paths (including now the non-DSC path as well) to fix the issue.
Suraj Kandpal [Mon, 2 Mar 2026 04:06:11 +0000 (09:36 +0530)]
drm/i915/backlight: Update debug log during backlight setup
With luminance_set which represents PANEL_LUMINANCE_OVERRIDE, we
have another variable to decide if we use PWM or DPCD.
Make drm_dbg_kms log represent that.
Suraj Kandpal [Mon, 2 Mar 2026 04:06:10 +0000 (09:36 +0530)]
drm/i915/backlight: Short circuit intel_dp_aux_supports_hdr_backlight
intel_dp_aux_supports_hdr_backlight() prints debug message for
intel HDR backlight version. This is fine when dealing with eDP 1.4b
and lower. When we are talking about eDP 1.5 it causes confusion in
logs since we need to use VESA AUX backlight functions but this
print causes confusion as to which path code take.
Short circuit this function with a eDP version check. Make sure this
is only called if eDP <= 1.4b
Suraj Kandpal [Mon, 2 Mar 2026 04:06:09 +0000 (09:36 +0530)]
drm/i915/backlight: Check luminance_set when disabling PWM via AUX VESA backlight
When deciding what if PWM funcs need to be disabled take into account
luminance_set too. We do this since it is also used to decide if
we are enabling PWM backlight funcs or not.
Suraj Kandpal [Mon, 2 Mar 2026 04:06:08 +0000 (09:36 +0530)]
drm/i915/backlight: Take luminance_set into account for VESA backlight
When deciding what functions to enable to help control backlight we
used to only check aux_enable. Now with PANEL_LUMINANCE_OVERRIDE in
picture we need to take care that we do not enable PWM function if
luminance_set is set.
Ville Syrjälä [Thu, 26 Feb 2026 13:38:55 +0000 (15:38 +0200)]
drm/i915/overlay: Move i915 specific code into i915_overlay.c
Relocate the i915 driver specific parts of the overlay code
into i915_overlay.c. This leaves intel_overlay.c with just
the display specific code.
The one annoyance here is the DSPCLK_GATE_D register access
being done from i830_overlay_clock_gating(). The register
definition lives on the display side as we do need to access
it on other platforms there. Since it's just one register
and bit, I decided to just duplicate that part in i915_reg.h.
Ville Syrjälä [Thu, 26 Feb 2026 13:01:13 +0000 (15:01 +0200)]
drm/i915/overlay: Don't use fetch_and_zero() in display code
We don't generally want fetch_and_zero() on the display side, so
stop using it in the display side intel_overlay_cleanup().
Fortunately we don't really have anything to do here apart from
freeing the data. And we'll keep on clearing the pointer, just
in case something somewhere cares about it.
Note that once i915_overlay_cleanup() is converted to the parent
interface we can't call it unconditionally (as xe won't have it).
So we need to keep the early bailout for overlay==NULL.
v2: Adjust the commit message since we do apparently
have fetch_and_zero() in display code as well (Jani)
v3: Skip i915_overlay_cleanup() if the overlay wasn't initialized
Ville Syrjälä [Thu, 26 Feb 2026 10:07:35 +0000 (12:07 +0200)]
drm/i915/overlay: Split 'struct intel_overlay'
Split the i915 driver specific bits from 'struct intel_overlay'
into a seaarate 'struct i915_overlay'. The latter will move to
the i915 side of the parent vs. display driver split.
The display side will also need to know the virtual address of
the register map. That now gets passed as the return value
from i915_overlay_setup(), so that the display side doesn't
need to know how the mapping was achieved.
Ville Syrjälä [Thu, 26 Feb 2026 10:07:33 +0000 (12:07 +0200)]
drm/i915/overlay: Make i830_overlay_clock_gating() i915 specific
i830_overlay_clock_gating() will remain on the i915 side of the
parent vs. display driver split. Stop using display specific stuff
inside it.
The one annoyance here is access to the display engine's
DSPCLK_GATE_D register. The proper way to deal with that might
be to move it to the display side, but that seems a bit hard right
now. So leave it where it is for now.
projects / thirdparty / kernel / linux.git / log
