[Intel-gfx] [PATCH v2 2/3] drm/i915: Setup MCR steering for RCS engine workarounds

[Tvrtko Ursulin]

On 05/05/2020 00:34, Matt Roper wrote:
> On Mon, May 04, 2020 at 12:43:54PM +0100, Tvrtko Ursulin wrote:
>> On 02/05/2020 05:57, Matt Roper wrote:
>>> Reads of multicast registers give the value associated with
>>> slice/subslice 0 by default unless we manually steer the reads to a
>>> different slice/subslice.  If slice/subslice 0 are fused off in hardware,
>>> performing unsteered reads of multicast registers will return a value of
>>> 0 rather than the value we wrote into the multicast register.
>>>
>>> To ensure we can properly readback and verify workarounds that touch
>>> registers in a multicast range, we currently setup MCR steering to a
>>> known-valid slice/subslice as the very first item in the GT workaround
>>> list for gen10+.  That steering will then be in place as we verify the
>>> rest of the registers that show up in the GT workaround list, and at
>>> initialization the steering will also still be in effect when we move on
>>> to applying and verifying the workarounds in the RCS engine's workaround
>>> list (which is where most of the multicast registers actually show up).
>>>
>>> However we seem run into problems during resets where RCS engine
>>> workarounds are applied without being preceded by application of the GT
>>> workaround list and the steering isn't in place.  Let's add the same MCR
>>> steering to the beginning of the RCS engine's workaround list to ensure
>>> that it's always in place and we don't get erroneous messages about RCS
>>> engine workarounds failing to apply.
>>>
>>> References: https://gitlab.freedesktop.org/drm/intel/issues/1222
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com>
>>> Cc: chris at chris-wilson.co.uk
>>> Signed-off-by: Matt Roper <matthew.d.roper at intel.com>
>>> ---
>>>    drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
>>>    1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> index 4a255de13394..b11b83546696 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>>> @@ -1345,6 +1345,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
>>>    {
>>>    	struct drm_i915_private *i915 = engine->i915;
>>> +	if (INTEL_GEN(i915) >= 10)
>>> +		wa_init_mcr(i915, wal);
>>> +
>>>    	if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0)) {
>>>    		/*
>>>    		 * Wa_1607138336:tgl
>>>
>>
>> No complaints, only a question - is live_engine_reset_workarounds able to
>> catch this, presumably sporadic, 0xfdc loss after engine reset?
> 
>>From what I can see, it looks like that selftests uses a separate
> ring-based approach to handling the workarounds rather than using the
> CPU.  It looks like that selftest just skips all MCR registers since we
> can't steer ring accesses the way we can with the CPU.

But 0xfdc is verified after engine reset with a mmio read. Because it is 
in the GT list. Strange.. Ack on the series anyway.

Regards,

Tvrtko