[Intel-gfx] [PATCH 2/2] drm/i915: Add WaKBLVECSSemaphoreWaitPoll

[Mika Kuoppala]

Chris Wilson <chris at chris-wilson.co.uk> 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 at linux.intel.com>
>> ---
>> 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.

-Mika