On Tue, Oct 25, 2016 at 10:05:23PM +0530, akash.goel@xxxxxxxxx wrote: > From: Akash Goel <akash.goel@xxxxxxxxx> > > Driver accesses the ringbuffer pages, via GMADR BAR, if the pages are > pinned in mappable aperture portion of GGTT and for ringbuffer pages > allocated from Stolen memory, access can only be done through GMADR BAR. > In case of GuC based submission, updates done in ringbuffer via GMADR > may not get committed to memory by the time the Command streamer starts > reading them, resulting in fetching of stale data. > > For Host based submission, such problem is not there as the write to Ring > Tail or ELSP register happens from the Host side prior to submission. > Access to any GFX register from CPU side goes to GTTMMADR BAR and Hw already > enforces the ordering between outstanding GMADR writes & new GTTMADR access. > MMIO writes from GuC side do not go to GTTMMADR BAR as GuC communication to > registers within GT is contained within GT, so ordering is not enforced > resulting in a race, which can manifest in form of a hang. > > To ensure the flush of in-flight GMADR writes, a POSTING READ is done to > GuC register prior to doorbell ring. > There is already a similar WA in i915_gem_object_flush_gtt_write_domain(), > which takes care of GMADR writes from User space to GEM buffers, but not the > ringbuffer writes from KMD. > This WA is needed on all recent HW. > > v2: > - Use POSTING_READ_FW instead of POSTING_READ as GuC register do not lie > in any forcewake domain range and so the overhead of spinlock & search > in the forcewake table is avoidable. (Chris) > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@xxxxxxxxx> > Signed-off-by: Akash Goel <akash.goel@xxxxxxxxx> Thanks for respinning, reviewed and pushed. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
