Re: [PATCH 2/6] drm/i915: Remove BXT incoherent seqno write workaround

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

 



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@xxxxxxxxxxxxxxxxxx>
> > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> > ---
> >  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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://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