On Sat, May 16, 2026 at 9:46 AM Maíra Canal <[email protected]> wrote: > > The job_lock mutex guarded dev->in_flight_job across ethosu_job_run(), > the threaded IRQ handler, and ethosu_job_timedout(). However, the DRM > scheduler already provides most of the serialization required, which > makes this mutex redundant. > > Analyzing the different scenarios: > > 1. run_job() and timedout_job() are mutually exclusive scheduler > callbacks, so the scheduler itself serializes them. > > 2. run_job() and the IRQ handler are implicitly serialized, but they can > overlap in time: dma_fence_signal() synchronously queues the next > run_job onto submit_wq, and the worker can execute run_job(next) on > another CPU before the IRQ thread finishes. The mutex previously kept > the IRQ's trailing "in_flight_job = NULL" from racing run_job(next)'s > "in_flight_job = next" store. > > The handler is now restructured to clear in_flight_job before calling > dma_fence_signal(), so any run_job(next) woken by the signal observes > NULL. > > 3. timedout_job() and the IRQ handler can also overlap if the hardware > completes the timed-out job near the timeout boundary, since > drm_sched_stop()'s cancel_work_sync() only synchronizes with the > scheduler's workqueue. The IRQ handler saves in_flight_job into a > local with READ_ONCE() before dereferencing ->done_fence, and > run_job()/timedout_job() publish the field with WRITE_ONCE(). This > prevents the compiler from reloading the pointer, and keeps the IRQ > thread operating on the same job for the duration of the handler even > if timedout_job() concurrently clears the field. > > Drop the mutex along with its initialization. > > Signed-off-by: Maíra Canal <[email protected]> > --- > > Hi, > > I noticed this pattern while reviewing "[PATCH v2] accel: ethosu: Add > performance counter support" and I had the impression this could be a > nice code simplification. However, I don't have the hardware to test it, > so this was only "compile-tested".
Looks good to me and I'll give it a spin before applying. The mutex originated from the rocket driver code, so maybe the same change applies there? Though since we have a single h/w core/queue, things are a bit simpler for ethosu. Rob
