Searched hist:"6 c7c8fb8" (Results 1 – 2 of 2) sorted by relevance
/openbmc/linux/drivers/gpu/drm/msm/ |
H A D | msm_gem.h | 6c7c8fb8 Mon Mar 20 09:43:30 CDT 2023 Rob Clark <robdclark@chromium.org> drm/msm/gem: Protect pin_count/madv by LRU lock
Since the LRU lock is already acquired when moving an obj between LRUs, we can use it to protect pin_count and madv, without any significant change in locking (ie. it just expands the scope of the lock by a hand- ful of instructions). This prepares the way to decrement the pin_count in the job_run() path without needing to hold the obj lock, to avoid a potential deadlock (or rather stall) caused by the fence-signaling path (job_run()) blocking on shrinker/reclaim. (Only a stall because the wait for fence signaling wait_for_idle() is not infinite.)
Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527843/ Link: https://lore.kernel.org/r/20230320144356.803762-9-robdclark@gmail.com
|
H A D | msm_gem.c | 6c7c8fb8 Mon Mar 20 09:43:30 CDT 2023 Rob Clark <robdclark@chromium.org> drm/msm/gem: Protect pin_count/madv by LRU lock
Since the LRU lock is already acquired when moving an obj between LRUs, we can use it to protect pin_count and madv, without any significant change in locking (ie. it just expands the scope of the lock by a hand- ful of instructions). This prepares the way to decrement the pin_count in the job_run() path without needing to hold the obj lock, to avoid a potential deadlock (or rather stall) caused by the fence-signaling path (job_run()) blocking on shrinker/reclaim. (Only a stall because the wait for fence signaling wait_for_idle() is not infinite.)
Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/527843/ Link: https://lore.kernel.org/r/20230320144356.803762-9-robdclark@gmail.com
|