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

From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: imre.deak@intel.com, Dave Gordon <david.s.gordon@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915/bxt: work around HW coherency issue when accessing GPU seqno
Date: Wed, 10 Jun 2015 08:10:11 -0700	[thread overview]
Message-ID: <55785353.5090803@virtuousgeek.org> (raw)
In-Reply-To: <1433933973.25216.48.camel@intel.com>

On 06/10/2015 03:59 AM, Imre Deak wrote:
> I think the discussion here is about two separate things:
> 1. Possible ordering issue between the seqno store and the completion
> interrupt
> 2. Coherency issue that leaves the CPU with a stale view of the seqno
> indefinitely, which this patch works around
> 
> I'm confident that in my case the problem is not due to ordering. If it
> was "only" ordering then the value would show up eventually. This is not
> the case though, __wait_for_request will see the stale value
> indefinitely even though it gets woken up periodically afterwards by the
> lost IRQ logic (with hangcheck disabled).

Yeah, based on your workaround it sounds like the write from the CS is
landing in memory but failing to invalidate the associated CPU
cacheline.  I assume mapping the HWSP as uncached also works around this
issue?

I wonder if this is just an issue with GGTT mappings on BXT.  If we had
per context HSWPs using PPGTT (and maybe even 48 bit PPGTT) mappings,
the snoop may be performed correctly...  Looks like we don't have a
store_dword variant for explicit coherent or incoherent buffer writes
(though it does test PPGTT writes at least); that would make this easy
to test.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx