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. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
