summaryrefslogtreecommitdiff
path: root/drivers/watchdog/orion_wdt.c
diff options
context:
space:
mode:
authorBoris Brezillon <boris.brezillon@collabora.com>2020-10-02 15:25:06 +0300
committerSteven Price <steven.price@arm.com>2020-10-08 12:52:02 +0300
commit1a11a88cfd9a97e13be8bc880c4795f9844fbbec (patch)
treee8eef6e0315e32a038a478d7c8bb2d3c53966bbb /drivers/watchdog/orion_wdt.c
parent9073d4ed8da47ce53f5447a18ff39cd64d4aee71 (diff)
downloadlinux-1a11a88cfd9a97e13be8bc880c4795f9844fbbec.tar.xz
drm/panfrost: Fix job timeout handling
If more than two jobs end up timeout-ing concurrently, only one of them (the one attached to the scheduler acquiring the lock) is fully handled. The other one remains in a dangling state where it's no longer part of the scheduling queue, but still blocks something in scheduler, leading to repetitive timeouts when new jobs are queued. Let's make sure all bad jobs are properly handled by the thread acquiring the lock. v3: - Add Steven's R-b - Don't take the sched_lock when stopping the schedulers v2: - Fix the subject prefix - Stop the scheduler before returning from panfrost_job_timedout() - Call cancel_delayed_work_sync() after drm_sched_stop() to make sure no timeout handlers are in flight when we reset the GPU (Steven Price) - Make sure we release the reset lock before restarting the schedulers (Steven Price) Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201002122506.1374183-1-boris.brezillon@collabora.com
Diffstat (limited to 'drivers/watchdog/orion_wdt.c')
0 files changed, 0 insertions, 0 deletions