kernel/linux.git/include/drm/drm_gpuvm.h, branch v7.0-rc7

drm/gpuvm: use const for drm_gpuva_op_* ptrs

2026-01-08T17:06:56+00:00

These methods just read the values stored in the op pointers without modifying them, so it is appropriate to use const ptrs here. This allows us to avoid const -> mut pointer casts in Rust. Reviewed-by: Boris Brezillon Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-3-dbd014005a0b@google.com Signed-off-by: Danilo Krummrich

drm/gpuvm: drm_gpuvm_bo_obtain() requires lock and staged mode

2026-01-08T17:05:16+00:00

In commit 9ce4aef9a5b1 ("drm/gpuvm: take GEM lock inside drm_gpuvm_bo_obtain_prealloc()") we update drm_gpuvm_bo_obtain_prealloc() to take locks internally, which means that it's only usable in immediate mode. In this commit, we notice that drm_gpuvm_bo_obtain() requires you to use staged mode. This means that we now have one variant of obtain for each mode you might use gpuvm in. To reflect this information, we add a warning about using it in immediate mode, and to make the distinction clearer we rename the method with a _locked() suffix so that it's clear that it requires the caller to take the locks. Reviewed-by: Boris Brezillon Signed-off-by: Alice Ryhl Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-2-dbd014005a0b@google.com [ Slightly reword commit message to refer to commit 9ce4aef9a5b1 ("drm/gpuvm: take GEM lock inside drm_gpuvm_bo_obtain_prealloc()"). - Danilo ] Signed-off-by: Danilo Krummrich

Merge tag 'v6.18-rc2' into 'drm-rust-next'

2025-10-20T11:49:19+00:00

When pushing commits to drm-rust-next, we need to verify that the patches pass rustfmt. Thus, pull in v6.18-rc2 for its rustfmt fix. Signed-off-by: Alice Ryhl

drm/gpuvm: add deferred vm_bo cleanup

2025-10-20T11:24:52+00:00

When using GPUVM in immediate mode, it is necessary to call drm_gpuvm_unlink() from the fence signalling critical path. However, unlink may call drm_gpuvm_bo_put(), which causes some challenges: 1. drm_gpuvm_bo_put() often requires you to take resv locks, which you can't do from the fence signalling critical path. 2. drm_gpuvm_bo_put() calls drm_gem_object_put(), which is often going to be unsafe to call from the fence signalling critical path. To solve these issues, add a deferred version of drm_gpuvm_unlink() that adds the vm_bo to a deferred cleanup list, and then clean it up later. The new methods take the GEMs GPUVA lock internally rather than letting the caller do it because it also needs to perform an operation after releasing the mutex again. This is to prevent freeing the GEM while holding the mutex (more info as comments in the patch). This means that the new methods can only be used with DRM_GPUVM_IMMEDIATE_MODE. Reviewed-by: Boris Brezillon Acked-by: Danilo Krummrich Link: https://lore.kernel.org/r/20251006-vmbo-defer-v4-1-30cbd2c05adb@google.com [aliceryhl: fix formatting of vm_bo = llist_entry(...) line] Signed-off-by: Alice Ryhl

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