Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > Quoting Mika Kuoppala (2018-05-16 09:39:14) >> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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.kuoppala@xxxxxxxxxxxxxxx> _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
