diff options
| author | Boris Brezillon <[email protected]> | 2021-06-30 08:27:44 +0200 |
|---|---|---|
| committer | Boris Brezillon <[email protected]> | 2021-07-01 08:53:32 +0200 |
| commit | a11c4711238ad39761cc0e04f3e8aa7b28fe1923 (patch) | |
| tree | 9760b4a65e96c103cd3974811983a3f9e3fc7fa7 /tools/perf/scripts/python | |
| parent | 070ce7657bdfaab5913908c93d57281c639cdca4 (diff) | |
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 <[email protected]>
Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Steven Price <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions