kernel/linux.git/drivers/gpu/drm/xe/xe_ring_ops.c, branch linux-7.1.y

drm/xe: Move aux table invalidation to ring ops

2026-03-24T13:29:11+00:00

Implement the suggestion of moving the aux invalidation from a helper to a ring ops vfunc, together with the suggestion to split the vfunc table of video decode and video enhance engines. With this done the LRC code will be able to access the functionality via the newly added ring ops vfunc. Signed-off-by: Tvrtko Ursulin Suggested-by: Matthew Brost Cc: Rodrigo Vivi Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260324084018.20353-7-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi

drm/xe/xelp: Wait for AuxCCS invalidation to complete

2026-03-24T13:29:11+00:00

On AuxCCS platforms we need to wait for AuxCCS invalidations to complete. Signed-off-by: Tvrtko Ursulin Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260324084018.20353-6-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi

drm/xe/xelp: Quiesce memory traffic before invalidating AuxCCS

2026-03-24T13:29:11+00:00

According to i915 commit ad8ebf12217e ("drm/i915/gt: Ensure memory quiesced before invalidation") quiescing of the memory traffic is required before invalidating the AuxCCS tables. Add an extra pipe control flush to achieve that. Signed-off-by: Tvrtko Ursulin Cc: Rodrigo Vivi Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260324084018.20353-5-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi

drm/xe/xelpg: Limit AuxCCS ring buffer programming to Alderlake

2026-03-24T13:29:11+00:00

At the moment the driver does not support AuxCCS at all due respective modifiers being hidden from userspace. As we are about to start enabling them, starting with Alderlake, let us begin by limiting the ring buffer support to just that initial platform. Signed-off-by: Tvrtko Ursulin Cc: Rodrigo Vivi Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260324084018.20353-4-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi

drm/xe/vf: Improve getting clean NULL context

2026-03-23T09:38:14+00:00

There is a small risk that when fetching a NULL context image the VF may get a tweaked context image prepared by another VF that was previously running on the engine before the GuC scheduler switched the VFs. To avoid that risk, without forcing GuC scheduler to trigger costly engine reset on every VF switch, use a watchdog mechanism that when configured with impossible condition, triggers an interrupt, which GuC will handle by doing an engine reset. Also adjust job size to account for additional dwords with watchdog setup. Signed-off-by: Michal Wajdeczko Reviewed-by: Michał Winiarski Link: https://patch.msgid.link/20260303201354.17948-4-michal.wajdeczko@intel.com

drm/xe: Do not preempt fence signaling CS instructions

2026-02-26T18:04:38+00:00

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 Cc: Carlos Santa Signed-off-by: Matthew Brost Reviewed-by: Daniele Ceraolo Spurio Link: https://patch.msgid.link/20260115004546.58060-1-matthew.brost@intel.com

drm/xe: Cleanup unused header includes

2026-01-15T15:05:04+00:00

clangd reports many "unused header" warnings throughout the Xe driver. Start working to clean this up by removing unnecessary includes in our .c files and/or replacing them with explicit includes of other headers that were previously being included indirectly. By far the most common offender here was unnecessary inclusion of xe_gt.h. That likely originates from the early days of xe.ko when xe_mmio did not exist and all register accesses, including those unrelated to GTs, were done with GT functions. There's still a lot of additional #include cleanup that can be done in the headers themselves; that will come as a followup series. v2: - Squash the 79-patch series down to a single patch. (MattB) Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260115032803.4067824-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe: Avoid toggling schedule state to check LRC timestamp in TDR

2026-01-10T21:39:52+00:00

We now have proper infrastructure to accurately check the LRC timestamp without toggling the scheduling state for non-VFs. For VFs, it is still possible to get an inaccurate view if the context is on hardware. We guard against free-running contexts on VFs by banning jobs whose timestamps are not moving. In addition, VFs have a timeslice quantum that naturally triggers context switches when more than one VF is running, thus updating the LRC timestamp. For multi-queue, it is desirable to avoid scheduling toggling in the TDR because this scheduling state is shared among many queues. Furthermore, this change simplifies the GuC state machine. The trade-off for VF cases seems worthwhile. v5: - Add xe_lrc_timestamp helper (Umesh) v6: - Reduce number of tries on stuck timestamp (VF testing) - Convert job timestamp save to a memory copy (VF testing) v7: - Save ctx timestamp to LRC when start VF job (VF testing) Signed-off-by: Matthew Brost Reviewed-by: Umesh Nerlige Ramappa Link: https://patch.msgid.link/20260110012739.2888434-8-matthew.brost@intel.com

drm/xe/lnl: Drop pre-production workaround support

2025-12-13T05:17:10+00:00

LNL has been out long enough that all of our internal usage of pre-production hardware has been phased out and we no longer need to maintain workarounds that were exclusive to pre-production parts. Production LNL hardware always has B0 or later steppings for both graphics and media IP. Eliminate all workarounds that were exclusive to A-step hardware and set the 'has_prod_wa_only' device flag for LNL to make sure we warn and taint if someone tries to load the driver on an old pre-production part. Bspec: 70821 Reviewed-by: Dnyaneshwar Bhadane Link: https://patch.msgid.link/20251212181411.294854-4-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe/multi_queue: Set QUEUE_DRAIN_MODE for Multi Queue batches

2025-12-12T03:21:34+00:00

To properly support soft light restore between batches being arbitrated at the CFEG, PIPE_CONTROL instructions have a new bit in the first DW, QUEUE_DRAIN_MODE. When set, this indicates to the CFEG that it should only drain the current queue. Additionally we no longer want to set the CS_STALL bit for these multi queue queues as this causes the entire pipeline to stall waiting for completion of the prior batch, preventing this soft light restore from occurring between queues in a queue group. v4: Assert !multi_queue where applicable (Matt Roper) Bspec: 56551 Signed-off-by: Stuart Summers Signed-off-by: Niranjana Vishwanathapura Reviewed-by: Matt Roper Link: https://patch.msgid.link/20251211010249.1647839-29-niranjana.vishwanathapura@intel.com