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

drm/drm_file: Add DRM obj's RSS reporting function for fdinfo

2023-10-04T11:04:15+00:00

Some BO's might be mapped onto physical memory chunkwise and on demand, like Panfrost's tiler heap. In this case, even though the drm_gem_shmem_object page array might already be allocated, only a very small fraction of the BO is currently backed by system memory, but drm_show_memory_stats will then proceed to add its entire virtual size to the file's total resident size regardless. This led to very unrealistic RSS sizes being reckoned for Panfrost, where said tiler heap buffer is initially allocated with a virtual size of 128 MiB, but only a small part of it will eventually be backed by system memory after successive GPU page faults. Provide a new DRM object generic function that would allow drivers to return a more accurate RSS and purgeable sizes for their BOs. Signed-off-by: Adrián Larumbe Reviewed-by: Boris Brezillon Reviewed-by: Steven Price Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Rob Clark Signed-off-by: Boris Brezillon Link: https://patchwork.freedesktop.org/patch/msgid/20230929181616.2769345-5-adrian.larumbe@collabora.com

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

drm/gem: Add evict() callback to drm_gem_object_funcs

2023-02-27T04:09:41+00:00

Add new common evict() callback to drm_gem_object_funcs and corresponding drm_gem_object_evict() helper. This is a first step on a way to providing common GEM-shrinker API for DRM drivers. Reviewed-by: Thomas Zimmermann Suggested-by: Thomas Zimmermann Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/all/20230108210445.3948344-4-dmitry.osipenko@collabora.com/

drm/msm/gem: Prevent blocking within shrinker loop

2023-02-27T04:06:56+00:00

Consider this scenario: 1. APP1 continuously creates lots of small GEMs 2. APP2 triggers `drop_caches` 3. Shrinker starts to evict APP1 GEMs, while APP1 produces new purgeable GEMs 4. msm_gem_shrinker_scan() returns non-zero number of freed pages and causes shrinker to try shrink more 5. msm_gem_shrinker_scan() returns non-zero number of freed pages again, goto 4 6. The APP2 is blocked in `drop_caches` until APP1 stops producing purgeable GEMs To prevent this blocking scenario, check number of remaining pages that GPU shrinker couldn't release due to a GEM locking contention or shrinking rejection. If there are no remaining pages left to shrink, then there is no need to free up more pages and shrinker may break out from the loop. This problem was found during shrinker/madvise IOCTL testing of virtio-gpu driver. The MSM driver is affected in the same way. Reviewed-by: Rob Clark Reviewed-by: Thomas Zimmermann Fixes: b352ba54a820 ("drm/msm/gem: Convert to using drm_gem_lru") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/all/20230108210445.3948344-2-dmitry.osipenko@collabora.com/