Chris Wilson <ch...@chris-wilson.co.uk> writes: > Quoting Mika Kuoppala (2018-05-16 09:39:14) >> Chris Wilson <ch...@chris-wilson.co.uk> writes: >> >> > The idea was to try and let the existing tasklet run to completion >> > before we began the reset, but it involves a racy check against anything >> > else that tries to run the tasklet. Rather than acknowledge and ignore >> > the race, let it be and don't try and be too clever. >> > >> > The tasklet will resume execution after reset (after spinning a bit >> > during reset), but before we allow it to resume we will have cleared all >> > the pending state. >> >> The disable works only on all future reschedules and >> the dequeue is behind timeline lock. But what guards against >> the tasklet being currently reading the ports? > > tasklet_disable() itself is synchronous and waits for completion of the > current execution before returning. See tasklet_disable_nosync() for the > complimentary function just to prevent future schedules from executing.
Ok, so the spinning is on the tasklet infra when it spins on scheduling, not being able to call the tasklet->func(). Reviewed-by: Mika Kuoppala <mika.kuopp...@linux.intel.com> _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
