summaryrefslogtreecommitdiff
path: root/fs/proc/proc_net.c
diff options
context:
space:
mode:
authorBoris Brezillon <boris.brezillon@collabora.com>2021-06-30 09:27:44 +0300
committerBoris Brezillon <boris.brezillon@collabora.com>2021-07-01 09:53:32 +0300
commita11c4711238ad39761cc0e04f3e8aa7b28fe1923 (patch)
tree9760b4a65e96c103cd3974811983a3f9e3fc7fa7 /fs/proc/proc_net.c
parent070ce7657bdfaab5913908c93d57281c639cdca4 (diff)
downloadlinux-a11c4711238ad39761cc0e04f3e8aa7b28fe1923.tar.xz
drm/panfrost: Simplify the reset serialization logic
Now that we can pass our own workqueue to drm_sched_init(), we can use an ordered workqueue on for both the scheduler timeout tdr and our own reset work (which we use when the reset is not caused by a fault/timeout on a specific job, like when we have AS_ACTIVE bit stuck). This guarantees that the timeout handlers and reset handler can't run concurrently which drastically simplifies the locking. v5: * Don't call cancel_delayed_timeout() in the reset path (those works are canceled in drm_sched_stop()) v4: * Actually pass the reset workqueue to drm_sched_init() * Don't call cancel_work_sync() in panfrost_reset(). It will deadlock since it might be called from the reset work, which is executing and cancel_work_sync() will wait for the handler to return. Checking the reset pending status should avoid spurious resets v3: * New patch Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210630062751.2832545-10-boris.brezillon@collabora.com
Diffstat (limited to 'fs/proc/proc_net.c')
0 files changed, 0 insertions, 0 deletions