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.
Ville Syrjälä [Thu, 26 Feb 2026 10:07:32 +0000 (12:07 +0200)]
drm/i915/overlay: Adjust i915 specific interfaces
Adjust the names ("i915_overlay_" prefix) and calling
convention (pass the driver agnostic 'struct drm_device'()
of the functions that will provide the remainder of the
parent driver interface to be used by the overlay display
code.
Ville Syrjälä [Thu, 26 Feb 2026 10:07:31 +0000 (12:07 +0200)]
drm/i915/overlay: Rename low level i915 specific functions
Some of the lower level functions in the overlay code will
move to the i915 side of the upcoming parent vs. display
driver split. Move all such functions to the "i915_overlay_"
namespace to make it easier to see what belongs where.
Ville Syrjälä [Thu, 26 Feb 2026 10:07:30 +0000 (12:07 +0200)]
drm/i915/overlay: Abstract buffer (un)pinning
Make the buffer (un)pinning a bit more abstract so that
the display side of the code doesn't need to know about i915
specific things (i915_ggtt_offset() and i915_vma_unpin()).
In preparation for the full parent vs. display driver split
we'll also pass in the drm_device to these functions, although
not strictly needed yet.
Ville Syrjälä [Thu, 26 Feb 2026 10:07:29 +0000 (12:07 +0200)]
drm/i915/overlay: Extract i915_overlay_cleanup()
Pull the i915 specific bits of the overlay cleanup into
a separate function (i915_overlay_cleanup()) to accommodate
the upcoming parent vs. display driver split.
For now we'll also have to pass in the overlay struct, but
that will disappear once the i915 vs. display split is completed.
Ville Syrjälä [Thu, 26 Feb 2026 10:07:28 +0000 (12:07 +0200)]
drm/i915/overlay: Extract i915_overlay_setup()
Pull the gem/gt related bits of the overlay setup into
a separate function (i915_overlay_setup()) that will eventually
move to the i915 side of the parent vs. display driver split.
For now we'll also have to pass in the overlay struct, but
that will disappear once the i915 vs. display split is completed.
Ville Syrjälä [Thu, 26 Feb 2026 10:07:27 +0000 (12:07 +0200)]
drm/i915/overlay: Extract i915_overlay_reset()
overlay->frontbuffer_bits tracking will move to the i915 side
of the parent vs. display driver split, so extract the reset
part of that into a new function (i915_overlay_reset()).
Ville Syrjälä [Thu, 26 Feb 2026 10:07:26 +0000 (12:07 +0200)]
drm/i915/overlay: Use struct drm_gem_object as the type
Use 'struct drm_gem_object' for the BO instead of 'struct
drm_i915_gem_object', to avoid having the display side
know anything about the i915 specific BO type.
v2: Correctly handle the ERR_PTR returned by
i915_overlay_obj_lookup() (Jani)
Extract the BO lookup and tiling check into a new
helper called i915_overlay_obj_lookup(). This will have to
move to the i915 side of the parent vs. display driver split.
There is a slight change here in that we now do the tiling
check before taking the modeset locks, but those locks don't
protect the BO tiling stuff in any way, so nothing is really
different here.
Note that the hardware should support X-tiled scanout also
for the overlay, but I guess no one ever bothered to hook
it up and test it. So the check should stay at least for now.
v2: Correctly handle the ERR_PTR returned by
i915_overlay_obj_lookup() (Jani)
Ville Syrjälä [Thu, 26 Feb 2026 10:07:24 +0000 (12:07 +0200)]
drm/i915/overlay: Relocate the underrun check
Move the underrun check out from intel_overlay_continue()
so that the DOVSTA register access can stay on the display
side of the parent vs. display driver split.
Pull the "is the overlay active?" check to a helper
(i915_overlay_is_active()). This will have to move to the
i915 side of the parent vs. display driver split.
Ville Syrjälä [Thu, 26 Feb 2026 10:07:21 +0000 (12:07 +0200)]
drm/i915/overlay: Track current frontbuffer_bits
Store the current frontbuffer_bits in the overlay data. The
main benefit here is that we get rid of the 'crtc->pipe'
usage from intel_overlay_flip_prepare() which will have to
move to the i915 side of the parent vs. display driver split.
And since the goal is to get rid of the crtc stuff, move those
out from intel_overlay_off_tail() into intel_overlay_switch_off()
since the i915 side doesn't use those anymore, and the display
side doesn't need those anymore after that anyway.
intel_overlay_off_tail() will itself move to the i915 side of
the fence once the driver split is done.
Ville Syrjälä [Thu, 26 Feb 2026 10:07:20 +0000 (12:07 +0200)]
drm/i915/overlay: Remove GPU hang snapshot stuff
The overlay snapshot stuff is a bit annoying because some of
it more or less of belongs on the gt side, and some on the
display side. Remove the whole thing to avoid having to deal
with it when splitting the overlay code around the i915
vs. display boundary. I don't think I've ever actually used
this for anything, so no real loss from my POV. And it can
always be resurrected later should the need arise.
Suraj Kandpal [Tue, 24 Feb 2026 03:13:22 +0000 (08:43 +0530)]
drm/i915/backlight: Remove try_vesa_interface
Some panels need VESA DPCD AUX backlight but VBT says otherwise.
This is why we try with Intel backlight interface over VESA backlight
interface. This causes a blankout on such panels without any fallback
mechanism.
Remove try_vesa_interface and use VESA AUX backlight interface as a
fallback mechanism.
While at in sneak in a small comment cleanup too.
Jani Nikula [Wed, 25 Feb 2026 14:49:16 +0000 (16:49 +0200)]
drm/i915/dpt: pass opaque struct intel_dpt around instead of i915_address_space
struct i915_address_space is used in an opaque fashion in the display
parent interface, but it's just one include away from being
non-opaque. And anyway the name is rather specific.
Switch to using the struct intel_dpt instead, which embeds struct
i915_address_space anyway. With the definition hidden in i915_dpt.c,
this can't be accidentally made non-opaque, and the type seems rather
more generic anyway.
We do have to add a new helper i915_dpt_to_vm(), as there's one case in
intel_fb_pin_to_dpt() that requires direct access to struct
i915_address_space. But this just underlines the point about opacity.
Jani Nikula [Wed, 25 Feb 2026 14:49:15 +0000 (16:49 +0200)]
drm/i915/dpt: rename struct i915_dpt to intel_dpt
Rename struct i915_dpt to intel_dpt. This may seem rather inconsistent
considering we just renamed the functions the other way round, but the
intent here is to lift struct intel_dpt to the display parent interface
as the generic opaque type for DPT instead of the very specific struct
i915_address_space.
Jani Nikula [Wed, 25 Feb 2026 14:49:13 +0000 (16:49 +0200)]
drm/i915/dpt: switch to i915 runtime pm calls
The i915 specific code doesn't need to, and should not, call the display
runtime pm functions. Just call the i915 functions directly, instead of
routing through the parent interface.
Jani Nikula [Wed, 25 Feb 2026 14:49:11 +0000 (16:49 +0200)]
drm/i915/dpt: remove display/intel_dpt.h
The remaining functions declared in intel_dpt.h are i915 specific, and
so are the users, so we can move them to i915_dpt.h. There are some
useless intel_dpt.h includes around that we can remove.
Jani Nikula [Wed, 25 Feb 2026 14:49:08 +0000 (16:49 +0200)]
drm/i915/dpt: pass obj, size instead of framebuffer to intel_dpt_create()
Split the size determination between caller and callee to drop the
dependency on struct intel_framebuffer from DPT code, but avoid adding a
dependency on I915_GTT_PAGE_SIZE in the caller side.
Pass zero size to let intel_dpt_create() handle the regular obj->size
case, but remapped size if fb needs stride remap.
Imre Deak [Thu, 19 Feb 2026 18:28:23 +0000 (20:28 +0200)]
drm/i915/dp_tunnel: Send BW change notification after tunnel creation
Detecting a bandwidth change for a sink connected through a DP tunnel
depends on updating the sink's DPRX link rate and lane count.
detect_new_tunnel() -> update_tunnel_state() updates the link
configuration only if the tunnel state changes. However, after the
tunnel is created and bandwidth allocation mode is enabled, the tunnel
state itself may remain unchanged.
Record the sink bandwidth before creating the tunnel and compare it to
the bandwidth after tunnel creation and enabling bandwidth allocation
mode, ensuring that any bandwidth change is detected and userspace is
notified accordingly.
Imre Deak [Thu, 19 Feb 2026 18:28:21 +0000 (20:28 +0200)]
drm/i915/dp_tunnel: Split update_tunnel_state()
Split update_tunnel_state() into two helpers: one that updates the
tunnel state, and another that detects whether the tunnel bandwidth
has changed.
This prepares for a follow-up change that needs to compare the current
bandwidth against the value from before the DP tunnel was detected and
bandwidth allocation mode was enabled.
While at it, document the return value of update_tunnel_state().
Imre Deak [Thu, 19 Feb 2026 18:28:20 +0000 (20:28 +0200)]
drm/i915/dp_tunnel: Simplify detection of link BW change
update_tunnel_state() checks whether a tunnel state change (e.g.
available tunnel bandwidth) affects the list of valid modes for the
sink connected through the tunnel. If so, its caller sends a hotplug
event so userspace can re-enumerate the modes.
A change in tunnel bandwidth does not affect the mode list if the
bandwidth was above the sink's DPRX bandwidth both before and after the
update, since in that case the effective bandwidth remains limited by
the DPRX.
As get_current_link_bw() via intel_dp_max_link_data_rate() already
returns bandwidth values clamped to the DPRX limit, the condition for
detecting a mode list change can be simplified to:
old_bw != new_bw
Remove the explicit checks for whether the bandwidth was below the
maximum DPRX bandwidth before and after the update, and rely on the
clamped bandwidth values instead.
projects / thirdparty / linux.git / log
