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

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

 



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@xxxxxxxxx>

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?

.Dave.
_______________________________________________
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