Re: [PATCH 2/2] drm/i915: Add WaKBLVECSSemaphoreWaitPoll

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

 



Quoting Mika Kuoppala (2018-06-06 09:40:11)
> Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes:
> 
> > Quoting Mika Kuoppala (2018-06-05 17:03:57)
> >> There is a problem with kbl up to rev E0 where a heavy
> >> memory/fabric traffic from adjacent engine(s) can cause an engine
> >> reset to fail. This traffic can be from normal memory accesses
> >> or it can be from heavy polling on a semaphore wait.
> >> 
> >> For engine hogging causing a fail, we already fallback to
> >> full reset. Which effectively stops all engines and thus
> >> we only add a workaround documentation.
> >> 
> >> For the semaphore wait loop poll case, we add one microsecond
> >> poll interval to semaphore wait to guarantee bandwidth for
> >> the reset preration. The side effect is that we make semaphore
> >> completion latencies also 1us longer.
> >> 
> >> v2: Let full reset handle the adjacent engine idling (Chris)
> >> 
> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=106684
> >> References: VTHSD#2227190, HSDES#1604216706, BSID#0917
> >> Signed-off-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> >> ---
> >> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c b/drivers/gpu/drm/i915/intel_workarounds.c
> >> index b1ab56a1ec31..5655d39c65cb 100644
> >> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> >> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> >> @@ -666,6 +666,15 @@ static void kbl_gt_workarounds_apply(struct drm_i915_private *dev_priv)
> >>         I915_WRITE(GEN9_GAMT_ECO_REG_RW_IA,
> >>                    I915_READ(GEN9_GAMT_ECO_REG_RW_IA) |
> >>                    GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS);
> >> +
> >> +       /* WaKBLVECSSemaphoreWaitPoll:kbl */
> >> +       if (IS_KBL_REVID(dev_priv, KBL_REVID_A0, KBL_REVID_E0)) {
> >
> > Hmm, what revision was production? Just checking we need to ship this
> > w/a...
> 
> The bspec list of revs seems outdated so can't trust that blindly
> but already 0x1 is not preprod on that list. Also found nuc in lab
> which is 0x02.

Acked-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>

Care to update intel_detect_preproduction_hw() ?
-Chris
_______________________________________________
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