On Thu, Jan 22, 2015 at 2:13 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > This looked like an odd regression from > > commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b > Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Date: Thu Jun 12 10:28:55 2014 +0100 > > drm/i915: Restrict GPU boost to the RCS engine > > but in reality it undercovered a much older coherency bug. The issue that > boosting the GPU frequency on the BCS ring was masking was that we could > wake the CPU up after completion of a BCS batch and inspect memory prior > to the write cache being fully evicted. In order to serialise the > breadcrumb interrupt (and so ensure that the CPU's view of memory is > coherent) we need to perform a post-sync operation in the MI_FLUSH_DW. > > Testcase: gpuX-rcs-gpu-read-after-write > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: stable@xxxxxxxxxxxxxxx We also need this in gen8_emit_flush and gen6_bsd_ring_flush I think. And interesting that the subsequent seqno write can apparently be reordered with cache flushing. Or do we just need lots more of those (wasn't the magic number once 32 or so)? Anyway can't argue with hw, so Acked (with the other 2 functions updated). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html