summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/xe
AgeCommit message (Collapse)Author
19 hoursMerge branch 'driver-core-next' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git # Conflicts: # include/linux/platform_device.h
21 hoursMerge branch 'drm-xe-next' of https://gitlab.freedesktop.org/drm/xe/kernel.gitMark Brown
21 hoursMerge branch 'for-linux-next' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/i915/kernel.git
21 hoursMerge branch 'for-linux-next' of ↵Mark Brown
https://gitlab.freedesktop.org/drm/misc/kernel.git
21 hoursMerge branch 'drm-next' of https://gitlab.freedesktop.org/drm/kernel.gitMark Brown
# Conflicts: # drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h # drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
3 daysdrm/xe/pf: Handle migration descriptor using KLV helpersMichal Wajdeczko
As we plan to add more KLVs to the migration descriptor packet, to simplify such extensions and avoid coding errors, start using our KLV helpers for packet preparing and parsing. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260707220816.677-14-michal.wajdeczko@intel.com
3 daysdrm/xe/tests: Add migration packet testMichal Wajdeczko
One of our migration data packet (descriptor) is based on the KLV encoding. Add a simple descriptor initialization test, as we plan to use new KLV helper functions there. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260708180921.2715-1-michal.wajdeczko@intel.com
3 daysdrm/xe/tests: Add GuC KLV printer testMichal Wajdeczko
For completeness, add a simple test to exercise the KLV printer to make sure it doesn't crash at least. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260711073608.7829-1-michal.wajdeczko@intel.com
3 daysdrm/xe/tests: Add object encoding helper testMichal Wajdeczko
We will soon be encoding complex objects as KLVs using our helper function. Add few simple tests to make sure this helper function works as expected. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260710195945.7316-1-michal.wajdeczko@intel.com
3 daysdrm/xe/tests: Add string encoding helper testMichal Wajdeczko
Before we start using string to KLV encoding helper, add a simple test to make sure it works as expected. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> #v1 Link: https://patch.msgid.link/20260708180755.2684-1-michal.wajdeczko@intel.com
3 daysdrm/xe/tests: Add GuC KLV helpers basic testsMichal Wajdeczko
We will be making more extensive use of GuC KLV helpers. Add simple tests to ensure the helpers are working as expected. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260707220816.677-9-michal.wajdeczko@intel.com
3 daysdrm/xe/guc: Formalize Reserved KLVsMichal Wajdeczko
We have already started using few KLV keys from the 0xF000 range that, as we have agreed with the GuC team, will not be used in any GuC ABI actions. Add definitions for that reserved range and move our migration KLVs to new ABI header. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260710172534.7201-1-michal.wajdeczko@intel.com
3 daysdrm/xe/guc: Add KLV parsing helperMichal Wajdeczko
We have already introduced a helper to encode larger objects. Now add helper to parse the KLVs buffer. We will use it shortly. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260707220816.677-7-michal.wajdeczko@intel.com
3 daysdrm/xe/guc: Add object KLV encoding helperMichal Wajdeczko
We plan to encode larger objects as single KLV or set of KLVs. Add helper for that. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260707220816.677-6-michal.wajdeczko@intel.com
3 daysdrm/xe/guc: Add string KLV encoding helperMichal Wajdeczko
We also plan to encode a text data as KLV. Add helper for that too. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260707220816.677-5-michal.wajdeczko@intel.com
3 daysdrm/xe/guc: Add basic KLV encoding helpersMichal Wajdeczko
We plan to encode more data as KLVs. Add helpers for that. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260707220816.677-4-michal.wajdeczko@intel.com
3 daysdrm/xe/guc: Prepare to print group KLVsMichal Wajdeczko
Some future KLVs will be encoded as a group of nested KLVs. Prepare our KLV printer function to handle such KLVs. List of known group keys will be updated later, for now just prepare it for testing. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260707220816.677-3-michal.wajdeczko@intel.com
3 daysdrm/xe/guc: Allow to print single KLVMichal Wajdeczko
We can decode and print all KLVs from the buffer, but it might be helpful also to allow printing just single already decoded KLV. Extract existing code into new function and make it public. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patch.msgid.link/20260707220816.677-2-michal.wajdeczko@intel.com
4 daysdrm/xe: Use xe_tile_info() in alloc_primary_gt() and alloc_media_gt()Shuicheng Lin
alloc_primary_gt() and alloc_media_gt() both operate in the context of a specific tile, and the configfs-disabled messages describe a per-tile primary/media GT. Switch from xe_info(xe, ...) to xe_tile_info(tile, ...) so the log lines are prefixed with "Tile%u:", which disambiguates the message on multi-tile devices. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260708221233.3251663-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
4 daysdrm/xe/configfs: Add enable_multi_queue attributeShuicheng Lin
Add a new configfs boolean attribute 'enable_multi_queue' that lets an administrator force-disable multi-queue support on a device before it binds to the driver. The attribute defaults to true (use the platform hardware capability as-is); writing 0 force-disables multi-queue. This is intended for debugging and for validating non-multi-queue code paths on hardware that would otherwise expose multi-queue. The override disables multi-queue at two levels: - UAPI: In alloc_primary_gt(), clear gt->info.multi_queue_engine_class_mask on the primary GT so that xe_gt_supports_multi_queue() returns false and attempts to create a multi-queue group via DRM_XE_EXEC_QUEUE_SET_PROPERTY_MULTI_GROUP are rejected. - GuC: In guc_ctl_feature_flags(), set the GUC_CTL_DISABLE_MULTI_QUEUE (BIT(24)) init-params bit on GuC firmware older than 70.66. On GuC firmware 70.66 and above, guc_waklv_init() emits the new GUC_FEATURE_KLV_DISABLE_MULTI_QUEUE Feature KLV (0x5001) via the ADS WA/Feature KLV buffer instead. Feature KLVs share the WA KLV buffer. The attribute is rejected after the device has been bound, so it only takes effect during probe: # echo 0 > /sys/kernel/config/xe/0000:03:00.0/enable_multi_queue # echo 0000:03:00.0 > /sys/bus/pci/drivers/xe/bind v2: Add log for multi-queue disabled. (Niranjana) v3: Rename attribute to enable_multi_queue with default true. (Stuart && Niranjana) v4: rebase. Assisted-by: Claude:claude-opus-4.7 Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20260709200822.3257825-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
4 daysdrm/xe/i2c: use platform_device_set_fwnode()Bartosz Golaszewski
Ahead of reworking the reference counting logic for platform devices, encapsulate the assignment of the firmware node for dynamically allocated platform devices with the provided helper. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260706-pdev-fwnode-ref-v3-15-1ff028e33779@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
4 daysdrm/xe/guc: toggle paging engine support for NVL-S+Matthew Auld
NVL-S with latest GuC should be the first platform combo to support the special GUC_PAGING_CLASS feature. v2: - Update with the final GuC version v3: - Split VF vs PF versioning. Which is recommendation from GuC side. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-22-matthew.auld@intel.com
4 daysdrm/xe/hw_engine: document top-down paging requirementMatthew Auld
We were doing this anyway, but going forward for paging engines, agreement is to always reserve BCS instances in top down fashion. This hopefully future proofs things for VFs, where in some low-level places it might only have the physical BCS instance from the hw pov. If we stick to a consistent mapping scheme, it should make it possible to determine if this is a special paging engine, or not. v2 (Daniele) - Give a concrete example, like with page fault descriptor Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-21-matthew.auld@intel.com
4 daysdrm/xe/vf: wire up NUM_PAGING_ENGINE_INSTANCESMatthew Auld
When host PF writes the logical configuration for the GUC PAGING engine, the VF is meant to query it, and mirror it. Size of N means we have paging logical index range [0, N-1], with N fewer normal copy engines. Agreement is that PF will only spawn PAGING engines on NVL-S+, so this should be zero on older platforms, where we should simply fall back to the old behaviour. v2 (Sashiko): - We can't call use the guc_has_paging_engine() this early in the VF code. With that just unconditionally do the query, if the GuC is new enough and take the value as-is. With that drop the -1 special case and just let the upper layers figure out the rest. v3: - Also update xe_guc_klv_key_to_string. (Michal) - Add kernel-doc for xe_gt_sriov_vf_paging_engines(), plus other tweaks. (Michal) - Update with final GuC version. v4: - Just fallback to manual reserve when vf reported paging engines is zero. Will revisit in the future. v5 (Michal): - Convert the assert to a full abort if we ever see non-zero GuC paging engine count, on pre-nvl. - Move the VF hunk in guc_has_paging_engine() here. - Some small tweaks. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260626111520.487997-20-matthew.auld@intel.com
4 daysdrm/xe/guc: handle submit mask with paging engineMatthew Auld
We need to re-map the submit mask so that we correctly account for the logical mask of paging engines, if the GUC_PAGING_CLASS is in play. We could also have multiple instances (possible on VF), so we need to handle that also. v2 (Daniele): - Move the implementation to guc_submit.c Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-19-matthew.auld@intel.com
4 daysdrm/xe/guc: handle guc logical instance for paging engineMatthew Auld
In the GuC backend, we need a different logical instance when referring to the reserved paging engine. Under the hood, this is still just the same physical BSC engine, however from the GuC POV this is actually re-mapped to a separate GUC_PAGING_CLASS, with the logical index starting from zero. The idea is to not leak this into the upper layers, since this is GuC version specific, so the changes here are purely on the GuC side. No functional change. v2: - Add some kernel-doc to explain the usage. - Move the implementation to guc.c Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-18-matthew.auld@intel.com
4 daysdrm/xe: refactor the paging engine setupMatthew Auld
On newer platforms, the paging configuration is now configured by the PF via the ADS object, where VF side should ensure that everything configured as GUC_PAGING_CLASS is correctly mirrored on VF side. For example PF could in theory reserve two BCS instances, and we expect VF to mirror that. With that move towards having a logical mask of all the paging engines, and also generalise selecting those engines, based on the number of paging engines. Also cache the first designated paging engine, which will makes things a little cleaner here, and in later patches. No functional changes for existing platforms. v2 (Sashiko): - Rework the loop slightly so that we don't needlessly check for the paging engine, before we have correctly set the logical instance. - Add a proper error return, if we encounter a bogus paging config. Thinking ahead to VF where the config is defined by the PF, we should just gracefully exit the probe sequence. v3: - Move paging_engines > copy_engines engines check to VF patch. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patch.msgid.link/20260626111520.487997-17-matthew.auld@intel.com
4 daysdrm/xe/hw_engine: don't open code is_usm_hwe()Matthew Auld
Prefer is_usm_hwe() here. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-16-matthew.auld@intel.com
4 daysdrm/xe/guc: add the plumbing for GUC_PAGING_CLASSMatthew Auld
On newer platforms, the GuC has a new engine class which we need to use to refer to the dedicated/reserved KMD BCS engine. With that, add the plumbing in the GuC backend to support GUC_PAGING_CLASS and GUC_CAPTURE_LIST_CLASS_PAGING. Currently this is still turned off. v2 (Daniele) - Also add adjust the capture list for hpg, so we account for nvl-s. - Move single paging engine assert to a more natural place. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-15-matthew.auld@intel.com
4 daysdrm/xe/guc: refactor to_guc_class() to accept hweMatthew Auld
Rather than inferring the GuC engine class from the generic hw engine class, pass in the hwe itself, which gives the complete view, like instance etc. On future GuC versions, there is dedicated PAGING class to identify the KMD reserved BCS engine, so we need more info here in order to return the correct GuC specific engine class. With this everything should now be using the new hwe based interface. No functional changes. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-14-matthew.auld@intel.com
4 daysdrm/xe/guc: refactor ads to use guc_classMatthew Auld
Currently in the lrc init flow on the ads side, we loop through each generic engine class and convert that to the respective guc engine class. However, with some upcoming changes, it will be better to go the opposite way and loop through every guc engine class, and convert that to the generic engine class. This will be needed in an upcoming patch where we have a new guc engine class that just matches up to the existing blitter/copy class, but needs to be treated as a separate entity from the normal copy lrc, when setting up the ADS. This also reworks engine_enable_mask to operate on the guc_class, that way we can easily filter out the PAGING vs normal BSC, when applicable. As a bonus, this also gets rid of two xe_engine_class_to_guc_class() users which will be helpful for the next patch. No functional changes. v2 (Daniele): - Simplify fill_engine_enable_masks() to just loop over all guc classes. Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260626111520.487997-13-matthew.auld@intel.com
4 daysdrm/xe/guc: Define GuC firmware for NVL-SJulia Filipchuk
GuC firmware 70.71.0 (UAPI 1.37.2) is the first official GuC firmware for Novalake S. Recommend this version for NVL-S platform. Signed-off-by: Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260707192547.50535-12-julia.filipchuk@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
5 daysdrm/xe: Add support for WA 16029897822Daniele Ceraolo Spurio
The WA is implemented by the GuC, so we just need to enable it via the dedicated KLV. This WA is supported starting from GuC 70.69. Note that the GuC does not enable the relevant feature on NVL-S, so this WA can't (and shouldn't) be enabled on that platform. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com> Link: https://patch.msgid.link/20260706224344.2723462-4-daniele.ceraolospurio@intel.com
5 daysdrm/xe: Add support for WA 22022079272Daniele Ceraolo Spurio
The WA is implemented by the GuC, so we just need to enable it via the dedicated KLV. This WA is supported starting from GuC 70.62. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260706224344.2723462-3-daniele.ceraolospurio@intel.com
5 daysdrm/xe/guc: Handle GuC local uncorrectable error notificationsZhanjun Dong
Add support for the GuC uncorrectable local error G2H notification and opt in to the feature when the submission ABI exposes it. When the notification targets a known exec queue, treat it like an engine reset request and route it through the existing timeout cleanup path. This keeps the queue teardown, pending job cancellation and error capture in one place instead of open-coding a parallel recovery flow. Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260706234353.3874355-1-zhanjun.dong@intel.com
5 daysdrm/gpusvm: let the drm_gpusvm core context purely MM levelHonglei Huang
The core mechanism of drm_gpusvm is HMM, which is fundamentally an MM side subsystem. A drm_device, enters the picture on the device side at DMA mapping / GPU bind. So move struct drm_device from struct drm_gpusvm in drm_gpusvm. Let drm_gpusvm keep its core neutral and leave device side decisions to the driver. Make drm_gpusvm a pure MM level object. - Move the drm_device from struct drm_gpusvm. drm_device now stored in drm_gpusvm_pages. - Drop the drm parameter from drm_gpusvm_init() - Update the xe call sites in xe_svm_init() and other callers. drm_device does not disappear from the framework, it is relocated onto each drm_gpusvm_pages where DMA actually happens. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-6-honghuan@amd.com
5 daysdrm/xe: have xe_svm_range embed one drm_gpusvm_pagesHonglei Huang
With drm_gpusvm_pages now self contained, make xe stop relying on the drm_gpusvm_range pages and take responsibility for the page lifecycle on the driver side. Driver side (xe): - Embed struct drm_gpusvm_pages in xe_svm_range and route all xe accesses through it instead of range->base.pages. - Initialise the embedded pages via drm_gpusvm_init_pages(), which binds the owning &xe->drm up front, and take over the page lifecycle: xe_svm_range_get_pages() calls drm_gpusvm_get_pages() directly; the notifier event_end and xe_svm_range_free() paths drive unmap/free on the embedded pages object. - Convert the open-coded userptr pages init in xe_userptr_setup() to the same drm_gpusvm_init_pages() helper. - Switch xe_svm_range_pages_valid() to drm_gpusvm_pages_valid(). Framework side (drm_gpusvm): - Add a small inline drm_gpusvm_init_pages() helper that records the owning drm_device and initialises the per-pages state, giving drivers a single hook to extend. - Export drm_gpusvm_pages_valid() to let driver owned pages can query mapping state without going through a range. - Lifecycle change: drm_gpusvm_range_remove() no longer *triggers* unmap/free of the embedded pages. The unmap/free logic itself stays in the framework -- drm_gpusvm_free_pages() still performs the DMA unmap (as an idempotent backstop) and frees the dma_addr array -- but the driver now owns *when* it runs, since the driver owns the drm_gpusvm_pages object. Side effect / contract: a driver that owns a drm_gpusvm_pages is now responsible for its lifecycle: drm_gpusvm_init_pages() before first use, and drm_gpusvm_free_pages() when the owner goes away. Xe does the latter from its ops->range_free callback, which the framework invokes once the range refcount drops to zero in drm_gpusvm_range_remove(). The timely DMA unmap for the IOMMU security model still happens in the notifier invalidate path via drm_gpusvm_unmap_pages(); the unmap inside drm_gpusvm_free_pages() is only a backstop for pages that were never invalidated. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-4-honghuan@amd.com
5 daysdrm/gpusvm: embed struct drm_device into drm_gpusvm_pagesHonglei Huang
drm_gpusvm_pages is the layer that actually represents physical pages/mappings it owns the dma_addr array, the dma_iova_state... With the previous patch, so drm_gpusvm_pages is now strictly about physical pages and their DMA view. Since now the drm_gpusvm_pages instance is inherently bound to one specific drm_device, make that ownership explicit by giving drm_gpusvm_pages its own drm_device handle, and drive all DMA through it instead of through the gpusvm: - Add drm to struct drm_gpusvm_pages and route all DMA in drm_gpusvm_get_pages() / __drm_gpusvm_unmap_pages() through svm_pages->drm instead of gpusvm->drm. - Bind svm_pages->drm where the pages object is initialised (drm_gpusvm_range_alloc() and the xe userptr setup) and require it to be set on entry to drm_gpusvm_get_pages(); the dma device is immutable for the lifetime of the pages instance. A later patch introduces drm_gpusvm_init_pages() to centralise this. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-3-honghuan@amd.com
5 daysdrm/gpusvm: split MM state flags out of drm_gpusvm_pages_flagsHonglei Huang
drm_gpusvm_pages_flags currently mixes two status: - MM / virtual-address state: whether the range has been (partially) unmapped by the Linux MM, these follow the lifetime of the VMA and are a single per VA range fact. - Device mapping state: has_devmem_pages and has_dma_mapping, which describe the current page mapping status held by device itself. Keeping both on the pages object blurs the semantics of the abstraction of pages and VA range. So move the MM state flags onto the range, and keep drm_gpusvm_pages_flags strictly for mapping state. - Introduce drm_gpusvm_range_flags { migrate_devmem, unmapped, partial_unmap } on drm_gpusvm_range. - Shrink drm_gpusvm_pages_flags to just has_devmem_pages and has_dma_mapping. Side effect: drivers now need to check the unmap flags in the driver itself to avoid handling the unmapped pages. Mirror that bit onto drm_gpusvm_pages so the framework can still short circuit drm_gpusvm_get_pages() under the notifier lock, and make drm_gpusvm_range_set_unmapped() propagate it to the backing pages. This follows Matt's review fixup for the v0 series; see the Link below. Like drm_gpusvm_pages_flags, drm_gpusvm_range_flags unions its bits with a u16 __flags member. Build the new value in a local copy and publish it with a single WRITE_ONCE() on __flags, and have the lockless readers use READ_ONCE(), so concurrent bitfield access stays data-race free and KCSAN quiet. Suggested-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://gitlab.freedesktop.org/mbrost/xe-kernel-driver-svn-perf-6-15-2025/-/commit/623f6a50c037d9e44f6c9fbe6859a0ba7ad50177 Signed-off-by: Honglei Huang <honghuan@amd.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630102127.392396-2-honghuan@amd.com
5 daysdrm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=nShuicheng Lin
When CONFIG_DRM_GPUSVM=n (e.g. um-allyesconfig), the only caller of xe_pt_svm_userptr_notifier_lock() is compiled out, triggering: drivers/gpu/drm/xe/xe_pt.c:1418:13: warning: 'xe_pt_svm_userptr_notifier_lock' defined but not used [-Wunused-function] The helpers cannot simply be removed in this case: the matching xe_pt_svm_userptr_notifier_unlock() is also referenced from xe_pt_update_ops_run(), which lives outside any DRM_GPUSVM ifdef and is gated only at runtime by pt_update_ops->needs_svm_lock. The symbol must exist in all builds. Provide empty static inline stubs for !DRM_GPUSVM, matching the pattern used by xe_svm_notifier_lock()/_unlock() in xe_svm.h. Fixes: dca6e08c923a ("drm/xe/userptr: Hold notifier_lock for write on inject test path") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606302210.QqcLbOEN-lkp@intel.com/ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630192221.2998168-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> (cherry picked from commit 3359422bf0a1140e96d783a19a397686e580a3ca) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
5 daysdrm/xe: free madvise VMA array on L2 flush failureGuangshuo Li
xe_vm_madvise_ioctl() allocates madvise_range.vmas in get_vmas(). After get_vmas() succeeds with at least one VMA, error paths must go through free_vmas so the array is released before the madvise details are destroyed. The L2 flush validation path added for PAT madvise rejects some SVM/userptr ranges after get_vmas() has succeeded, but jumps directly to madv_fini. This skips kfree(madvise_range.vmas), leaking the VMA array on each failed ioctl. Jump to free_vmas instead, matching the other validation failure paths after get_vmas() has succeeded. Fixes: 4f39a194d41e ("drm/xe/xe3p_lpg: Restrict UAPI to enable L2 flush optimization") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260708073422.725186-1-lgs201920130244@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit c3a1c3579b1250060da73507a4acef712974c78a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
5 daysdrm/xe: remove duplicate <kunit/test-bug.h> includeAnas Khan
xe_pci.c includes <kunit/test-bug.h> twice, separated only by the <kunit/test.h> include. Drop the redundant second include; this is a non-functional cleanup flagged by scripts/checkincludes.pl. Fixes: 6cad22853cb8 ("drm/xe/kunit: Add stub to read_gmdid") Signed-off-by: Anas Khan <anxkhn28@gmail.com> Link: https://patch.msgid.link/20260702112820.34675-1-anxkhn28@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 84ed5b0a925721aaf069d36e18a99db966ff4e80) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
5 daysdrm/xe: Wait on external BO kernel fences in exec IOCTLMatthew Brost
Before arming a user job, xe_exec_ioctl() only added the VM's dma-resv KERNEL slot as a dependency. That slot covers rebinds and the kernel operations of the VM's private BOs, but not external BOs (bo->vm == NULL), which carry their kernel operations (evictions, moves, ...) in their own dma-resv KERNEL slot. The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for memory management operations that must complete before the BO or its backing store may be used: any accessor is required to wait on the KERNEL fences before touching the resv. By skipping the external BOs' KERNEL slots, the exec path violated that contract and could schedule a user job while a kernel operation on an external BO mapped by the VM was still in flight, racing against it and potentially reading or writing memory that was being moved. Replace the VM-only dependency with an iteration over every object locked by the exec, adding each object's KERNEL slot as a job dependency. This covers the VM resv (rebinds and private BOs) as well as every external BO, mirroring the drm_gpuvm_resv_add_fence() call that later publishes the job fence to the same set of objects. Long-running mode continues to skip this, as before. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260702215805.4011228-1-matthew.brost@intel.com (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
5 daysdrm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked bindsMatthew Brost
xe_vm_populate_pgtable() indexed the source PTE array (update->pt_entries) by the per-call loop counter, assuming each call starts at the first entry of the update. That holds for the CPU bind path (xe_migrate_update_pgtables_cpu), which populates a whole update in a single call, but not for the GPU bind path: write_pgtable() splits an update into MAX_PTE_PER_SDI (510) sized MI_STORE_DATA_IMM chunks, invoking the populate callback once per chunk with an advancing qword_ofs but a fresh command- buffer destination pointer. As a result, every chunk after the first re-read pt_entries from index 0 instead of from its true offset, so PTEs beyond the first 510 entries of a single update were programmed with the wrong physical pages, shifting the mapping by exactly MAX_PTE_PER_SDI pages. This stayed latent because a single update only exceeds 510 qwords when a large (e.g. 2M) region is bound as individual 4K PTEs rather than a single huge-page entry, which happens when the backing store is sufficiently fragmented. It was surfaced by the BO defrag path, which deliberately rebinds such fragmented ranges via the GPU bind path, producing deterministic data corruption offset by 510 pages. Index pt_entries by the chunk's absolute offset relative to update->ofs so both the CPU and GPU paths pick the correct entries. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Assisted-by: GitHub_Copilot:claude-opus-4.8 Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260702012434.3861171-1-matthew.brost@intel.com (cherry picked from commit e6f2d0b757c4fb577a513c577140109d1d292a9a) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
5 daysdrm/xe/kunit: Build DP link display testsImre Deak
Hook the shared i915 display DP link KUnit tests into the xe display test build. Build the shared display test source from the i915 display test directory when xe display support is enabled. v2: Unchanged. v3: Add SPDX license header. (Michał) Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260707124849.135319-2-imre.deak@intel.com
5 daysdrm/xe/kunit: Add display test configImre Deak
Add a separate xe KUnit config for display tests. The existing xe .kunitconfig builds xe statically, which is suitable for non-display xe tests. The display code can only be enabled for xe when xe is built as a module, so add a separate display config with DRM_XE=m and DRM_XE_DISPLAY=y. This can be folded back into the main xe KUnit config once the display code becomes a separate module. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260701153204.4124150-29-imre.deak@intel.com
5 daysdrm/xe/guc: fix activity stats error message formatSk Anirban
Use ERR_PTR() to print the error code symbolically. This makes the failure easier to spot from IGT, e.g. when the device is wedged. Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260624194618.2793571-6-sk.anirban@intel.com
5 daysdrm/xe/guc: distinguish wedged from recoverable cancellationSk Anirban
The CT layer returns -ECANCELED regardless of whether cancellation is due to a GT reset or a wedged device. Return -ENOTRECOVERABLE on wedge so callers don't need xe_device_wedged() checks to suppress spurious error logs. Also document the return codes of xe_guc_ct_send() in kernel-doc form. v2: Fix -ECANCELED description (Matt) Signed-off-by: Sk Anirban <sk.anirban@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260624194618.2793571-5-sk.anirban@intel.com
5 daysdrm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=nShuicheng Lin
When CONFIG_DRM_GPUSVM=n (e.g. um-allyesconfig), the only caller of xe_pt_svm_userptr_notifier_lock() is compiled out, triggering: drivers/gpu/drm/xe/xe_pt.c:1418:13: warning: 'xe_pt_svm_userptr_notifier_lock' defined but not used [-Wunused-function] The helpers cannot simply be removed in this case: the matching xe_pt_svm_userptr_notifier_unlock() is also referenced from xe_pt_update_ops_run(), which lives outside any DRM_GPUSVM ifdef and is gated only at runtime by pt_update_ops->needs_svm_lock. The symbol must exist in all builds. Provide empty static inline stubs for !DRM_GPUSVM, matching the pattern used by xe_svm_notifier_lock()/_unlock() in xe_svm.h. Fixes: 80ccbd97ffee ("drm/xe/userptr: Hold notifier_lock for write on inject test path") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606302210.QqcLbOEN-lkp@intel.com/ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260630192221.2998168-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
6 daysdrm/xe: free madvise VMA array on L2 flush failureGuangshuo Li
xe_vm_madvise_ioctl() allocates madvise_range.vmas in get_vmas(). After get_vmas() succeeds with at least one VMA, error paths must go through free_vmas so the array is released before the madvise details are destroyed. The L2 flush validation path added for PAT madvise rejects some SVM/userptr ranges after get_vmas() has succeeded, but jumps directly to madv_fini. This skips kfree(madvise_range.vmas), leaking the VMA array on each failed ioctl. Jump to free_vmas instead, matching the other validation failure paths after get_vmas() has succeeded. Fixes: 4f39a194d41e ("drm/xe/xe3p_lpg: Restrict UAPI to enable L2 flush optimization") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260708073422.725186-1-lgs201920130244@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-14 08:59:51 +0000