kernel/linux.git/drivers/gpu/drm/xe/xe_module.h, branch v6.18.22

drm/xe: Make xe_modparam.force_vram_bar_size signed

2026-02-26T22:59:44+00:00

[ Upstream commit 1acec6ef0511b92e7974cc5a8768bfd3a659feaf ] 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 Signed-off-by: Shuicheng Lin Link: https://patch.msgid.link/20260202181853.1095736-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper (cherry picked from commit 25c9aa4dcb5ef2ad9f354d19f8f1eeb690d1c161) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin

drm/xe: Strict migration policy for atomic SVM faults

2025-05-14T16:03:29+00:00

Mixing GPU and CPU atomics does not work unless a strict migration policy of GPU atomics must be device memory. Enforce a policy of must be in VRAM with a retry loop of 3 attempts, if retry loop fails abort fault. Removing always_migrate_to_vram modparam as we now have real migration policy. v2: - Only retry migration on atomics - Drop alway migrate modparam v3: - Only set vram_only on DGFX (Himal) - Bail on get_pages failure if vram_only and retry count exceeded (Himal) - s/vram_only/devmem_only - Update xe_svm_range_is_valid to accept devmem_only argument v4: - Fix logic bug get_pages failure v5: - Fix commit message (Himal) - Mention removing always_migrate_to_vram in commit message (Lucas) - Fix xe_svm_range_is_valid to check for devmem pages - Bail on devmem_only && !migrate_devmem (Thomas) v6: - Add READ_ONCE barriers for opportunistic checks (Thomas) - Pair READ_ONCE with WRITE_ONCE (Thomas) v7: - Adjust comments (Thomas) Fixes: 2f118c949160 ("drm/xe: Add SVM VRAM migration") Cc: stable@vger.kernel.org Signed-off-by: Himal Prasad Ghimiray Signed-off-by: Matthew Brost Acked-by: Himal Prasad Ghimiray Reviewed-by: Thomas Hellström Link: https://lore.kernel.org/r/20250512135500.1405019-3-matthew.brost@intel.com (cherry picked from commit a9ac0fa455b050d03e3032501368048fb284d318) Signed-off-by: Lucas De Marchi

drm/xe: Add always_migrate_to_vram modparam

2025-03-06T19:36:57+00:00

Used to show we can bounce memory multiple times which will happen once a real migration policy is implemented. Can be removed once migration policy is implemented. v3: - Pull some changes into the previous patch (Thomas) - Better commit message (Thomas) Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström Reviewed-by: Himal Prasad Ghimiray Link: https://patchwork.freedesktop.org/patch/msgid/20250306012657.3505757-32-matthew.brost@intel.com

drm/xe: Add modparam for SVM notifier size

2025-03-06T19:36:57+00:00

Useful to experiment with notifier size and how it affects performance. v3: - Pull missing changes including in following patch (Thomas) v5: - Spell out power of 2 (Thomas) Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström Reviewed-by: Himal Prasad Ghimiray Link: https://patchwork.freedesktop.org/patch/msgid/20250306012657.3505757-31-matthew.brost@intel.com

drm/xe: Rename enable_display module param

2024-08-13T20:52:20+00:00

The different approach used by xe regarding the initialization of display HW has been proved a great addition for early driver bring up: core xe can be tested without having all the bits sorted out on the display side. On the other hand, the approach exposed by i915-display is to *actively* disable the display by programming it if needed, i.e. if it was left enabled by firmware. It also has its use to make sure the HW is actually disabled and not wasting power. However having both the way it is in xe doesn't expose a good interface wrt module params. From modinfo: disable_display:Disable display (default: false) (bool) enable_display:Enable display (bool) Rename enable_display to probe_display to try to convey the message that the HW is being touched and improve the module param description. To avoid confusion, the enable_display is renamed everywhere, not only in the module param. New description for the parameters: disable_display:Disable display (default: false) (bool) probe_display:Probe display HW, otherwise it's left untouched (default: true) (bool) Reviewed-by: Matt Roper Acked-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20240813141931.3141395-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi

drm/xe: Force wedged state and block GT reset upon any GPU hang

2024-04-24T16:12:58+00:00

In many validation situations when debugging GPU Hangs, it is useful to preserve the GT situation from the moment that the timeout occurred. This patch introduces a module parameter that could be used on situations like this. If xe.wedged module parameter is set to 2, Xe will be declared wedged on every single execution timeout (a.k.a. GPU hang) right after devcoredump snapshot capture and without attempting any kind of GT reset and blocking entirely any kind of execution. v2: Really block gt_reset from guc side. (Lucas) s/wedged/busted (Lucas) v3: - s/busted/wedged - Really use global_flags (Dafna) - More robust timeout handling when wedging it. v4: A really robust clean exit done by Matt Brost. No more kernel warns on unbind. v5: Simplify error message (Lucas) Cc: Matthew Brost Cc: Dafna Hirschfeld Cc: Lucas De Marchi Cc: Alan Previn Cc: Himanshu Somaiya Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20240423221817.1285081-3-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi

drm/xe: Add max_vfs module parameter

2024-04-10T09:26:17+00:00

We want to have an option to limit the number of the VFs that the PF driver will be able to manage. With this limit set to zero we will also have a way to completely disable the PF functionality. Since we currently don't support SR-IOV on any platform, we start with this limit set to zero by default. Signed-off-by: Michal Wajdeczko Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20240404154431.583-2-michal.wajdeczko@intel.com

drm/xe/gsc: Define GSC FW for MTL

2023-12-21T16:45:06+00:00

We track GSC FW based on its compatibility version, which is what determines the interface it supports. Also add a modparam override like the ones for GuC and HuC. v2: fix module param description (John) Signed-off-by: Daniele Ceraolo Spurio Cc: Alan Previn Cc: John Harrison Reviewed-by: John Harrison Signed-off-by: Rodrigo Vivi

drm/xe: Encapsulate all the module parameters

2023-12-21T16:45:05+00:00

Encapsulate all the module parameters in one single global struct variable. This also removes the extra xe_module.h from includes. v2: naming consistency as suggested by Jani and Lucas v3: fix checkpatch errors/warnings v4: adding blank line after struct declaration Cc: Jani Nikula Cc: Lucas De Marchi Signed-off-by: Bommithi Sakeena Reviewed-by: Lucas De Marchi Signed-off-by: Rodrigo Vivi

drm/xe/uc: Add GuC/HuC firmware path overrides

2023-12-21T16:41:14+00:00

When testing a new binary and/or debugging binary-related issues, it is useful to have the option to change which binary is loaded without having to update and re-compile the kernel. To support this option, this patch adds 2 new modparams to override the FW path for GuC and HuC. The HuC modparam can also be set to an empty string to disable HuC loading. Note that those modparams only take effect on platforms where we already have a default FW, so we're sure there is support for FW loading and the kernel isn't going to explode in an undefined path. v2: simplify comment (John), rebase on s/guc_submission_enabled/uc_enabled Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Cc: Matthew Brost Reviewed-by: John Harrison Signed-off-by: Rodrigo Vivi