[Intel-gfx] [PATCH] drm/i915: enable WaDisableDopClkGating for gen9

[Ville Syrjälä]

On Thu, Aug 03, 2017 at 10:31:11AM -0700, Rodrigo Vivi wrote:
> On Thu, Aug 3, 2017 at 4:13 AM, David Weinehall
> <david.weinehall at linux.intel.com> wrote:
> > On Wed, Aug 02, 2017 at 12:24:33PM -0700, Rodrigo Vivi wrote:
> >> On Wed, Aug 2, 2017 at 10:34 AM, Praveen Paneri
> >> <praveen.paneri at intel.com> wrote:
> >> > This WA is required when decoupled frequencies for slice and unslice
> >> > are enabled. This disables DOP clock gating for gen9.
> >> >
> >> > v2: enable the WA for all gen9 platforms (not just for SKL GT4 where
> >> >     the hang issue is originally reported) to avoid rare hangs (David)
> >> >
> >> > Cc: David Weinehall <david.weinehall at linux.intel.com>
> >> > Reviewed-by: David Weinehall <david.weinehall at linux.intel.com>
> >> > Signed-off-by: Praveen Paneri <praveen.paneri at intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_pm.c | 6 ++++++
> >> >  1 file changed, 6 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> >> > index 3fc42aa..e369d77 100644
> >> > --- a/drivers/gpu/drm/i915/intel_pm.c
> >> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> >> > @@ -88,6 +88,12 @@ static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)
> >> >         /* WaFbcHighMemBwCorruptionAvoidance:skl,bxt,kbl,cfl */
> >> >         I915_WRITE(ILK_DPFC_CHICKEN, I915_READ(ILK_DPFC_CHICKEN) |
> >> >                    ILK_DPFC_DISABLE_DUMMY0);
> >> > +
> >> > +       if (IS_GEN9(dev_priv)) {
> >>
> >> I believe we should go with IS_SKYLAKE(dev_priv)
> >
> > Based on the info below that sounds sensible, yes. Good find.
> >
> >> Bspec only list this Wa for:
> >> BDW: ALL
> >> CHV: UNTIL A7
> >>
> >> WaDatabase only list this to:
> >> SKL: SIWA_FOREVER
> >> BDW: SIWA_FOREVER
> >> CHV: SIWA_CHV_UNTIL_A7
> >> SNB: SIWA_UNTIL_GT_MOBILE_D0
> >
> > Do we currently apply the fix on SNB?
> 
> I guess we are not...
> 
> >
> > I must say that the list of platforms seem a bit arbitrary though; it
> > seems weird that an issue on Sandybridge would disappear on Ivybridge
> > and Haswell, then resurface again on Broadwell...
> >
> > Then again, it happens far too often in software land, so it might very
> > well be that it happens in hardware land too.
> 
> I agree... that's so odd...
> 
> specially because this bit starts with GEN7...

IIRC the register and bit do exist on SNB as well. Our defines are
simply named incorrectly for whatever reason.

> let's just ignore this snb for now unless we find a good reason to
> investigate back there...
> 
> >
> >
> > Kind regards, David
> 
> 
> 
> -- 
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC