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

drm/gem: Internally test import_attach for imported objects

2025-06-04T12:42:21+00:00

commit 8260731ccad0451207b45844bb66eb161a209218 upstream. 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 Signed-off-by: Greg Kroah-Hartman

drm/gem: Test for imported GEM buffers with helper

2025-06-04T12:42:02+00:00

[ Upstream commit b57aa47d39e94dc47403a745e2024664e544078c ] 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 Signed-off-by: Sasha Levin

drm: add drm_gem_object_is_shared_for_memory_stats() helper

2024-05-02T14:32:41+00:00

[ Upstream commit b31f5eba32ae8cc28e7cfa5a55ec8670d8c718e2 ] Add a helper so that drm drivers can consistently report shared status via the fdinfo shared memory stats interface. In addition to handle count, show buffers as shared if they are shared via dma-buf as well (e.g., shared with v4l or some other subsystem). v2: switch to inline function Link: https://lore.kernel.org/all/20231207180225.439482-1-alexander.deucher@amd.com/ Reviewed-by: Tvrtko Ursulin (v1) Signed-off-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Christian König Stable-dep-of: a6ff969fe9cb ("drm/amdgpu: fix visible VRAM handling during faults") Signed-off-by: Sasha Levin

drm/gem: fix lockdep check for dma-resv lock

2023-08-04T18:34:31+00:00

When no custom lock is set to protect a GEMs GPUVA list, lockdep checks should fall back to the GEM objects dma-resv lock. With the current implementation we're setting the lock_dep_map of the GEM objects 'resv' pointer (in case no custom lock_dep_map is set yet) on drm_gem_private_object_init(). However, the GEM objects 'resv' pointer might still change after drm_gem_private_object_init() is called, e.g. through ttm_bo_init_reserved(). This can result in the wrong lock being tracked. To fix this, call dma_resv_held() directly from drm_gem_gpuva_assert_lock_held() and fall back to the GEMs lock_dep_map pointer only if an actual custom lock is set. Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings") Reviewed-by: Dave Airlie Signed-off-by: Danilo Krummrich Link: https://patchwork.freedesktop.org/patch/msgid/20230804182406.5222-2-dakr@redhat.com

drm: manager to keep track of GPUs VA mappings

2023-07-20T03:15:53+00:00

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1) Provide infrastructure to track GPU VA allocations and mappings, using an interval tree (RB-tree). 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. Acked-by: Thomas Hellström Acked-by: Matthew Brost Reviewed-by: Boris Brezillon Tested-by: Matthew Brost Tested-by: Donald Robson Suggested-by: Dave Airlie Signed-off-by: Danilo Krummrich Link: https://patchwork.freedesktop.org/patch/msgid/20230720001443.2380-2-dakr@redhat.com

drm: Add fdinfo memory stats

2023-05-24T16:03:30+00:00

Add support to dump GEM stats to fdinfo. v2: Fix typos, change size units to match docs, use div_u64 v3: Do it in core v4: more kerneldoc v5: doc fixes v6: Actually use u64, bit more comment docs Signed-off-by: Rob Clark Reviewed-by: Emil Velikov Reviewed-by: Daniel Vetter Acked-by: Tvrtko Ursulin Acked-by: Dave Airlie Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20230524155956.382440-6-robdclark@gmail.com

Merge tag 'drm-msm-next-2023-04-10' of https://gitlab.freedesktop.org/drm/msm into drm-next

2023-04-11T10:21:50+00:00

main pull request for v6.4 Core Display: ============ * Bugfixes for error handling during probe * rework UBWC decoder programming * prepare_commit cleanup * bindings for SM8550 (MDSS, DPU), SM8450 (DP) * timeout calculation fixup * atomic: use drm_crtc_next_vblank_start() instead of our own custom thing to calculate the start of next vblank DP: == * interrupts cleanup DPU: === * DSPP sub-block flush on sc7280 * support AR30 in addition to XR30 format * Allow using REC_0 and REC_1 to handle wide (4k) RGB planes * Split the HW catalog into individual per-SoC files DSI: === * rework DSI instance ID detection on obscure platforms GPU: === * uapi C++ compatibility fix * a6xx: More robust gdsc reset * a3xx and a4xx devfreq support * update generated headers * various cleanups and fixes * GPU and GEM updates to avoid allocations which could trigger reclaim (shrinker) in fence signaling path * dma-fence deadline hint support and wait-boost * a640 speedbin support * a650 speedbin support Conflicts in drivers/gpu/drm/msm/adreno/adreno_gpu.c: Conflict between the 7fa5047a436b ("drm: Use of_property_present() for testing DT property presence") and 9f251f934012 ("drm/msm/adreno: Use OPP for every GPU generation"). The latter removed the of_ function call outright, so I went with what's in the PR unchanged. From: Rob Clark Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvwuj5tabyW910+N-B=5kFNAC7QNYoQ=0xi3roBjQvFFQ@mail.gmail.com Signed-off-by: Daniel Vetter

Merge v6.3-rc4 into drm-next

2023-03-29T14:00:23+00:00

I just landed the fence deadline PR from Rob that a bunch of drivers want/need to apply driver-specific patches. Backmerge -rc4 so that they don't have to be stuck on -rc2 for no reason at all. Signed-off-by: Daniel Vetter

drm/gem: Export drm_gem_lru_move_tail_locked()

2023-03-25T23:31:44+00:00

Export the locked version or lru's move_tail(). Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/527835/ Link: https://lore.kernel.org/r/20230320144356.803762-7-robdclark@gmail.com

Merge drm/drm-fixes into drm-misc-fixes

2023-03-13T09:14:05+00:00

Backmerging to get latest upstream. Signed-off-by: Thomas Zimmermann