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? -Mika > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > --- > drivers/gpu/drm/i915/i915_gem.c | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 0a2070112b66..0dc369a9ec4d 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3035,16 +3035,7 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs *engine) > * calling engine->init_hw() and also writing the ELSP. > * Turning off the execlists->tasklet until the reset is over > * prevents the race. > - * > - * Note that this needs to be a single atomic operation on the > - * tasklet (flush existing tasks, prevent new tasks) to prevent > - * a race between reset and set-wedged. It is not, so we do the best > - * we can atm and make sure we don't lock the machine up in the more > - * common case of recursively being called from set-wedged from inside > - * i915_reset. > */ > - if (!atomic_read(&engine->execlists.tasklet.count)) > - tasklet_kill(&engine->execlists.tasklet); > tasklet_disable(&engine->execlists.tasklet); > > /* > -- > 2.17.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
