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

Rodrigo Vivi rodrigo.vivi at gmail.com
Thu Aug 3 17:31:11 UTC 2017


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...
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


More information about the Intel-gfx mailing list