Matthew Brost [Thu, 15 Jan 2026 00:45:46 +0000 (16:45 -0800)]
drm/xe: Do not preempt fence signaling CS instructions
If a batch buffer is complete, it makes little sense to preempt the
fence signaling instructions in the ring, as the largest portion of the
work (the batch buffer) is already done and fence signaling consists of
only a few instructions. If these instructions are preempted, the GuC
would need to perform a context switch just to signal the fence, which
is costly and delays fence signaling. Avoid this scenario by disabling
preemption immediately after the BB start instruction and re-enabling it
after executing the fence signaling instructions.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Carlos Santa <carlos.santa@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260115004546.58060-1-matthew.brost@intel.com
Michal Wajdeczko [Sat, 21 Feb 2026 15:22:30 +0000 (16:22 +0100)]
drm/xe/pf: Don't use LMTT page size if no LMTT
While today all our DGFX platforms have LMTT, we already started
preparation to do not rely on this assumption. Add check for the
LMTT presence and return default page size as VRAM/LMEM alignment
if there is no LMTT.
Michal Wajdeczko [Sat, 21 Feb 2026 15:22:29 +0000 (16:22 +0100)]
drm/xe/pf: Don't force 2MB VRAM alignment
There is no need to always request VRAM BO to have 2MB alignment
as for now this is required by the LMTT only, which could be not
present on some platforms with VRAM.
Shuicheng Lin [Mon, 23 Feb 2026 16:23:53 +0000 (16:23 +0000)]
drm/xe/guc: Refine CT queue checks and log formatting
Fix three code-level cleanups in xe_guc_ct.c:
- Use SZ_4K for the queue size alignment assertion in
xe_guc_ct_queue_proc_time_jiffies().
- Drop an unused local variable in guc_ct_send_wait_for_retry().
- Add missing trailing newlines in CT error/warn log messages.
These changes keep behavior unchanged while improving correctness checks
and log formatting.
Shuicheng Lin [Mon, 23 Feb 2026 16:23:52 +0000 (16:23 +0000)]
drm/xe/guc: Accumulate CT H2G retry sleep budget
guc_ct_send_wait_for_retry() introduced sleep_total_ms as a
budget guard, but never incremented it. As a result, the
"about 1 second" bailout condition never triggers in the H2G
backpressure path.
Accumulate the delay returned by xe_sleep_exponential_ms() into
sleep_total_ms so the timeout logic works as intended.
Fixes: 943c4d0637cf ("drm/xe/guc: Limit sleep while waiting for H2G credits") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260223162350.3205364-5-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Matt Roper [Tue, 24 Feb 2026 00:11:33 +0000 (16:11 -0800)]
drm/xe/xe2_hpg: Drop invalid workaround Wa_15010599737
Wa_15010599737 was a workaround originally proposed (and ultimately
rejected) for DG2-G10. There's no record of it ever being relevant or
even considered for any other platforms.
The specific bit this workaround was setting is documented as "This bit
should be set to 1 for the DX9 API and 0 for all other APIs" which means
that it should almost always be left at the default value of 0 on Linux.
The register itself is directly accessible from userspace, so in the
special cases where it might be relevant (e.g., Wine/Proton running
Windows DX9 apps), the userspace drivers already have the ability to
change the setting without involvement of the kernel.
Matt Roper [Tue, 24 Feb 2026 00:11:32 +0000 (16:11 -0800)]
drm/xe: Consolidate workaround entries for Wa_18041344222
Wa_18041344222 applies to all graphics versions from 20.01 through 30.00
(inclusive). Consolidate the RTP entries into a single range-based
entry.
v2:
- Drop the FUNC(xe_rtp_match_not_sriov_vf) to align with commit a800b95c2498 ("drm/xe/xe2hpg: Remove SRIOV VF check for
Wa_18041344222") and commit 0ffe9dcf260b ("drm/xe/xe3: Remove SRIOV
VF check for Wa_18041344222") which just landed. (Shuicheng)
drm/xe/uapi: Introduce a flag to disallow vm overcommit in fault mode
Some compute applications may try to allocate device memory to probe
how much device memory is actually available, assuming that the
application will be the only one running on the particular GPU.
That strategy fails in fault mode since it allows VM overcommit.
While this could be resolved in user-space it's further complicated
by cgroups potentially restricting the amount of memory available
to the application.
Introduce a vm create flag, DRM_XE_VM_CREATE_NO_VM_OVERCOMMIT, that
allows fault mode to mimic the behaviour of !fault mode WRT this. It
blocks evicting same vm bos during VM_BIND processing. However,
it does *not* block evicting same-vm bos during pagefault
processing, preferring eviction rather than VM banning in
OOM situations.
Cc: John Falkowski <john.falkowski@intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260204153320.17989-1-thomas.hellstrom@linux.intel.com
Matt Roper [Fri, 20 Feb 2026 17:27:45 +0000 (09:27 -0800)]
drm/xe: Consolidate workaround entries for Wa_14023061436
Wa_14023061436 applies to all graphics versions from 30.00 through 30.05
(inclusive) since there is currently no IP that uses version 30.02.
Consolidate the RTP rules into a single range.
Matt Roper [Fri, 20 Feb 2026 17:27:44 +0000 (09:27 -0800)]
drm/xe/wa_oob: Consolidate some OOB rules
Given the new policy of allowing graphics/media IP ranges to extend over
unused IP versions, we can consolidate some of the OOB workaround rules
and simplify the table. If new IP variants eventually show up that use
these unused versions (e.g., media version 30.01, graphics versions
20.03 / 30.02, etc.), and if an existing workaround does not extend to
that new intermediate version, the ranges will be split back apart as
part of the enablement work for that new IP version.
Matt Roper [Fri, 20 Feb 2026 17:27:38 +0000 (09:27 -0800)]
drm/xe: Consolidate workaround entries for Wa_14019877138
Wa_14019877138 applies to all graphics versions from 12.55 through 20.04
(inclusive) that have a render engine. Consolidate the RTP entries into
a single range-based entry.
Note that the DG2 entry for this workaround was missing an
ENGINE_CLASS(RENDER) rule; that mistake is fixed by this consolidation.
Matt Roper [Fri, 20 Feb 2026 17:27:34 +0000 (09:27 -0800)]
drm/xe: Consolidate workaround entries for Wa_16021639441
Wa_16021639441 applies to all graphics versions from 20.01 through 20.04
(inclusive) and all media versions from 13.01 to 20.00 (inclusive).
Consolidate the RTP entries into a single range-based entry.
Also drop the reference to Wa_18032095049 which was only relevant to
pre-production platforms that we no longer support.
Matt Roper [Fri, 20 Feb 2026 17:27:29 +0000 (09:27 -0800)]
drm/xe: Consolidate workaround entries for Wa_16021865536
Wa_16021865536 applies to both media versions 30.00 and 30.02; since
version 30.01 is currently unused we can consolidate the two RTP entries
into a single range-based entry.
Matt Roper [Fri, 20 Feb 2026 17:27:28 +0000 (09:27 -0800)]
drm/xe: Consolidate workaround entries for Wa_16028005424
Wa_16028005424 applies to all media IPs from 13.01 to 35.00 (inclusive)
and all graphics IPs from 30.00 and 30.05 (inclusive). Conslidate the
multiple RTP entries into a single range-based entry.
Matt Roper [Fri, 20 Feb 2026 17:27:27 +0000 (09:27 -0800)]
drm/xe: Consolidate workaround entries for Wa_14019449301
Wa_14019449301 applies to both media IP 13.01 and 20.00 and none of the
version numbers between those are used. Conslidate the two entries into
a single range entry.
Matt Roper [Fri, 20 Feb 2026 17:27:26 +0000 (09:27 -0800)]
drm/xe: Consolidate workaround entries for Wa_16021867713
Wa_16021867713 applies to every single media IP from 13.00 to 30.02
(inclusive). We can consolidate the multiple per-version entries down
to a single range entry.
Matt Roper [Fri, 20 Feb 2026 17:27:25 +0000 (09:27 -0800)]
drm/xe/wa: Document new policy regarding workaround IP ranges
During early Xe driver development, our policy for applying workarounds
to ranges of IP versions was to only use GRAPHICS_VERSION_RANGE and
MEDIA_VERSION_RANGE rules when all of the affected IP versions had
consecutive version numbers; otherwise separate RTP entries should be
used. For example, a workaround that applies to all Xe2-based platforms
would be implemented in the driver with two RTP entries: one using
GRAPHICS_VERSION_RANGE(2001, 2002) and the other using
GRAPHICS_VERSION(2004). This ensured that if a new IP variant showed up
in the future with currently unused version 20.03, an old workaround
entry wouldn't automatically apply to it by accident (and we could
always consolidate those two distinct entries in the future if the
workaround database did explicitly indicate that 20.03 also needed the
workaround).
Now that we're a couple years down the road with this driver, the number
of IP versions supported is much larger (several Xe2 20.xx versions,
several Xe3 30.xx versions, and a couple Xe3p 35.xx versions). When new
workarounds are discovered that need to apply to a wide range of IPs,
it's becoming more of a pain to create independent entries for each
non-contiguous range of versions, and the general consensus is that we
should revisit our previous policy and start allowing use of
VERSION_RANGE constructs for non-contiguous version ranges.
Note that allowing ranges that cover currently unused versions will
require additional care if/when some of those intermediate version
numbers start being used in the future. We'll need to re-check every
workaround that has a range including the new IP version and check the
hardware database to see whether the workaround also applies to the new
version (no code change required) or whether we need to split the
existing range into two separate ranges that don't cover the new
version. The platform enabling engineers are willing to take on this
extra review burden at the time we first enable a new IP in the driver
(see lore link below for one recent discussion).
Update the kerneldoc for the workaround file to make the new policy
official.
Matt Roper [Fri, 20 Feb 2026 17:27:24 +0000 (09:27 -0800)]
drm/xe/pvc: Drop pre-prod workarounds
Production PVC hardware had a graphics stepping of C0. Xe1 platforms
already aren't officially supported by the Xe driver, but pre-production
steppings are especially out of scope (and 'has_pre_prod_wa' is not set
in the device descriptor). Drop the workarounds that aren't relevant to
production hardware.
v2:
- Drop the stream->override_gucrc which is no longer set anywhere after
the removal of Wa_1509372804. (Bala)
- Drop xe_guc_rc_set_mode / xe_guc_rc_unset_mode which are no longer
used after the removal of Wa_1509372804.
Matt Roper [Fri, 20 Feb 2026 17:27:23 +0000 (09:27 -0800)]
drm/xe/mtl: Drop pre-prod workarounds Wa_14015795083 & Wa_14014475959
Wa_14015795083 and Wa_14014475959 only apply to early steppings of
Xe_LPG that appeared only in pre-production hardware (in fact
Wa_14014475959 wasn't supposed to apply to _any_ steppings of version
12.71). Xe1 platforms already aren't officially supported by the Xe
driver, but pre-production steppings are especially out of scope (and
'has_pre_prod_wa' is not set in the device descriptor). Drop both
workarounds.
Varun Gupta [Mon, 23 Feb 2026 06:19:06 +0000 (11:49 +0530)]
drm/xe: Add prefetch fault support for Xe3p
Xe3p hardware prefetches memory ranges and notifies software via an
additional bit (bit 11) in the page fault descriptor that the fault
was caused by prefetch.
Extract the prefetch bit from the fault descriptor and echo it in the
response (bit 6) only when the page fault handling fails. This allows
the HW to suppress CAT errors for unsuccessful prefetch faults.
For prefetch faults that fail, increment stats counter without verbose
logging to avoid spamming the log. The prefetch flag is packed into
BIT(7) of the access_type field to avoid growing the consumer struct.
Based on original patches by Brian Welty <brian.welty@intel.com> and
Priyanka Dandamudi <priyanka.dandamudi@intel.com>.
Bspec: 59311 Cc: Matthew Brost <matthew.brost@intel.com> Cc: Priyanka Dandamudi <priyanka.dandamudi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Varun Gupta <varun.gupta@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260223061906.1420883-3-varun.gupta@intel.com
Varun Gupta [Mon, 23 Feb 2026 06:19:05 +0000 (11:49 +0530)]
drm/xe: Add counter for invalid prefetch pagefaults
Add a stats counter for invalid prefetch page faults to avoid
excessive logging.
Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Varun Gupta <varun.gupta@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260223061906.1420883-2-varun.gupta@intel.com
drm/xe/sa: Add lockdep annotations for SA manager swap_guard
Annotate the SA manager init path to model taking swap_guard while under
reclaim context. This helps lockdep catch potential circular dependencies
between fs_reclaim and swap_guard in debug builds. Without this annotation,
lockdep is unaware of this chain until the shrinker runs.
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260220055519.2485681-8-satyanarayana.k.v.p@intel.com
drm/xe/vf: Fix fs_reclaim warning with CCS save/restore BB allocation
CCS save/restore batch buffers are attached during BO allocation and
detached during BO teardown. The shrinker triggers xe_bo_move(), which is
used for both allocation and deletion paths.
When BO allocation and shrinking occur concurrently, a circular locking
dependency involving fs_reclaim and swap_guard can occur, leading to a
deadlock such as:
To avoid this, the BB pointer and SA are allocated using xe_bb_alloc()
before taking lock and SA is initialized using xe_bb_init() preventing
reclaim from being invoked in this context.
Fixes: 864690cf4dd62 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260220055519.2485681-7-satyanarayana.k.v.p@intel.com
drm/sa: Split drm_suballoc_new() into SA alloc and init helpers
drm_suballoc_new() currently both allocates the SA object using kmalloc()
and searches for a suitable hole in the sub-allocator for the requested
size. If SA allocation is done by holding sub-allocator mutex, this design
can lead to reclaim safety issues.
By splitting the kmalloc() step outside of the critical section, we allow
the memory allocation to use GFP_KERNEL (reclaim-safe) while ensuring that
the initialization step that holds reclaim-tainted locks (sub-allocator
mutex) operates in a reclaim-unsafe context with pre-allocated memory.
This separation prevents potential deadlocks where memory reclaim could
attempt to acquire locks that are already held during the sub-allocator
operations.
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: Maarten Lankhorst <dev@lankhorst.se> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Maarten Lankhorst <dev@lankhorst.se> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260220055519.2485681-6-satyanarayana.k.v.p@intel.com
Shuicheng Lin [Thu, 19 Feb 2026 23:35:19 +0000 (23:35 +0000)]
drm/xe/sync: Fix user fence leak on alloc failure
When dma_fence_chain_alloc() fails, properly release the user fence
reference to prevent a memory leak.
Fixes: adda4e855ab6 ("drm/xe: Enforce correct user fence signaling order using") Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260219233516.2938172-6-shuicheng.lin@intel.com
Shuicheng Lin [Thu, 19 Feb 2026 23:35:18 +0000 (23:35 +0000)]
drm/xe/sync: Cleanup partially initialized sync on parse failure
xe_sync_entry_parse() can allocate references (syncobj, fence, chain fence,
or user fence) before hitting a later failure path. Several of those paths
returned directly, leaving partially initialized state and leaking refs.
Route these error paths through a common free_sync label and call
xe_sync_entry_cleanup(sync) before returning the error.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260219233516.2938172-5-shuicheng.lin@intel.com
Michal Wajdeczko [Wed, 18 Feb 2026 20:55:51 +0000 (21:55 +0100)]
drm/xe/pf: Skip VRAM auto-provisioning if already provisioned
In case VF's VRAM provisioning using sysfs is done by the admin
prior to VFs enabling, this provisioning will be lost as PF will
run VRAM auto-provisioning anyway. To avoid that skip this auto-
provisioning if any VF has been already provisioned with VRAM.
To help admin find any mistakes, add diagnostics messages about
which VFs were provisioned with VRAM and which were missed.
Michal Wajdeczko [Wed, 18 Feb 2026 20:55:49 +0000 (21:55 +0100)]
drm/xe/pf: Don't check for empty config
We already turn off VFs auto-provisioning once we detect manual VFs
provisioning over the debugfs, so we can skip additional check for
all VFs configs being still empty.
Michal Wajdeczko [Wed, 18 Feb 2026 20:55:47 +0000 (21:55 +0100)]
drm/xe/pf: Use migration-friendly VRAM auto-provisioning
Instead of trying very hard to find the largest fair VRAM (aka LMEM)
size that could be allocated for VFs on the current tile, pick some
smaller rounded down to power-of-two value that is more likely to be
provisioned in the same manner by the other PF instances.
In some cases, the outcome of above calculation might not be optimal,
but it's expected that admin will do fine-tuning using sysfs files.
Michal Wajdeczko [Wed, 18 Feb 2026 20:55:46 +0000 (21:55 +0100)]
drm/xe/pf: Allow to change VFs VRAM quota using sysfs
On current discrete platforms, PF will provision all VFs with a fair
amount of the VRAM (LMEM) during VFs enabling. However, in some cases
this automatic VRAM provisioning might be either non-reproducible or
sub-optimal. This could break VF's migration or impact performance.
Expose per-VF VRAM quota read-write sysfs attributes to allow admin
change default VRAM provisioning performed by the PF.
Above values represent total provisioned VRAM from all tiles where
VFs were assigned, and currently it's from all tiles always.
Note that changing VRAM provisioning is only possible when VF is
not running, otherwise GuC will complain. To make sure that given
VF is idle, triggering VF FLR might be needed.
Michal Wajdeczko [Wed, 18 Feb 2026 20:55:45 +0000 (21:55 +0100)]
drm/xe/pf: Add functions for VRAM provisioning
We already have functions to configure VF LMEM (aka VRAM) on the
tile/GT level, used by the auto-provisioning and debugfs, but we
also need functions that will work on the device level that will
configure VRAM on all tiles at once.
We will use these new functions in upcoming patch.
Michal Wajdeczko [Wed, 18 Feb 2026 20:55:44 +0000 (21:55 +0100)]
drm/xe/pf: Add locked variants of VRAM configuration functions
We already have few functions to configure LMEM (aka VRAM) but they
all are taking master mutex. Split them and expose locked variants
to allow use by the caller who already hold this mutex.
Michal Wajdeczko [Wed, 18 Feb 2026 20:55:43 +0000 (21:55 +0100)]
drm/xe/pf: Expose LMTT page size
The underlying LMTT implementation already provides the info about
the page size it is using. There is no need to have a separate
helper function that is making assumption about the required size.
Tomasz Lis [Fri, 13 Feb 2026 14:00:08 +0000 (15:00 +0100)]
drm/xe/guc: Increase GuC log sizes in debug builds
Increase event log size for GuC debug to 16MB, and for general debug
to 8MB. This allows for useful debug even if performance-affecting
DRM_XE_DEBUG_GUC is not enabled.
Without this change, GuC logs gathered by CI are useless for debug
due to limited size, which translates to time frame not even able
to cover cleanup after test.
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260213140008.1473400-1-tomasz.lis@intel.com
Matt Roper [Wed, 18 Feb 2026 22:09:15 +0000 (14:09 -0800)]
drm/xe/reg_sr: Allow register_save_restore_check debugfs to verify LRC values
reg_sr programming that applies to an engines LRC cannot be verified by
a simple CPU-based register readout because the reg_sr's values may not
be in effect if no context is executing on the hardware at the time we
check. Instead, we should verify correct reg_sr application by
searching for the register in the default_lrc.
Matt Roper [Wed, 18 Feb 2026 22:09:14 +0000 (14:09 -0800)]
drm/xe: Add facility to lookup the value of a register in a default LRC
An LRC is stored in memory as a special batchbuffer that hardware will
execute to re-load state when switching to the context; it's a
collection of register values (encoded as MI_LOAD_REGISTER_IMM commands)
and other state instructions (e.g., 3DSTATE_*). The value that will be
loaded for a given register can be determined by parsing the batchbuffer
to find MI_LRI commands and extracting the value from the offset/value
pairs it contains. Add functions to do this, which will be used in a
future patch to help verify that our expected reg_sr programming is in
place.
The implementation here returns the value as soon as it finds a match in
the LRC. Technically a register could appear multiple times (either due
to memory corruption or a hardware defect) and the last value
encountered would be the one in effect when the context resumes
execution. We can adjust the logic to keep looking and return the last
match instead of first in the future if we encounter real-world cases
where this would assist with debugging.
Matt Roper [Wed, 18 Feb 2026 22:09:13 +0000 (14:09 -0800)]
drm/xe/reg_sr: Add debugfs to verify status of reg_sr programming
When applying save-restore register programming for workarounds, tuning
settings, and general device configuration we assume the programming was
successful. However there are a number of cases where the desired
reg_sr programming can become lost:
- workarounds implemented on the wrong RTP table might not get
saved/restored at the right time leading to, for example, failure to
re-apply the programming after engine resets
- some hardware registers become "locked" and can no longer be updated
after firmware or the driver finishes initializing them
- sometimes the hardware teams just made a mistake when documenting the
register and/or bits that needed to be programmed
Add a debugfs entry that will read back the registers referenced on a
GT's save-restore lists and print any cases where the desired
programming is no longer in effect. Such cases might indicate the
presence of a driver/firmware bug, might indicate that the documentation
we were following has a mistake, or might be benign (occasionally
registers have broken read-back capability preventing verification, but
previous writes were still successful and effective).
For now we only verify the GT and engine reg_sr lists. Verifying the
LRC list will require checking the expected programming against the
default_lrc contents, not the live registers (which may not reflect the
reg_sr programming if no context is actively running).
Matt Roper [Wed, 18 Feb 2026 22:09:12 +0000 (14:09 -0800)]
drm/xe/reg_sr: Don't process gt/hwe lists in VF
There are a few different reg_sr lists managed by the driver for
workarounds/tuning:
- gt->reg_sr
- hwe->reg_sr
- hwe->reg_lrc
The first two are not relevant to SRIOV VFs; a VF KMD does not have
access to the registers that appear on this list and it is the PF KMD's
responsibility to apply such programming on behalf of the entire system.
However the third list contains per-client values that the VF KMD needs
to ensure are incorporated whenever a new LRC is created.
Handling of reg_sr lists comes in two steps: processing an RTP table to
build a reg_sr from the relevant entries, and then applying the contents
of the reg_sr. Skipping the RTP processing (resulting in an empty
reg_sr) or skipping the application of a reg_sr are both valid ways to
avoid having a VF accidentally try to write registers it doesn't have
access to. In commit c19e705ec981 ("drm/xe/vf: Stop applying
save-restore MMIOs if VF") and commit 92a5bd302458 ("drm/xe/vf: Unblock
xe_rtp_process_to_sr for VFs") we adjusted the drivers behavior to
always process the RTP table into a reg_sr and just skipped the
application step. This works fine functionally, but can lead to
confusion during debugging since facilities like the debugfs
'register-save-restore' will still report a bunch of registers that the
VF KMD isn't actually trying to handle. It will also mislead other
upcoming debug changes.
Let's go back to skipping the RTP => reg_sr processing step, but only
for GT / hwe tables this time. This will allow LRC reg_sr handling to
continue to work, but will ensure that gt->reg_sr and hwe->reg_sr remain
empty and that debugfs reporting more accurately reflects the KMD's
behavior.
v2:
- Also skip the hwe processing in hw_engine_setup_default_state() and
xe_reg_whitelist_process_engine().
v3:
- Handle skipping via an additional parameter passed to
xe_rtp_process_to_sr() rather than adding conditions at each
callsite. (Ashutosh)
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Harish Chegondi <harish.chegondi@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patch.msgid.link/20260218-sr_verify-v4-1-35d6deeb3421@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Matt Roper [Fri, 6 Feb 2026 22:30:59 +0000 (14:30 -0800)]
drm/xe/wa: Steer RMW of MCR registers while building default LRC
When generating the default LRC, if a register is not masked, we apply
any save-restore programming necessary via a read-modify-write sequence
that will ensure we only update the relevant bits/fields without
clobbering the rest of the register. However some of the registers that
need to be updated might be MCR registers which require steering to a
non-terminated instance to ensure we can read back a valid, non-zero
value. The steering of reads originating from a command streamer is
controlled by register CS_MMIO_GROUP_INSTANCE_SELECT. Emit additional
MI_LRI commands to update the steering before any RMW of an MCR register
to ensure the reads are performed properly.
Note that needing to perform a RMW of an MCR register while building the
default LRC is pretty rare. Most of the MCR registers that are part of
an engine's LRCs are also masked registers, so no MCR is necessary.
Fixes: f2f90989ccff ("drm/xe: Avoid reading RMW registers in emit_wa_job") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patch.msgid.link/20260206223058.387014-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Matthew Brost [Tue, 17 Feb 2026 20:05:52 +0000 (12:05 -0800)]
drm/xe: Convert GT stats to per-cpu counters
Current GT statistics use atomic64_t counters. Atomic operations incur
a global coherency penalty.
Transition to dynamic per-cpu counters using alloc_percpu(). This allows
stats to be incremented via this_cpu_add(), which compiles to a single
non-locking instruction. This approach keeps the hot-path updates local
to the CPU, avoiding expensive cross-core cache invalidation traffic.
Use for_each_possible_cpu() during aggregation and clear operations to
ensure data consistency across CPU hotplug events.
Remove the unnecessary VRAM channel entry introduced in xe_hwmon_channel.
Without this, adding any new hwmon channel causes extra VRAM channel
to appear. This remained unnoticed earlier because VRAM was the
final xe hwmon channel.
v2: Use MAX_VRAM_CHANNELS with in_range() instead of
CHANNEL_VRAM_N_MAX. (Raag)
Arnd Bergmann [Mon, 16 Feb 2026 13:46:01 +0000 (14:46 +0100)]
drm/pagemap: pass pagemap_addr by reference
Passing a structure by value into a function is sometimes problematic,
for a number of reasons. Of of these is a warning from the 32-bit arm
compiler:
drivers/gpu/drm/drm_gpusvm.c: In function '__drm_gpusvm_unmap_pages':
drivers/gpu/drm/drm_gpusvm.c:1152:33: note: parameter passing for argument of type 'struct drm_pagemap_addr' changed in GCC 9.1
1152 | dpagemap->ops->device_unmap(dpagemap,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1153 | dev, *addr);
| ~~~~~~~~~~~
This particular problem is harmless since we are not mixing compiler versions
inside of the compiler. However, passing this by reference avoids the warning
along with providing slightly better calling conventions as it avoids an
extra copy on the stack.
Fixes: 75af93b3f5d0 ("drm/pagemap, drm/xe: Support destination migration over interconnect") Fixes: 2df55d9e66a2 ("drm/xe: Support pcie p2p dma as a fast interconnect") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20260216134644.1025365-1-arnd@kernel.org Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
With the intermediate state gone, no longer useful. Just check against
NULL where needed.
After looking carefully, the check for allocated in xe_fb_pin.c is
unneeded. vma->node is never NULL. The check is specifically only
to check if vma->node == the bo's root tile ggtt_obj.
This extra step is easier to handle inside xe_ggtt.c and makes
xe_ggtt_node_allocated a simple null check instead, as the intermediate
state 'allocated but not inserted' is no longer used.
Privatize xe_ggtt_node_fini() and init() as they're no longer used
outside of xe_ggtt.c
The previous code was using a complicated system with 2 balloons to
set GGTT size and adjust GGTT offset. While it works, it's overly
complicated.
A better approach is to set the offset and size when initializing GGTT,
this removes the need for adding balloons. The resize function only
needs readjust ggtt->start to have GGTT at the new offset.
This removes the need to manipulate the internals of xe_ggtt outside
of xe_ggtt, and cleans up a lot of now unneeded code.
Matthew Brost [Thu, 12 Feb 2026 20:42:27 +0000 (12:42 -0800)]
drm/xe: Avoid touching consumer fields in GuC pagefault ack
The GuC pagefault acknowledgment code is designed to extract the fields
needed for the acknowledgment from the producer-stored message so that
the consumer fields can be overloaded to return additional information.
The ASID is stored in the producer message; extract it from there to
future‑proof this logic.
Arvind Yadav [Thu, 12 Feb 2026 06:59:20 +0000 (12:29 +0530)]
drm/xe/xe2: Apply Wa_14024997852
Applied Wa_14024997852 to Graphics version 20.01 to 20.04
Whitelist registers needed for userspace to control autostrip on xe2.
v2:
- set Bit 31 of FF_MODE, for TE autostrip disable (Nitin)
v3:
- Need to whitelist these for Xe2 IPs (MATT R)
v4:
- Combine these into a single range for simplicity:(2001, 3005)
(MATT R)
Piotr Piórkowski [Wed, 11 Feb 2026 17:14:41 +0000 (18:14 +0100)]
drm/xe: Force EXEC_QUEUE_FLAG_KERNEL for kernel internal VMs
VMs created without an associated xe_file originate from kernel
contexts and should use kernel exec queues. Ensure such VMs
create bind exec queues with EXEC_QUEUE_FLAG_KERNEL set.
Let's ensure bind exec queues created for kernel VMs are always
marked with EXEC_QUEUE_FLAG_KERNEL.
Matt Roper [Wed, 11 Feb 2026 23:47:36 +0000 (15:47 -0800)]
drm/xe: Stop applying Wa_16018737384 from Xe3 onward
Wa_16018737384 is one of the rare cases where the hardware teams mark a
workaround as "driver change required" rather than "permanent/temporary
workaround" in the internal workaround database, signifying that the
implementation details of the workaround should just be considered
standard programming instructions on all platforms going forward. Cases
like this are the only time that using XE_RTP_END_VERSION_UNDEFINED as an
upper bound for a workaround's IP range is warranted and correct.
However in this specific case, the register bit in question (0xE4F0[1])
simply no longer exists in hardware from Xe3 onward. Trying to write to
that bit on Xe3 or Xe3p platforms is harmless and just doesn't have any
effect, but it's possible that the register bit could get repurposed to
control something else down the road on future platforms. To avoid any
surprises in the future we should replace the unbounded upper bound in
our RTP table with a value that accurately reflects that Wa_16018737384
can only apply to Xe2 platforms.
Matt Roper [Tue, 10 Feb 2026 18:25:19 +0000 (10:25 -0800)]
drm/xe/xe3p_xpc: Add new XeCore fuse registers to VF runtime regs
SRIOV VFs do not automatically have access to the XeCore fuse registers.
Add the two new registers that show up on Xe3p_XPC to the runtime
register list to grant VFs access. Since there's a single runtime
register list for all Xe3p, this will technically also grant access on
Xe3p_LPG platforms where the registers don't exist, but that should be
harmless since even if a VF tries to read a non-existent register on
those platforms it will just get back a sensible value of 0x0.
Fixes: e8100643ff01 ("drm/xe/xe3p_xpc: XeCore mask spans four registers") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Ngai-Mint Kwan <ngai-mint.kwan@linux.intel.com> Link: https://patch.msgid.link/20260210182519.206952-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Since the introduction of DRM wedged event, there are now a few different
procedures to recover the device depending on selected recovery method.
Update the error log to reflect this and point the user to correct
documentation for it.
With commit a69d1ab971a6 ("mm: Fix a hmm_range_fault() livelock / starvation problem")
device-to-device migration is not functional again and the
disabling can be reverted.
Add the above commit as a Fixes: tag in order for the revert to not
take place unless that commit is present.
Shuicheng Lin [Mon, 2 Feb 2026 18:18:54 +0000 (18:18 +0000)]
drm/xe: Make xe_modparam.force_vram_bar_size signed
vram_bar_size is registered as an int module parameter and is documented
to accept negative values to disable BAR resizing.
Store it as an int in xe_modparam as well, so negative values work as
intended and the module_param type matches.
Fixes: 80742a1aa26e ("drm/xe: Allow to drop vram resizing") Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260202181853.1095736-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
drm/xe/vf: Avoid reading media version when media GT is disabled
When the media GT is not allowed, a VF must not attempt to read
the media version from the GuC. The GuC may not be loaded, and
any attempt to communicate with it would result in a timeout
and a VF probe failure:
Let's skip reading the media version for VFs when the media GT is not
allowed.
v2: move the condition directly to the VF path
Fixes: 7abd69278bb5 ("drm/xe/configfs: Add attribute to disable GT types") Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260202115041.2863357-1-piotr.piorkowski@intel.com Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Thomas Hellström [Tue, 10 Feb 2026 11:56:53 +0000 (12:56 +0100)]
mm: Fix a hmm_range_fault() livelock / starvation problem
If hmm_range_fault() fails a folio_trylock() in do_swap_page,
trying to acquire the lock of a device-private folio for migration,
to ram, the function will spin until it succeeds grabbing the lock.
However, if the process holding the lock is depending on a work
item to be completed, which is scheduled on the same CPU as the
spinning hmm_range_fault(), that work item might be starved and
we end up in a livelock / starvation situation which is never
resolved.
This can happen, for example if the process holding the
device-private folio lock is stuck in
migrate_device_unmap()->lru_add_drain_all()
sinc lru_add_drain_all() requires a short work-item
to be run on all online cpus to complete.
A prerequisite for this to happen is:
a) Both zone device and system memory folios are considered in
migrate_device_unmap(), so that there is a reason to call
lru_add_drain_all() for a system memory folio while a
folio lock is held on a zone device folio.
b) The zone device folio has an initial mapcount > 1 which causes
at least one migration PTE entry insertion to be deferred to
try_to_migrate(), which can happen after the call to
lru_add_drain_all().
c) No or voluntary only preemption.
This all seems pretty unlikely to happen, but indeed is hit by
the "xe_exec_system_allocator" igt test.
Resolve this by waiting for the folio to be unlocked if the
folio_trylock() fails in do_swap_page().
Rename migration_entry_wait_on_locked() to
softleaf_entry_wait_unlock() and update its documentation to
indicate the new use-case.
Future code improvements might consider moving
the lru_add_drain_all() call in migrate_device_unmap() to be
called *after* all pages have migration entries inserted.
That would eliminate also b) above.
v2:
- Instead of a cond_resched() in hmm_range_fault(),
eliminate the problem by waiting for the folio to be unlocked
in do_swap_page() (Alistair Popple, Andrew Morton)
v3:
- Add a stub migration_entry_wait_on_locked() for the
!CONFIG_MIGRATION case. (Kernel Test Robot)
v4:
- Rename migrate_entry_wait_on_locked() to
softleaf_entry_wait_on_locked() and update docs (Alistair Popple)
v5:
- Add a WARN_ON_ONCE() for the !CONFIG_MIGRATION
version of softleaf_entry_wait_on_locked().
- Modify wording around function names in the commit message
(Andrew Morton)
Suggested-by: Alistair Popple <apopple@nvidia.com> Fixes: 1afaeb8293c9 ("mm/migrate: Trylock device page in do_swap_page") Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: linux-mm@kvack.org Cc: <dri-devel@lists.freedesktop.org> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.15+ Reviewed-by: John Hubbard <jhubbard@nvidia.com> #v3 Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://patch.msgid.link/20260210115653.92413-1-thomas.hellstrom@linux.intel.com
drm/gpusvm: Fix unbalanced unlock in drm_gpusvm_scan_mm()
There is a unbalanced lock/unlock to gpusvm notifier lock:
[ 931.045868] =====================================
[ 931.046509] WARNING: bad unlock balance detected!
[ 931.047149] 6.19.0-rc6+xe-**************** #9 Tainted: G U
[ 931.048150] -------------------------------------
[ 931.048790] kworker/u5:0/51 is trying to release lock (&gpusvm->notifier_lock) at:
[ 931.049801] [<ffffffffa090c0d8>] drm_gpusvm_scan_mm+0x188/0x460 [drm_gpusvm_helper]
[ 931.050802] but there are no more locks to release!
[ 931.051463]
The drm_gpusvm_notifier_unlock() sits under err_free label and the
first jump to err_free is just before calling the
drm_gpusvm_notifier_lock() causing unbalanced unlock.
Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state") Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260209123433.1271053-1-maciej.patelczyk@intel.com
Matt Roper [Thu, 5 Feb 2026 22:05:09 +0000 (14:05 -0800)]
drm/xe/xe2_hpg: Fix handling of Wa_14019988906 & Wa_14019877138
The PSS_CHICKEN register has been part of the RCS engine's LRC since it
was first introduced in Xe_LP. That means that any workarounds that
adjust its value (such as Wa_14019988906 and Wa_14019877138) need to be
implemented in the lrc_was[] table so that they become part of the
default LRC from which all subsequent LRCs are copied. Although these
workarounds were implemented correctly on most platforms, they were
incorrectly placed on the engine_was[] table for Xe2_HPG.
Move the workarounds to the proper lrc_was[] table and switch the
'xe_rtp_match_first_render_or_compute' rule to specifically match the
RCS since that's the engine whose LRC manages the register.
Gustavo Sousa [Fri, 6 Feb 2026 18:36:11 +0000 (15:36 -0300)]
drm/xe/nvlp: Bump maximum WOPCM size
On NVL-P, the primary GT's WOPCM gained an extra 8MiB for the Memory
URB. As such, we need to bump the maximum size in the driver so that
the driver is able to load without erroring out thinking that the WOPCM
is too small.
FIXME: The wopcm code in xe driver is a bit confusing. For the case
where the offsets for GUC WOPCM are already locked, it appears we are
using the maximum overall WOPCM size instead of the sizes relative to
each type of GT. The function __check_layout() should be checking
against the latter.
Aradhya Bhatia [Fri, 6 Feb 2026 18:36:07 +0000 (15:36 -0300)]
drm/xe/xe3p_lpg: Set STLB bank hash mode to 4KB
Since the dominant size of the pages referred in an i-gpu, such as
Xe3p_LPG, will be 4KB, the HW default of mix of 64K and 2M for STLB bank
hash mode does not make sense.
Allow the SW to change it to 4KB Mode, for Xe3p_LPG.
Gustavo Sousa [Fri, 6 Feb 2026 18:36:06 +0000 (15:36 -0300)]
drm/xe/xe3p_lpg: Update LRC sizes
Like with previous generations, the engine context images for of both
RCS and CCS in Xe3p_LPG contain a common layout at the end for the
context related to the "Compute Pipeline".
The size of the memory area written to such section varies; it depends
on the type of preemption has taken place during the execution and type
of command streamer instruction that was used on the pipeline. For
Xe3p_LPG, the maximum possible size, including NOOPs for cache line
alignment, is 4368 dwords, which would be the case of a mid-thread
preemption during the execution of a COMPUTE_WALKER_2 instruction.
The maximum size has increased in such a way that we need to update
xe_gt_lrc_size() to match the new sizing requirement. When we add that
to the engine-specific parts, we have:
Matt Roper [Fri, 6 Feb 2026 18:36:05 +0000 (15:36 -0300)]
drm/xe/xe3p_lpg: Extend 'group ID' mask size
Xe3p_LPG extends the 'group ID' register mask by one bit. Since the new
upper bit (12) was unused on previous platforms, we can safely extend
the existing mask size without worrying about adding conditional version
checks to the register programming.
Matt Roper [Fri, 6 Feb 2026 18:36:04 +0000 (15:36 -0300)]
drm/xe/xe3p_lpg: Drop unnecessary tuning settings
From Xe3p onward, the desired settings are now the hardware's
default values and the driver does not need to program them explicitly.
Since 35.xx seems to be the starting point for "Xe3p" version numbers;
we'll adjust the bounds of the old programming to stop at 34.99. Even
though there's no platform with version 35.00 at the moment, this is
simplest in case one does show up in the future.
Matt Roper [Fri, 6 Feb 2026 18:36:03 +0000 (15:36 -0300)]
drm/xe/xe3p_lpg: Disable reporting of context switch status to GHWSP
By default the hardware reports context switch status into the global
hardware status page. The Xe driver doesn't use this information for
anything, and as of Xe3p, leaving this setting enabled will prevent
other hardware optimizations from being enabled. Disable this reporting
as suggested by the tuning guide.
Matt Roper [Fri, 6 Feb 2026 18:36:02 +0000 (15:36 -0300)]
drm/xe/xe3p_lpg: Add LRC parsing for additional RCS engine state
Xe3p_LPG adds some additional state instructions to the RCS engine's
LRC. Add support for these to the debugfs LRC parser.
Note that the bspec's LRC description page seems to have a few mistakes
in the name/spelling of these new instructions (e.g.,
"3DSTATE_TASK_DATA_EXT" instead of "3DSTATE_TASK_SHADER_DATA_EXT" or
"3DSTATE_VIEWPORT_STATE_POINTERS_CL_SF_2" instead of
"3DSTATE_VIEWPORT_STATE_POINTERS_SF_CLIP_2").
Matt Roper [Fri, 6 Feb 2026 18:36:01 +0000 (15:36 -0300)]
drm/xe/xe3p_lpg: Add MCR steering
Xe3p_LPG has nearly identical steering to Xe2 and Xe3. The only
DSS/XeCore change from those IPs is an additional range from
0xDE00-0xDE7F that was previously reserved, so we can simply grow one of
the existing ranges in the Xe2 table to include it. Similarly, the
"instance0" table is also almost identical, but gains one additional
PSMI range and requires a separate table.
v2:
- Drop reserved range from MEMPIPE range. (Dnyaneshwar)
Gustavo Sousa [Fri, 6 Feb 2026 18:35:59 +0000 (15:35 -0300)]
drm/xe/pat: Differentiate between primary and media for PTA
Differently from currently supported platforms, in upcoming changes we
will need to have different PAT entries for PTA based on the GT type. As
such, let's prepare the code to support that by having two separate
PTA-specific members in the pat struct, one for each type of GT.
Shekhar Chauhan [Fri, 6 Feb 2026 18:35:57 +0000 (15:35 -0300)]
drm/xe/xe3p_lpg: Add support for graphics IP 35.10
Add Xe3p_LPG graphics IP version 35.10. Xe3p_LPG supports all features
described by XE2_GFX_FEATURES and also multi-queue feature on BCS and
CCS engines. As such, create a new struct xe_graphics_desc named
graphics_xe3p_lpg that inherits from XE2_GFX_FEATURES and also includes
the necessary .multi_queue_engine_class_mask.
Here is a list of fields and associated Bspec references for the members
of the IP descriptor:
v2:
- Drop non-existing fields from the list in the commit message. (Matt)
- Squash patch adding .multi_queue_engine_class_mask here. (Matt)
- Rename graphics_xe3p to graphics_xe3p_lpg. (Matt)
- Add fields .num_geometry_xecore_fuse_regs and
.num_compute_xecore_fuse_regs after rebasing and inheriting
commit 6acf3d3ed6c1 ("drm/xe: Move number of XeCore fuse registers to
graphics descriptor"). (Gustavo)
Shuicheng Lin [Fri, 30 Jan 2026 16:56:22 +0000 (16:56 +0000)]
drm/xe/mmio: Avoid double-adjust in 64-bit reads
xe_mmio_read64_2x32() was adjusting register addresses and then
calling xe_mmio_read32(), which applies the adjustment again.
This may shift accesses twice if adj_offset < adj_limit. There is
no issue currently, as for media gt, adj_offset > adj_limit, so
the 2nd adjust will be a no-op. But it may not work in future.
To fix it, replace the adjusted-address comparison with a direct
sanity check that ensures the MMIO address adjustment cutoff never
falls within the 8-byte range of a 64-bit register. And let
xe_mmio_read32() handle address translation.
v2: rewrite the sanity check in a more natural way. (Matt)
v3: Add Fixes tag. (Jani)
Fixes: 07431945d8ae ("drm/xe: Avoid 64-bit register reads") Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260130165621.471408-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
While VFs can't access MCR registers, it's still safe to initialize
our per-platform MCR tables, as we might need them later in the LRC
programming, as engines itself may access MCR steer registers and
thanks to all our past fixes to the VF probe initialization order,
VFs are able to use values of the fuse registers needed here.
projects / thirdparty / kernel / linux.git / log
