V3D exposes several independent hardware queues, but it only has a single,
global reset. Therefore, when a job times out in one queue, the timeout
handler has to stop, reset and restart the schedulers of every other queue
as well. As each scheduler queues its timeout work on the system workqueue,
those handlers run concurrently and can interfere with each other.
This can be reproduced on a Raspberry Pi 4 or 5 by running glmark2-wayland,
which keeps the CL queues busy, while a second application triggers a GPU
reset in the CSD queue every 0.5 seconds. The failure is non-deterministic,
but it usually shows up after a dozen resets: the DRM scheduler warns about
a credit imbalance in one of the CL queues,
WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102
drm_sched_run_job_work+0x238/0x4d0 [gpu_sched]
and, from that point on, the UI freezes and the machine is unusable.
The DRM scheduler already provides the synchronization that this kind of
hardware needs: an ordered workqueue passed as drm_sched_init()'s
@timeout_wq parameter, which guarantees that the timeout handlers of the
different schedulers are executed sequentially. Patch 1 gives all of the
V3D queues such a workqueue. Patch 2 removes `reset_lock`, which only
ever covered the driver's callback and is made redundant by the ordered
workqueue.
Only patch 1 is Cc'ed to stable, in order to keep the backport minimal.
Best regards,
- Maíra
---
Maíra Canal (2):
drm/v3d: Serialize the scheduler timeout handlers
drm/v3d: Remove the now-redundant reset lock
drivers/gpu/drm/v3d/v3d_drv.h | 8 ++++----
drivers/gpu/drm/v3d/v3d_gem.c | 3 ---
drivers/gpu/drm/v3d/v3d_sched.c | 13 ++++++++-----
3 files changed, 12 insertions(+), 12 deletions(-)
---
base-commit: 48a570c964d8e37d353381e4195106277e17f5cb
change-id: 20260728-v3d-order-global-reset-7736b445e0b8
