kernel/linux.git/include/drm/drm_gpuvm.h, branch v6.18.21

drm/gpuvm: Fix kernel-doc warning for drm_gpuvm_map_req.map

2025-10-15T16:37:05+00:00

The kernel-doc for struct drm_gpuvm_map_req.map was added as '@op_map' instead of '@map', leading to this warning during htmldocs build: WARNING: include/drm/drm_gpuvm.h:1083 struct member 'map' not described in 'drm_gpuvm_map_req' Fixes: 000a45dce7ad ("drm/gpuvm: Pass map arguments through a struct") Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/all/20250821133539.03aa298e@canb.auug.org.au/ Signed-off-by: Ankan Biswas Signed-off-by: Danilo Krummrich

Merge tag 'v6.17-rc6' into drm-next

2025-09-15T07:51:07+00:00

This is a backmerge of Linux 6.17-rc6, needed for msm, also requested by misc. Signed-off-by: Dave Airlie

gpuvm: remove gem.gpuva.lock_dep_map

2025-08-28T10:40:43+00:00

Since all users of gem.gpuva.lock_dep_map now rely on the mutex directly in gpuva, we may remove it. Whether the mutex is used is now tracked by a flag in gpuvm rather than by whether lock_dep_map is null. Note that a GEM object may not be pushed to multiple gpuvms that disagree on the value of this new flag. But that's okay because a single driver should use the same locking scheme everywhere, and a GEM object is driver specific (when a GEM is exported with prime, a new GEM object instance is created from the backing dma-buf). The flag is present even with CONFIG_LOCKDEP=n because the intent is that the flag will also cause vm_bo cleanup to become deferred. However, that will happen in a follow-up patch. Reviewed-by: Boris Brezillon Signed-off-by: Alice Ryhl Link: https://lore.kernel.org/r/20250827-gpuva-mutex-in-gem-v3-3-bd89f5a82c0d@google.com [ Use lockdep_is_held() instead of lock_is_held(). - Danilo ] Signed-off-by: Danilo Krummrich

drm/gpuvm: fix various typos in .c and .h gpuvm file

2025-08-25T19:48:50+00:00

After working with this code for a while, I came across several typos. This patch fixes them. Signed-off-by: Alice Ryhl Link: https://lore.kernel.org/r/20250825-gpuvm-typo-fix-v1-1-14e9e78e28e6@google.com Signed-off-by: Danilo Krummrich

drm/gpuvm: Introduce drm_gpuvm_madvise_ops_create

2025-08-20T04:19:35+00:00

This ops is used to iterate over GPUVA's in the user-provided range and split the existing sparse VMA's if the start or end of the input range lies within it. The operations can create up to 2 REMAPS and 2 MAPs. The primary use case is for drivers to assign attributes to GPU VAs in the specified range without performing unmaps or merging mappings, supporting fine-grained control over sparse va's. Cc: Danilo Krummrich Cc: Matthew Brost Cc: Boris Brezillon Cc: Signed-off-by: Himal Prasad Ghimiray Reviewed-by: Matthew Brost Acked-by: Danilo Krummrich Signed-off-by: Matthew Brost Link: https://lore.kernel.org/r/20250819162058.2777306-4-himal.prasad.ghimiray@intel.com

drm/gpuvm: Kill drm_gpuva_init()

2025-08-20T04:19:33+00:00

drm_gpuva_init() only has one internal user, and given we are about to add new optional fields, it only add maintenance burden for no real benefit, so let's kill the thing now. Cc: Danilo Krummrich Cc: Rob Clark Signed-off-by: Boris Brezillon Acked-by: Danilo Krummrich Reviewed-by: Matthew Brost Signed-off-by: Himal Prasad Ghimiray Reviewed-by: Rob Clark Signed-off-by: Matthew Brost Link: https://lore.kernel.org/r/20250819162058.2777306-3-himal.prasad.ghimiray@intel.com

drm/gpuvm: Pass map arguments through a struct

2025-08-20T04:19:31+00:00

We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](), so, before we do that, let's pass arguments through a struct instead of changing each call site every time a new optional argument is added. Cc: Danilo Krummrich Cc: Brendan King Cc: Matt Coster Cc: Boris Brezillon Cc: Caterina Shablia Cc: Rob Clark Cc: Matthew Brost Cc: Co-developed-by: Himal Prasad Ghimiray Signed-off-by: Himal Prasad Ghimiray Signed-off-by: Boris Brezillon Acked-by: Danilo Krummrich Reviewed-by: Matthew Brost Reviewed-by: Rob Clark Reviewed-by: Matt Coster # imagination/pvr_vm.c Acked-by: Matt Coster Signed-off-by: Matthew Brost Link: https://lore.kernel.org/r/20250819162058.2777306-2-himal.prasad.ghimiray@intel.com

drm/gpuvm: Add locking helpers

2025-07-04T18:09:43+00:00

For UNMAP/REMAP steps we could be needing to lock objects that are not explicitly listed in the VM_BIND ioctl in order to tear-down unmapped VAs. These helpers handle locking/preparing the needed objects. Note that these functions do not strictly require the VM changes to be applied before the next drm_gpuvm_sm_map_lock()/_unmap_lock() call. In the case that VM changes from an earlier drm_gpuvm_sm_map()/_unmap() call result in a differing sequence of steps when the VM changes are actually applied, it will be the same set of GEM objects involved, so the locking is still correct. v2: Rename to drm_gpuvm_sm_*_exec_locked() [Danilo] v3: Expand comments to show expected usage, and explain how the usage is safe in the case of overlapping driver VM_BIND ops. Signed-off-by: Rob Clark Tested-by: Antonino Maniscalco Reviewed-by: Antonino Maniscalco Acked-by: Danilo Krummrich Patchwork: https://patchwork.freedesktop.org/patch/661458/

drm/gpuvm: Add DRM_GPUVA_OP_DRIVER

2025-03-06T19:35:42+00:00

Add DRM_GPUVA_OP_DRIVER which allows driver to define their own gpuvm ops. Useful for driver created ops which can be passed into the bind software pipeline. v3: - s/DRM_GPUVA_OP_USER/DRM_GPUVA_OP_DRIVER (Thomas) - Better commit message (Thomas) Cc: Danilo Krummrich Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström Link: https://patchwork.freedesktop.org/patch/msgid/20250306012657.3505757-14-matthew.brost@intel.com

Merge drm/drm-next into drm-misc-next

2024-01-29T13:20:23+00:00

Kickstart 6.9 development cycle. Signed-off-by: Maxime Ripard