[Intel-gfx] [PATCH 2/6] drm/i915: Remove BXT incoherent seqno write workaround

[Chris Wilson]

On Mon, Jan 23, 2017 at 03:43:27PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 23, 2017 at 01:05:57PM +0000, Chris Wilson wrote:
> > This w/a was only used for preproduction hw, which is no longer in use.
> > Remove the workaround to simplify the code.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> > Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_lrc.c | 17 -----------------
> >  1 file changed, 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> > index 8ffa4961aa40..202ce1e6e499 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1638,21 +1638,6 @@ static int gen8_emit_flush_render(struct drm_i915_gem_request *request,
> >  	return 0;
> >  }
> >  
> > -static void bxt_a_seqno_barrier(struct intel_engine_cs *engine)
> > -{
> > -	/*
> > -	 * On BXT A steppings there is a HW coherency issue whereby the
> > -	 * MI_STORE_DATA_IMM storing the completed request's seqno
> > -	 * occasionally doesn't invalidate the CPU cache. Work around this by
> > -	 * clflushing the corresponding cacheline whenever the caller wants
> > -	 * the coherency to be guaranteed. Note that this cacheline is known
> > -	 * to be clean at this point, since we only write it in
> > -	 * bxt_a_set_seqno(), where we also do a clflush after the write. So
> > -	 * this clflush in practice becomes an invalidate operation.
> > -	 */
> > -	intel_flush_status_page(engine, I915_GEM_HWS_INDEX);
> > -}
> 
> Ahem. Don't we have hardware in the pipeline which is going to need
> this stuff?

I sincerely hope we don't have such broken hw again. Less functional
than gen2. Anyway, restoring it, or whatever is actually required, is
trivial. Deciding whether that interrupt signaling doesn't work in
future and what we need to do instead is a whole new ballgame.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre