[Intel-gfx] [PATCH 1/2] drm/i915/bxt: work around HW coherency issue when accessing GPU seqno

[Imre Deak]

On ma, 2015-06-08 at 18:08 +0100, Dave Gordon wrote:
> On 08/06/15 17:28, Imre Deak wrote:
> > By running igt/store_dword_loop_render on BXT we can hit a coherency
> > problem where the seqno written at GPU command completion time is not
> > seen by the CPU. This results in __i915_wait_request seeing the stale
> > seqno and not completing the request (not considering the lost
> > interrupt/GPU reset mechanism). I also verified that this isn't a case
> > of a lost interrupt, or that the command didn't complete somehow: when
> > the coherency issue occured I read the seqno via an uncached GTT mapping
> > too. While the cached version of the seqno still showed the stale value
> > the one read via the uncached mapping was the correct one.
> > 
> > Work around this issue by clflushing the corresponding CPU cacheline
> > following any store of the seqno and preceding any reading of it. When
> > reading it do this only when the caller expects a coherent view.
> > 
> > Testcase: igt/store_dword_loop_render
> > Signed-off-by: Imre Deak <imre.deak at intel.com>
> 
> Not necessarily a cure for this, but BSpec says of MI_STORE_DATA_IMM
> (and MI_STORE_DATA_INDEX):
> 
> 	This command simply initiates the write operation with
> 	command execution proceeding normally. Although the write
> 	operation is guaranteed to complete "eventually", there is
> 	no mechanism to synchronize command execution with the
> 	completion (or even initiation) of these operations.
> 
> So shouldn't we use MI_FLUSH_DW or PIPE_CONTROL to update the seqno in
> the HWSP instead?

I have tried to use PIPE_CONTROL instead of MI_STORE_DATA_IMM, but that
didn't solve this issue. With the new
igt/store_dword_batches_loop/cached-mapping you can also verify that
this isn't some ordering issue. By waiting enough after the command
completed the CPU's view is still stale. Reading it after a clflush
results in the correct value on the other hand.

--Imre