kernel.git/drivers/gpu/drm/xe/xe_device.c, branch linux-6.17.y

drm/xe: Do clean shutdown also when using flr

2025-11-24T09:37:23Z

[ Upstream commit b11a020d914c3b7628f56a9ea476a5b03679489b ] Currently Xe driver is triggering flr without any clean-up on shutdown. This is causing random warnings from pending related works as the underlying hardware is reset in the middle of their execution. Fix this by performing clean shutdown also when using flr. Fixes: 501d799a47e2 ("drm/xe: Wire up device shutdown handler") Cc: Maarten Lankhorst Signed-off-by: Jouni Högander Reviewed-by: Maarten Lankhorst Link: https://patch.msgid.link/20251031122312.1836534-1-jouni.hogander@intel.com Signed-off-by: Maarten Lankhorst (cherry picked from commit a4ff26b7c8ef38e4dd34f77cbcd73576fdde6dd4) Signed-off-by: Lucas De Marchi Signed-off-by: Sasha Levin

drm/xe: Move declarations under conditional branch

2025-11-24T09:37:23Z

[ Upstream commit 9cd27eec872f0b95dcdd811edc39d2d32e4158c8 ] The xe_device_shutdown() function was needing a few declarations that were only required under a specific condition. This change moves those declarations to be within that conditional branch to avoid unnecessary declarations. Reviewed-by: Nitin Gote Link: https://patchwork.freedesktop.org/patch/msgid/20251007100208.1407021-1-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay (cherry picked from commit 15b3036045188f4da4ca62b2ed01b0f160252e9b) Signed-off-by: Lucas De Marchi Stable-dep-of: b11a020d914c ("drm/xe: Do clean shutdown also when using flr") Signed-off-by: Sasha Levin

drm/xe: Set GT as wedged before sending wedged uevent

2025-11-13T20:37:06Z

[ Upstream commit 90fdcf5f89e9288c153923f16a60e6f7da18ba76 ] Userspace should be notified after setting the device as wedged. Re-order function calls to set gt wedged before sending uevent. Cc: Matthew Brost Suggested-by: Raag Jadav Signed-off-by: Riana Tauro Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250826063419.3022216-4-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin

drm/xe: Move struct xe_vram_region to a dedicated header

2025-10-23T14:24:40Z

[ Upstream commit 7a20b4f558f4291161f71a5b7384262db9ccd6b0 ] Let's move the xe_vram_region structure to a new header dedicated to VRAM to improve modularity and avoid unnecessary dependencies when only VRAM-related structures are needed. v2: Fix build if CONFIG_DRM_XE_DEVMEM_MIRROR is enabled v3: Fix build if CONFIG_DRM_XE_DISPLAY is enabled v4: Move helper to get tile dpagemap to xe_svm.c Signed-off-by: Piotr Piórkowski Suggested-by: Jani Nikula Reviewed-by: Satyanarayana K V P # rev3 Acked-by: Matthew Brost Link: https://lore.kernel.org/r/20250714184818.89201-4-piotr.piorkowski@intel.com Signed-off-by: Lucas De Marchi Stable-dep-of: d30203739be7 ("drm/xe: Move rebar to be done earlier") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/xe: Use dynamic allocation for tile and device VRAM region structures

2025-10-23T14:24:40Z

[ Upstream commit f92cfd72d9a650f90260c54accd840c6500c4c3a ] In future platforms, we will need to represent the device and tile VRAM regions in a more dynamic way, so let's abandon the static allocation of these structures and start use a dynamic allocation. v2: - Add a helpers for accessing fields of the xe_vram_region structure v3: - Add missing EXPORT_SYMBOL_IF_KUNIT for xe_vram_region_actual_physical_size Signed-off-by: Piotr Piórkowski Cc: Stuart Summers Cc: Matthew Auld Cc: Satyanarayana K V P Reviewed-by: Satyanarayana K V P Acked-by: Matthew Brost Link: https://lore.kernel.org/r/20250714184818.89201-3-piotr.piorkowski@intel.com Signed-off-by: Lucas De Marchi Stable-dep-of: d30203739be7 ("drm/xe: Move rebar to be done earlier") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/xe: Increase global invalidation timeout to 1000us

2025-10-23T14:24:25Z

commit e5ae8d1eb08a3e27fff4ae264af4c8056d908639 upstream. The previous timeout of 500us seems to be too small; panning the map in the Roll20 VTT in Firefox on a KDE/Wayland desktop reliably triggered timeouts within a few seconds of usage, causing the monitor to freeze and the following to be printed to dmesg: [Jul30 13:44] xe 0000:03:00.0: [drm] *ERROR* GT0: Global invalidation timeout [Jul30 13:48] xe 0000:03:00.0: [drm] *ERROR* [CRTC:82:pipe A] flip_done timed out I haven't hit a single timeout since increasing it to 1000us even after several multi-hour testing sessions. Fixes: 0dd2dd0182bc ("drm/xe: Move DSB l2 flush to a more sensible place") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5710 Signed-off-by: Kenneth Graunke Cc: stable@vger.kernel.org Cc: Maarten Lankhorst Reviewed-by: Shuicheng Lin Link: https://lore.kernel.org/r/20250912223254.147940-1-kenneth@whitecape.org Signed-off-by: Lucas De Marchi (cherry picked from commit 146046907b56578263434107f5a7d5051847c459) Signed-off-by: Lucas De Marchi Signed-off-by: Greg Kroah-Hartman

