kernel/linux.git/drivers/gpu/drm/msm/msm_gem.h, branch v6.3

drm/msm/gem: Convert to lockdep assert

2022-08-28T15:31:49+00:00

Utilize the power of lockdep for our GEM locking related sanity checking. Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/496139/ Link: https://lore.kernel.org/r/20220802155152.1727594-16-robdclark@gmail.com

drm/msm/gem: Add msm_gem_assert_locked()

2022-08-27T16:32:45+00:00

All use of msm_gem_is_locked() is just for WARN_ON()s, so extract out into an msm_gem_assert_locked() patch. Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/496136/ Link: https://lore.kernel.org/r/20220802155152.1727594-15-robdclark@gmail.com

drm/msm/gem: Convert to using drm_gem_lru

2022-08-27T16:32:45+00:00

This converts over to use the shared GEM LRU/shrinker helpers. Note that it means we are no longer tracking purgeable or willneed buffers that are active separately. But the most recently pinned buffers should be at the tail of the various LRUs, and the shrinker is already prepared to encounter objects which are still active. Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/496131/ Link: https://lore.kernel.org/r/20220802155152.1727594-11-robdclark@gmail.com

drm/msm/gem: Remove active refcnt

2022-08-27T16:32:44+00:00

At this point the pinned refcnt is sufficient, and the shrinker is already prepared to encounter objects which are still active according to fences attached to the resv. Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/496122/ Link: https://lore.kernel.org/r/20220802155152.1727594-9-robdclark@gmail.com

drm/msm/gem: Rename to pin/unpin_pages

2022-08-27T16:32:44+00:00

Since that is what these fxns actually do.. they are getting *pinned* pages (as opposed to cases where we need pages, but don't need them pinned, like CPU mappings). Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/496121/ Link: https://lore.kernel.org/r/20220802155152.1727594-7-robdclark@gmail.com

drm/msm/gem: Check for active in shrinker path

2022-08-27T16:32:44+00:00

Currently in our shrinker path we shouldn't be encountering anything that is active, but this will change in subsequent patches. So check if there are unsignaled fences. Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/496117/ Link: https://lore.kernel.org/r/20220802155152.1727594-5-robdclark@gmail.com

drm/msm/gem: Drop obj lock in msm_gem_free_object()

2022-07-07T01:54:41+00:00

The only reason we grabbed the lock was to satisfy a bunch of places that WARN_ON() if called without the lock held. But this angers lockdep which doesn't realize no one else can be holding the lock by the time we end up destroying the object (and sees what would otherwise be a locking inversion between reservation_ww_class_mutex and fs_reclaim). Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/14 Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/489364/ Link: https://lore.kernel.org/r/20220613205032.2652374-1-robdclark@gmail.com

drm/msm: Make msm_gem_free_object() static

2022-07-05T03:01:07+00:00

Misc small cleanup I noticed. Not called from another object file since commit 3c9edd9c85f5 ("drm/msm: Introduce GEM object funcs") Signed-off-by: Rob Clark Reviewed-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/489362/ Link: https://lore.kernel.org/r/20220613204910.2651747-1-robdclark@gmail.com Signed-off-by: Dmitry Baryshkov

drm/msm/gem: Separate object and vma unpin

2022-06-15T20:06:54+00:00

Previously the BO_PINNED state in the submit was tracking two related but different things: (1) that the buffer object was pinned, and (2) that the vma (mapping within a set of pagetables) was pinned. But with fenced vma unpin (needed so that userspace couldn't race with retire path for releasing a vma) these two were decoupled. The fact that the BO_PINNED flag was already cleared meant that we leaked the bo pin count which should have been dropped when the submit was retired. So split this state into BO_OBJ_PINNED and BO_VMA_PINNED, so they can be dropped independently. Fixes: 95d1deb02a9c ("drm/msm/gem: Add fenced vma unpin") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/487559/ Link: https://lore.kernel.org/r/20220527172341.2151005-1-robdclark@gmail.com

drm/msm: Add a way for userspace to allocate GPU iova

2022-04-21T22:03:12+00:00

The motivation at this point is mainly native userspace mesa driver in a VM guest. The one remaining synchronous "hotpath" is buffer allocation, because guest needs to wait to know the bo's iova before it can start emitting cmdstream/state that references the new bo. By allocating the iova in the guest userspace, we no longer need to wait for a response from the host, but can just rely on the allocation request being processed before the cmdstream submission. Allocation failures (OoM, etc) would just be treated as context-lost (ie. GL_GUILTY_CONTEXT_RESET) or subsequent allocations (or readpix, etc) can raise GL_OUT_OF_MEMORY. v2: Fix inuse check v3: Change mismatched iova case to -EBUSY Signed-off-by: Rob Clark Reviewed-by: Dmitry Baryshkov Reviewed-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20220411215849.297838-11-robdclark@gmail.com Signed-off-by: Rob Clark