diff options
author | Boris Brezillon <boris.brezillon@collabora.com> | 2021-06-30 09:27:44 +0300 |
---|---|---|
committer | Boris Brezillon <boris.brezillon@collabora.com> | 2021-07-01 09:53:32 +0300 |
commit | a11c4711238ad39761cc0e04f3e8aa7b28fe1923 (patch) | |
tree | 9760b4a65e96c103cd3974811983a3f9e3fc7fa7 /fs/proc/proc_net.c | |
parent | 070ce7657bdfaab5913908c93d57281c639cdca4 (diff) | |
download | linux-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