kernel/linux.git/include/drm/drm_gem.h, branch v6.19.11

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_gem: add mutex to drm_gem_object.gpuva

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

There are two main ways that GPUVM might be used: * staged mode, where VM_BIND ioctls update the GPUVM immediately so that the GPUVM reflects the state of the VM *including* staged changes that are not yet applied to the GPU's virtual address space. * immediate mode, where the GPUVM state is updated during run_job(), i.e., in the DMA fence signalling critical path, to ensure that the GPUVM and the GPU's virtual address space has the same state at all times. Currently, only Panthor uses GPUVM in immediate mode, but the Rust drivers Tyr and Nova will also use GPUVM in immediate mode, so it is worth to support both staged and immediate mode well in GPUVM. To use immediate mode, the GEMs gpuva list must be modified during the fence signalling path, which means that it must be protected by a lock that is fence signalling safe. For this reason, a mutex is added to struct drm_gem_object that is intended to achieve this purpose. Adding it directly in the GEM object both makes it easier to use GPUVM in immediate mode, but also makes it possible to take the gpuva lock from core drm code. As a follow-up, another change that should probably be made to support immediate mode is a mechanism to postpone cleanup of vm_bo objects, as dropping a vm_bo object in the fence signalling path is problematic for two reasons: * When using DRM_GPUVM_RESV_PROTECTED, you cannot remove the vm_bo from the extobj/evicted lists during the fence signalling path. * Dropping a vm_bo could lead to the GEM object getting destroyed. The requirement that GEM object cleanup is fence signalling safe is dubious and likely to be violated in practice. Panthor already has its own custom implementation of postponing vm_bo cleanup. Reviewed-by: Boris Brezillon Signed-off-by: Alice Ryhl Link: https://lore.kernel.org/r/20250827-gpuva-mutex-in-gem-v3-1-bd89f5a82c0d@google.com Signed-off-by: Danilo Krummrich

drm/gem: Add ww_acquire_ctx support to drm_gem_lru_scan()

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

If the callback is going to have to attempt to grab more locks, it is useful to have an ww_acquire_ctx to avoid locking order problems. Why not use the drm_exec helper instead? Mainly because (a) where ww_acquire_init() is called is awkward, and (b) we don't really need to retry after backoff, we can just move on to the next object. Signed-off-by: Rob Clark Signed-off-by: Rob Clark Tested-by: Antonino Maniscalco Reviewed-by: Antonino Maniscalco Patchwork: https://patchwork.freedesktop.org/patch/661463/

drm/gem: Inline drm_gem_pin() into PRIME helpers

2025-05-30T07:47:28+00:00

Inline drm_gem_pin() into its only caller drm_gem_map_attach() and update the documentation in the callback's purpose. Do the equivalent for drm_gem_unpin(). Also add stricter error checking on the involved locking. The pin operation in the GEM object functions is a helper for PRIME-exported buffer objects. Having drm_gem_pin() gives the impression of a general-purpose interface, which is not the case. Removing it makes the pin callback a bit harder to misuse. v2: - clarify comment on pin callback (Dmitry) Signed-off-by: Thomas Zimmermann Reviewed-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20250526132634.531789-5-tzimmermann@suse.de

BackMerge tag 'v6.15-rc5' into drm-next

2025-05-06T06:39:25+00:00

Linux 6.15-rc5, requested by tzimmerman for fixes required in drm-next. Signed-off-by: Dave Airlie

drm/gem: Internally test import_attach for imported objects

2025-04-17T07:52:48+00:00

Test struct drm_gem_object.import_attach to detect imported objects. During object clenanup, the dma_buf field might be NULL. Testing it in an object's free callback then incorrectly does a cleanup as for native objects. Happens for calls to drm_mode_destroy_dumb_ioctl() that clears the dma_buf field in drm_gem_object_exported_dma_buf_free(). v3: - only test for import_attach (Boris) v2: - use import_attach.dmabuf instead of dma_buf (Christian) Signed-off-by: Thomas Zimmermann Fixes: b57aa47d39e9 ("drm/gem: Test for imported GEM buffers with helper") Reported-by: Andy Yan Closes: https://lore.kernel.org/dri-devel/38d09d34.4354.196379aa560.Coremail.andyshrk@163.com/ Tested-by: Andy Yan Cc: Thomas Zimmermann Cc: Anusha Srivatsa Cc: Christian König Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Simona Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: dri-devel@lists.freedesktop.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Reviewed-by: Boris Brezillon Reviewed-by: Simona Vetter Link: https://lore.kernel.org/r/20250416065820.26076-1-tzimmermann@suse.de

drm/gem: Document locking rule of vmap and evict callbacks

2025-03-26T20:00:06+00:00

The vmap/vunmap/evict GEM callbacks are always invoked with a held GEM's reservation lock. Document this locking rule for clarity. Reviewed-by: Boris Brezillon Reviewed-by: Christian König Acked-by: Thomas Zimmermann Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20250322212608.40511-4-dmitry.osipenko@collabora.com

drm/gem: Add _locked postfix to functions that have unlocked counterpart

2025-03-26T20:00:02+00:00

Add _locked postfix to drm_gem functions that have unlocked counterpart functions to make GEM functions naming more consistent and intuitive in regards to the locking requirements. Acked-by: Maxime Ripard Reviewed-by: Boris Brezillon Suggested-by: Boris Brezillon Reviewed-by: Christian König Acked-by: Thomas Zimmermann Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20250322212608.40511-3-dmitry.osipenko@collabora.com

drm/gem: Change locked/unlocked postfix of drm_gem_v/unmap() function names

2025-03-26T19:59:56+00:00

Make drm/gem API function names consistent by having locked function use the _locked postfix in the name, while the unlocked variants don't use the _unlocked postfix. Rename drm_gem_v/unmap() function names to make them consistent with the rest of the API functions. Acked-by: Maxime Ripard Reviewed-by: Boris Brezillon Suggested-by: Boris Brezillon Reviewed-by: Christian König Acked-by: Thomas Zimmermann Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20250322212608.40511-2-dmitry.osipenko@collabora.com

drm/gem: Test for imported GEM buffers with helper

2025-03-06T07:58:27+00:00

Add drm_gem_is_imported() that tests if a GEM object's buffer has been imported. Update the GEM code accordingly. GEM code usually tests for imports if import_attach has been set in struct drm_gem_object. But attaching a dma-buf on import requires a DMA-capable importer device, which is not the case for many serial busses like USB or I2C. The new helper tests if a GEM object's dma-buf has been created from the GEM object. Signed-off-by: Thomas Zimmermann Reviewed-by: Anusha Srivatsa Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20250226172457.217725-2-tzimmermann@suse.de