drm/xe/devcoredump: Defer devcoredump initialization during probe

2025-08-04T15:58:56Z

Doing devcoredump initializing before GT though look harmless, it leads to problem during driver unbind. Because of this order, GT/Engine release functions will be called before xe devcoredump release function (xe_driver_devcoredump_fini) leading to the following kernel crash[1] because the devcoredump functions might still use GT/Engine datastructures after those are freed. The following crash is observed while running the IGT xe_wedged@wedged-at-any-timeout. The test forces a wedged state by submitting a workload which hangs. Then does a unbind/rebind of the driver to recover from the wedged state. The hanged workload leads to a devcoredump. The following crash is noticed when the devcoredump capture races with the driver unbind. During driver unbind, the release function hw_engine_fini() will be called which assigns NULL to hwe->gt. But the same data structure is accessed during the coredump capture in the function xe_engine_snapshot_print by reading snapshot->hwe->gt. With this patch, we make sure the devcoredump is stopped before deinitializing the core driver functions. [1]: BUG: kernel NULL pointer dereference, address: 0000000000000000 Workqueue: events_unbound xe_devcoredump_deferred_snap_work [xe] RIP: 0010:xe_engine_snapshot_print+0x47/0x420 [xe] Call Trace: ? drm_printf+0x64/0x90 __xe_devcoredump_read+0x23f/0x2d0 [xe] ? __pfx___drm_printfn_coredump+0x10/0x10 ? __pfx___drm_puts_coredump+0x10/0x10 xe_devcoredump_deferred_snap_work+0x17a/0x190 [xe] process_one_work+0x22e/0x6f0 worker_thread+0x1e8/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x11f/0x250 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x47/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 v2: Detailed commit description (Rodrigo) v3: FIXME added (Rodrigo, Stuart) Fixes: 4209d635a823 ("drm/xe: Remove devcoredump during driver release") Reviewed-by: Stuart Summers Link: https://lore.kernel.org/r/20250731061300.14320-1-balasubramani.vivekanandan@intel.com Signed-off-by: Balasubramani Vivekanandan Link: https://lore.kernel.org/r/20250801052356.21885-1-balasubramani.vivekanandan@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit 1fdc4c381ff765479d76ccf3134717c430c871b8) Signed-off-by: Rodrigo Vivi

drm/xe/vf: Disable CSC support on VF

2025-07-30T19:09:27Z

CSC is not accessible by VF drivers, so disable its support flag on VF to prevent further initialization attempts. Fixes: e02cea83d32d ("drm/xe/gsc: add Battlemage support") Signed-off-by: Lukasz Laguna Cc: Alexander Usyskin Cc: Michal Wajdeczko Reviewed-by: Michal Wajdeczko Signed-off-by: Michal Wajdeczko Link: https://lore.kernel.org/r/20250729123437.5933-1-lukasz.laguna@intel.com (cherry picked from commit 552dbba1caaf0cb40ce961806d757615e26ec668) Signed-off-by: Rodrigo Vivi

drm/xe: extend Wa_15015404425 to apply to PTL

2025-07-10T22:36:31Z

Wa_15015404425 only needs to be applied on PTL platforms with an A step compute die. There is no way to map PCI revid to the compute die stepping. The easiest way to figure out compute die stepping our end is to map the media IP's stepping to the compute die. For PTL, compute die has an A stepping if and only if the media IP's stepping is also A-step (This relationship is determined on a per platform basis and just happens to be this way on PTL). In addition this workaround is a chicken-and-egg problem. Wa_15015404425 requires that all register reads be preceded by four dummy MMIO writes (including during early driver init and even pre-OS firmware). The driver needs to perform some MMIO reads during init which include the GMD_ID register that contains the Media IPs stepping. To handle this in the safest manner assume the workaround applies to all of PTL during driver probe and deactivate the workaround after. The overall solution becomes a set of two workarounds: * 15015404425 - a Device OOB workaround that's always active for PTL * 15015404425_disable - a GT OOB workaround that applies to PTL platfroms with a B0 or later stepping The first of these workarounds issues dummy MMIO writes we do when reading registers. The second guards logic that disables the first once we have the necessary information later in the probe process. v2: rename SoC to device, avoid null pointer dereference, update commit message. v3: rebase v5: move disable check into xe_device_probe to avoid linking in xe_wa into xe_pci, reword commit message v6: squash extension and b0 support into 1 patch Reviewed-by: Lucas De Marchi Signed-off-by: Matt Atwood Link: https://lore.kernel.org/r/20250709221605.172516-7-matthew.s.atwood@intel.com Signed-off-by: Lucas De Marchi

drm/xe: Add infrastructure for Device OOB workarounds

2025-07-10T22:36:30Z

Some workarounds need to be able to be applied ahead of any GT initialization for example 15015404425. This patch creates XE_DEVICE_WA macro, in the same vein as XE_WA. This macro can be used ahead of GT initialization, and can be tracked in sysfs. This should alleviate some of the complexities that exist in i915. v2: name change SoC to Device, address style issues v5: split into separate patch from RTP changes, put oob within a struct, move the initiation of oob workarounds into xe_device_probe_early(), clean up the comments around XE_WA. Reviewed-by: Lucas De Marchi Signed-off-by: Matt Atwood Link: https://lore.kernel.org/r/20250709221605.172516-5-matthew.s.atwood@intel.com Signed-off-by: Lucas De Marchi