On Fri, Oct 09, 2015 at 09:45:16AM +0100, Chris Wilson wrote: > On Fri, Oct 09, 2015 at 10:38:18AM +0200, Daniel Vetter wrote: > > On Thu, Oct 08, 2015 at 07:31:39PM +0100, Tomas Elf wrote: > > > Grab execlist lock when cleaning up execlist queues after GPU reset to > > > avoid > > > concurrency problems between the context event interrupt handler and the > > > reset > > > path immediately following a GPU reset. > > > > > > Signed-off-by: Tomas Elf <tomas....@intel.com> > > > > Should we instead just stop any irqs from the GT completely while we do > > the reset (plus a synchronize_irq)? It's a bit heavy-weight, but probably > > safer. Well not the entire GT, but all the rings under reset (as prep for > > per-ring reset). > > Bah, stopping IRQs is not enough for error state capture though since > requests complete asynchronously just by polling a memory address. (If > that is the goal here, this patch just makes execlist_queue access > consistent and should only be run once the GPU has been reset and so is > categorically idle.)
This is the execlist ELSP tracking, which is execlusively driven by the CTX_SWITCH interrupt signal from each engine. At least that's been my assumption, and under that assumption I think stalling interrupts should be good enough. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
