Re: [Intel-gfx] [PATCH v3 09/11] drm/i915/tgl: Restrict Wa_1408615072 to A0 stepping

["Souza, Jose" <jose.souza@intel.com>]

On Fri, 2020-02-28 at 16:29 -0800, Matt Roper wrote:
> On Fri, Feb 28, 2020 at 04:04:17PM -0800, Souza, Jose wrote:
> > On Fri, 2020-02-28 at 13:25 -0800, Matt Roper wrote:
> > > On Thu, Feb 27, 2020 at 02:00:59PM -0800, José Roberto de Souza
> > > wrote:
> > > > It is fixed in B0 stepping.
> > > > 
> > > > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > index 22aa205793e5..a101d8072b5b 100644
> > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > @@ -6838,8 +6838,9 @@ static void tgl_init_clock_gating(struct
> > > > drm_i915_private *dev_priv)
> > > >  	unsigned int i;
> > > >  
> > > >  	/* Wa_1408615072:tgl */
> > > > -	intel_uncore_rmw(&dev_priv->uncore,
> > > > UNSLICE_UNIT_LEVEL_CLKGATE2,
> > > > -			 0, VSUNIT_CLKGATE_DIS_TGL);
> > > > +	if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0))
> > > > +		intel_uncore_rmw(&dev_priv->uncore,
> > > > UNSLICE_UNIT_LEVEL_CLKGATE2,
> > > > +				 0, VSUNIT_CLKGATE_DIS_TGL);
> > > 
> > > I think this workaround is also implemented in the wrong
> > > location.  This
> > > is a render engine register (part of the 94D0-951C render
> > > forcewake
> > > range on bspec 52078) and part of the MCR range (bspec 52079), so
> > > we
> > > should program this in the engine_wa_init rather than the clock
> > > gating
> > > function.
> > > 
> > > The ICL/EHL version (which we based the TGL WA on) is also in the
> > > wrong
> > > place for the same reasons.
> > > 
> > > At some point we should probably audit all the other
> > > GT/engine/MCR
> > > registers we're dealing with in the init_clock_gating functions
> > > and
> > > move
> > > them out to more appropriate places.
> > 
> > What about this note in BSpec 52078:
> > * Note: Some CP registers (0x9400-0x97FF) are replicated in all
> > domains, thus both render and media domains must be awake.
> 
> Well, the uncore functions will still take care of grabbing both
> forcewakes for registers like these (so that the register writes are
> applied to all the multicast register instances that live behind that
> register offset), so everything that needs to be will be powered up.
> Based on the information about the workaround, it sounds like it's
> only
> actually the render engine it really matters for though.

The WA explicity says to set 0x94E4 so other engines would need it too.

> 
> If we do this change in init_clock_gating, I don't believe it gets
> re-applied on single-engine resets, so we lose the workaround.  If we
> do
> this in the rcs engine's WA function, then those will be re-applied

For what I checked if display is not involved in the reset it would not
be applied, so a better and easier sollution would be make it be
executed when display is not involved.

CCing some GT folks.

> 
> > Otherwise we have a huge problem, doing just a quick search I found
> > this 2 registers bellow that we are programing from
> > init_clock_gating()
> > in the same range.
> > 
> > #define GEN8_UCGCTL6				_MMIO(0x9430)
> > #define GEN7_MISCCPCTL				_MMIO(0x9424)
> 
> Yeah, I suspect there are multiple workarounds we're not actually
> handling properly today (but as long as you don't suffer an engine
> hang
> & reset, you'll probably never notice).
> 
> IIRC, there's a fixme comment somewhere in the code saying we should
> move all
> the non-display stuff our of init_clock_gating to move appropriate
> locations too.
> 
> 
> 
> Matt
> 
> > > 
> > > Matt
> > > 
> > > >  
> > > >  	/* This is not a WA. Enable VD HCP & MFX_ENC powergate
> > > > */
> > > >  	for (i = 0; i < I915_MAX_VCS; i++) {
> > > > -- 
> > > > 2.25.1
> > > > 
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx