Re: [PATCH 7/8] drm/i915: Grab execlist spinlock to avoid post-reset concurrency issues.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.elf@xxxxxxxxx>
> > 
> > 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux