kernel/linux.git/drivers/gpu/drm/xe/xe_devcoredump.c, branch v7.1

drm/xe: replace use of system_unbound_wq with system_dfl_wq

2026-02-03T00:18:09+00:00

This patch continues the effort to refactor workqueue APIs, which has begun with the changes introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The point of the refactoring is to eventually alter the default behavior of workqueues to become unbound by default so that their workload placement is optimized by the scheduler. Before that to happen, workqueue users must be converted to the better named new workqueues with no intended behaviour changes: system_wq -> system_percpu_wq system_unbound_wq -> system_dfl_wq This way the old obsolete workqueues (system_wq, system_unbound_wq) can be removed in the future. Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260202103756.62138-2-marco.crivellari@suse.com Signed-off-by: Rodrigo Vivi

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

Merge drm/drm-next into drm-xe-next

2025-12-19T10:51:22+00:00

Backmerging to bring in 6.19-rc1. An important upstream bugfix and to help unblock PTL CI. Signed-off-by: Thomas Hellström

drm/xe/devcoredump: Use scope-based cleanup

2025-11-19T19:58:57+00:00

Use scope-based cleanup for forcewake and runtime PM in the devcoredump code. This eliminates some goto-based error handling and slightly simplifies other functions. v2: - Move the forcewake acquisition slightly higher in devcoredump_snapshot() so that we maintain an easy-to-understand LIFO cleanup order. (Gustavo) Cc: Gustavo Sousa Reviewed-by: Gustavo Sousa Link: https://patch.msgid.link/20251118164338.3572146-41-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe: Switch to use %ptSp

2025-11-19T11:26:06+00:00

Use %ptSp instead of open coded variants to print content of struct timespec64 in human readable format. Acked-by: Lucas De Marchi Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20251113150217.3030010-9-andriy.shevchenko@linux.intel.com Signed-off-by: Petr Mladek

drm/xe: Release runtime pm for error path of xe_devcoredump_read()

2025-07-08T22:11:37+00:00

xe_pm_runtime_put() is missed to be called for the error path in xe_devcoredump_read(). Add function description comments for xe_devcoredump_read() to help understand it. v2: more detail function comments and refine goto logic (Matt) Fixes: c4a2e5f865b7 ("drm/xe: Add devcoredump chunking") Cc: stable@vger.kernel.org Reviewed-by: Matthew Brost Signed-off-by: Shuicheng Lin Signed-off-by: Matthew Brost Link: https://lore.kernel.org/r/20250707004911.3502904-6-shuicheng.lin@intel.com

drm/xe: Remove unused code in devcoredump_snapshot()

2025-07-08T22:11:36+00:00

The deleted code is no longer needed because patch "drm/xe/guc: Plumb GuC-capture into dev coredump" has removed the related usage code. Remove the code to tidy up the function. v2: s/bacause/because Reviewed-by: Zhanjun Dong Reviewed-by: Matthew Brost Cc: Rodrigo Vivi Signed-off-by: Shuicheng Lin Signed-off-by: Matthew Brost Link: https://lore.kernel.org/r/20250707004911.3502904-5-shuicheng.lin@intel.com

drm/xe: fix devcoredump chunk alignmnent calculation

2025-05-01T15:48:56+00:00

The device core dumps are copied in 1.5GB chunks, which leads to a link-time error on 32-bit builds because of the 64-bit division not getting trivially turned into mask and shift operations: ERROR: modpost: "__moddi3" [drivers/gpu/drm/xe/xe.ko] undefined! On top of this, I noticed that the ALIGN_DOWN() usage here cannot work because that is only defined for power-of-two alignments. Change ALIGN_DOWN into an explicit div_u64_rem() that avoids the link error and hopefully produces the right results. Doing a 1.5GB kvmalloc() does seem a bit suspicious as well, e.g. this will clearly fail on any 32-bit platform and is also likely to run out of memory on 64-bit systems under memory pressure, so using a much smaller power-of-two chunk size might be a good idea instead. v2: - Always call div_u64_rem (Matt) Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202504251238.JsNgFeFc-lkp@intel.com/ Fixes: c4a2e5f865b7 ("drm/xe: Add devcoredump chunking") Signed-off-by: Arnd Bergmann Signed-off-by: Matthew Brost Reviewed-by: Rodrigo Vivi Link: https://lore.kernel.org/r/20250501012545.1045247-1-matthew.brost@intel.com Signed-off-by: Rodrigo Vivi

drm/xe: Add devcoredump chunking

2025-04-24T22:51:38+00:00

Chunk devcoredump into 1.5G pieces to avoid hitting the kvmalloc limit of 2G. Simple algorithm reads 1.5G at time in xe_devcoredump_read callback as needed. Some memory allocations are changed to GFP_ATOMIC as they done in xe_devcoredump_read which holds lock in the path of reclaim. The allocations are small, so in practice should never fail. v2: - Update commit message wrt gfp atomic (John H) v6: - Drop GFP_ATOMIC change for hwconfig (John H) Signed-off-by: Matthew Brost Reviewed-by: Jonathan Cavitt Link: https://lore.kernel.org/r/20250423171725.597955-2-matthew.brost@intel.com

drm/xe/devcoredump: Remove IS_ERR_OR_NULL check for kzalloc

2025-02-24T21:31:35+00:00

kzalloc returns a valid pointer or NULL if the allocation fails. It never returns an error pointer. It is better to check for NULL directly. Signed-off-by: Shuicheng Lin Cc: John Harrison Cc: Lucas De Marchi Reviewed-by: Tejas Upadhyay Reviewed-by: Jonathan Cavitt Link: https://patchwork.freedesktop.org/patch/msgid/20250220001710.1803749-3-shuicheng.lin@intel.com Signed-off-by: Lucas De Marchi