[Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT

[Bloomfield, Jon]

> -----Original Message-----
> From: Bloomfield, Jon
> Sent: Tuesday, May 23, 2017 7:28 AM
> To: 'Chris Wilson' <chris at chris-wilson.co.uk>
> Cc: intel-gfx at lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT
> 

> > -----Original Message-----
> > From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> > Sent: Tuesday, May 23, 2017 12:33 AM
> > To: Bloomfield, Jon <jon.bloomfield at intel.com>
> > Cc: intel-gfx at lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Serialize GTT Updates on BXT
> > It's an uncached mmio write. It is strongly ordered and serial. Besides
> > if you feel it is wrong, fix the bug at source.
> 
> Strongly ordered is not enough, nor is being uncached - that just ensures the
> PTE
> writes have left the CPU. We need to ensure they have left the GAM before
> we
> allow any following Aperture accesses to reach the GAM. On the other hand
> it
> may be that the write to the flushctl reg will explicitly cause the h/w to clear
> the
> fifo. I'll check with hw.

H/W have confirmed that the flushing write is not sufficient to avoid the bug. 
In their words [almost]:

	"You need the read.  The [FLSH_CTRL write] will invalidate the GTLB.  
	 However, it won't ensure a [Aperture] read isn't in the pipe."

So the mmio read needs to stay, and we're left with where to issue it. I placed 
it in the _cb function because it is only needed for BXT and doing it there 
avoids any (admittedly small) extra overhead for other devices. But I have 
no strong opinion on this, so if you really want it to go into the main function
I'll move it. I do think it should be conditional though.