kernel/linux.git/drivers/gpu/drm/msm/msm_gem.c, branch v6.2

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: Consolidate pin/unpin paths

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

Avoid having multiple spots where we increment/decrement pin_count (and associated LRU updating) Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/496130/ Link: https://lore.kernel.org/r/20220802155152.1727594-8-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: Rename update_inactive

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

Really what this is doing is updating various LRU lists. Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/496115/ Link: https://lore.kernel.org/r/20220802155152.1727594-6-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: Switch to pfn mappings

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

I'm not entirely sure why we were using VM_MIXEDMAP. These are never CoW mappings. Let's switch to be more consistent with what other drivers and the GEM shmem helpers do. Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/491218/ Link: https://lore.kernel.org/r/20220625225454.81039-2-robdclark@gmail.com

drm/msm: Deprecate MSM_BO_UNCACHED harder

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

Handle the demotion to MSM_BO_WC at the userspace ABI level, and fix the remaining internal MSM_BO_UNCACHED user. Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/489339/ Link: https://lore.kernel.org/r/20220613194623.2588353-1-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