kernel/linux.git/drivers/gpu/drm/xe/xe_device.h, branch linux-7.0.y

drm/xe: Validate wedged_mode parameter and define enum for modes

2026-01-08T21:07:07+00:00

Check correctness of the wedged_mode parameter input to ensure only supported values are accepted. Additionally, replace magic numbers with a clearly defined enum. Signed-off-by: Lukasz Laguna Reviewed-by: Rodrigo Vivi Link: https://patch.msgid.link/20260107174741.29163-2-lukasz.laguna@intel.com Signed-off-by: Rodrigo Vivi

drm/xe/uapi: Extend the madvise functionality to support foreign pagemap placement for svm

2025-12-23T09:00:48+00:00

Use device file descriptors and regions to represent pagemaps on foreign or local devices. The underlying files are type-checked at madvise time, and references are kept on the drm_pagemap as long as there is are madvises pointing to it. Extend the madvise preferred_location UAPI to support the region instance to identify the foreign placement. v2: - Improve UAPI documentation. (Matt Brost) - Sanitize preferred_mem_loc.region_instance madvise. (Matt Brost) - Clarify madvise drm_pagemap vs xe_pagemap refcounting. (Matt Brost) - Don't allow a foreign drm_pagemap madvise without a fast interconnect. v3: - Add a comment about reference-counting in xe_devmem_open() and remove the reference-count get-and-put. (Matt Brost) Signed-off-by: Thomas Hellström Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20251219113320.183860-16-thomas.hellstrom@linux.intel.com

drm/xe: Add device flag to indicate standalone MERT

2025-11-25T16:45:22+00:00

The MERT subsystem manages memory accesses between host and device. On the Crescent Island platform, it requires direct management by the driver. Introduce a device flag and corresponding helpers to identify platforms with standalone MERT, enabling proper initialization and handling. Signed-off-by: Lukasz Laguna Reviewed-by: Ashutosh Dixit Signed-off-by: Michal Wajdeczko Link: https://patch.msgid.link/20251124190237.20503-2-lukasz.laguna@intel.com

drm/xe: Add a helper function to set recovery method

2025-08-26T14:11:34+00:00

Add a helper function to set recovery method. The recovery method can be set before declaring the device wedged and sending the drm wedged uevent. If no method is set, default unbind/re-bind method will be set. v2: fix documentation (Raag) Signed-off-by: Riana Tauro Reviewed-by: Raag Jadav Link: https://lore.kernel.org/r/20250826063419.3022216-5-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi

drm/xe/pf: Invalidate LMTT during LMEM unprovisioning

2025-07-15T11:05:20+00:00

Invalidate LMTT immediately after removing VF's LMTT page tables and clearing root PTE in the LMTT PD to avoid any invalid access by the hardware (and VF) due to stale data. Signed-off-by: Michal Wajdeczko Cc: Michał Winiarski Cc: Piotr Piórkowski Cc: Matthew Brost Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250711193316.1920-6-michal.wajdeczko@intel.com

drm/xe: Don't compare GT ID to GT count when determining valid GTs

2025-07-02T23:08:54+00:00

On current platforms with multiple GTs, all of the GT IDs are consecutive; as a result we know that the GT IDs range from 0 to gt_count-1 and can determine if a GT ID is valid by comparing against the count. The consecutive nature of GT IDs may not hold true on future platforms if/when we have platforms that are both multi-tile and have multiple GTs within each tile. Once such platforms exist, it's quite possible that we could wind up with something like a GT list composed of IDs 0, 2, and 3 with no GT 1 (which would be a 2-tile platform with media only on the second tile). To future-proof the code we should stop comparing against the GT count to determine whether a GT ID is valid or not. Instead we should do an actual lookup of the ID to determine whether the GT exists. This also means that our GT loop macro should not end at the GT count, but should rather examine the entire space up to (# of tiles) * (max GT per tile) to ensure it doesn't stop prematurely. Reviewed-by: Jonathan Cavitt Link: https://lore.kernel.org/r/20250701201320.2514369-15-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe: Track maximum GTs per tile on a per-platform basis

2025-07-02T23:08:54+00:00

Today all of our platforms fall into one of three cases: * Single tile platforms with a single (primary) GT * Single tile platforms with two GTs (primary + media) * Two-tile platforms with a single GT (primary) in each Our numbering of GTs has been a bit inconsistent between platforms (e.g., GT1 is the media GT on some platforms, but the second tile's primary GT on others). In the future we'll likely have platforms that are both multi-tile and multi-GT, which will make the situation more confusing. We could also wind up with more than just two types of GTs at some point in the future. Going forward we should standardize the way we assign uapi GT IDs to internal GT structures. Let's declare that for userspace GT ID n, GT[n]'s tile = n / (max gt per tile) GT[n]'s slot within tile = n % (max gt per tile) We don't want the GT numbering to change for any of our current platforms since the current IDs are part of our ABI contract with userspace so this means we should track the 'max gt per tile' value on a per-platform basis rather than just using a single value across the driver. Encode this into device descriptors in xe_pci.c and use the per-platform number for various checks in the code. Constant XE_MAX_GT_PER_TILE will remain just as the maximum across all platforms for easy of sizing array allocations. Reviewed-by: Lucas De Marchi Link: https://lore.kernel.org/r/20250701201320.2514369-12-matthew.d.roper@intel.com Signed-off-by: Matt Roper

drm/xe: Add helper function to inject fault into ct_dead_capture()

2025-06-12T23:53:56+00:00

When injecting fault to xe_guc_ct_send_recv() & xe_guc_mmio_send_recv() functions, the CI test systems are going out of space and crashing. To avoid this issue, a new helper function is created and when fault is injected into this xe_is_injection_active() helper function, ct dead capture is avoided which suppresses ct dumps in the log. Signed-off-by: Satyanarayana K V P Suggested-by: John Harrison Reviewed-by: John Harrison Cc: Michal Wajdeczko Cc: Jani Nikula Signed-off-by: John Harrison Link: https://lore.kernel.org/r/20250612080402.22011-1-satyanarayana.k.v.p@intel.com

drm/xe: Drop remove callback support

2025-02-25T22:29:06+00:00

Now that devres supports component driver cleanup during driver removal cleanup, the xe custom support for removal callbacks is not needed anymore. Drop it. Reviewed-by: Rodrigo Vivi Reviewed-by: Jonathan Cavitt Link: https://patchwork.freedesktop.org/patch/msgid/20250222001051.3012936-7-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi

drm/xe: Add callback support for driver remove

2025-02-14T19:39:29+00:00

xe device probe uses devm cleanup in most places. However there are a few cases where this is not possible: when the driver interacts with component add/del. In that case, the resource group would be cleanup while the entire device resources are in the process of cleanup. One example is the xe_gsc_proxy and display using that to interact with mei and audio. Add a callback-based remove so the exception doesn't make the probe use multiple error handling styles. v2: Change internal API to mimic the devm API. This will make it easier to migrate in future when devm can be used. Cc: Daniele Ceraolo Spurio Cc: Rodrigo Vivi Cc: Thomas Hellström Reviewed-by: Rodrigo Vivi Link: https://patchwork.freedesktop.org/patch/msgid/20250213192909.996148-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi