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

drm/gem: Fix kerneldoc warnings

2025-12-18T10:08:21+00:00

Fix incorrect parameters in drm_gem_shmem_init() and missing " *" on empty lines in drm_gem_get_huge_mnt(). Signed-off-by: Loïc Molinari Fixes: 6e0b1b82017b ("drm/gem: Add huge tmpfs mountpoint helpers") Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/dri-devel/20251216115605.4babbce0@canb.auug.org.au/ Reviewed-by: Boris Brezillon Reviewed-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://patch.msgid.link/20251217172404.31216-1-loic.molinari@collabora.com Signed-off-by: Boris Brezillon

drm/gem: Fix builds with CONFIG_MMU=n

2025-12-10T13:51:26+00:00

drm_gem_get_unmapped_area() relies on mm_get_unmapped_area() which is only available if CONFIG_MMU=y. Fixes: 99bda20d6d4c ("drm/gem: Introduce drm_gem_get_unmapped_area() fop") Cc: Loïc Molinari Reviewed-by: Loïc Molinari Link: https://patch.msgid.link/20251209171151.2449120-1-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon

drm/gem: Get rid of *_with_mnt helpers

2025-12-08T09:52:48+00:00

drm_gem_object_init_with_mnt() and drm_gem_shmem_create_with_mnt() can be removed now that the drivers use the new drm_gem_huge_mnt_create() and drm_gem_get_huge_mnt() helpers. v5: - use drm_gem_has_huge_mnt() helper - compile out shmem_file_setup_with_mnt() call in builds with CONFIG_TRANSPARENT_HUGEPAGE=n v9: - replace drm_gem_has_huge_mnt() with drm_gem_get_huge_mnt() Signed-off-by: Loïc Molinari Reviewed-by: Boris Brezillon Reviewed-by: Maíra Canal Link: https://patch.msgid.link/20251205182231.194072-8-loic.molinari@collabora.com Signed-off-by: Boris Brezillon

drm/gem: Add huge tmpfs mountpoint helpers

2025-12-08T09:52:47+00:00

Add the drm_gem_huge_mnt_create() and drm_gem_get_huge_mnt() helpers to avoid code duplication in the i915, V3D, Panfrost and Panthor drivers. The former creates and mounts a dedicated huge tmpfs mountpoint, for the lifetime of a DRM device, used at GEM object initialization. The latter retrieves the dedicated huge tmpfs mountpoint used by a DRM device. The next commits will port drivers to these helpers. v3: - store huge tmpfs mountpoint in drm_device v4: - return 0 in builds with CONFIG_TRANSPARENT_HUGEPAGE=n - return 0 when huge_mnt already exists - use new vfs_parse_fs_string() helper v5: - remove warning on !dev->huge_mnt and reset to NULL on free - inline drm_gem_huge_mnt_create() to remove func from text and avoid calls in builds with CONFIG_TRANSPARENT_HUGEPAGE=n - compile out drm_device's huge_mnt field in builds with CONFIG_TRANSPARENT_HUGEPAGE=n - add drm_gem_has_huge_mnt() helper v6: - move huge_mnt doc into ifdef'd section - either inline or export drm_gem_huge_mnt_create() v7: - include in drm_gem.h v9: - replace drm_gem_has_huge_mnt() by drm_gem_get_huge_mnt() v11: - doc fixes - add Boris and Maíra R-bs Signed-off-by: Loïc Molinari Reviewed-by: Boris Brezillon Reviewed-by: Maíra Canal Link: https://patch.msgid.link/20251205182231.194072-5-loic.molinari@collabora.com Signed-off-by: Boris Brezillon

drm/gem: Introduce drm_gem_get_unmapped_area() fop

2025-12-08T09:52:47+00:00

mmap() calls on the DRM file pointer currently always end up using mm_get_unmapped_area() to get a free mapping region. On builds with CONFIG_TRANSPARENT_HUGEPAGE enabled, this isn't ideal for GEM objects backed by shmem buffers on mountpoints setting the 'huge=' option because it can't correctly figure out the potentially huge address alignment required. This commit introduces the drm_gem_get_unmapped_area() function which is meant to be used as a get_unmapped_area file operation on the DRM file pointer to lookup GEM objects based on their fake offsets and get a properly aligned region by calling shmem_get_unmapped_area() with the right file pointer. If a GEM object isn't available at the given offset or if the caller isn't granted access to it, the function falls back to mm_get_unmapped_area(). This also makes drm_gem_get_unmapped_area() part of the default GEM file operations so that all the DRM drivers can benefit from more efficient mappings thanks to the huge page fault handler introduced in previous commit 'drm/shmem-helper: Add huge page fault handler'. The shmem_get_unmapped_area() function needs to be exported so that it can be used from the DRM subsystem. v3: - include in drm_gem.c - forward to shmem layer in builds with CONFIG_TRANSPARENT_HUGEPAGE=n v6: - use GPL variant to export drm_gem_get_unmapped_area() - don't export shmem_get_unmapped_area() anymore (use f_op instead) v11: - rename drm_gem_object_lookup_from_offset() to drm_gem_object_lookup_at_offset() - add Boris R-b Signed-off-by: Loïc Molinari Reviewed-by: Boris Brezillon Link: https://patch.msgid.link/20251205182231.194072-4-loic.molinari@collabora.com Signed-off-by: Boris Brezillon

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