[Intel-gfx] [PATCH 3/6] drm/i915: Disable render idle on user forcewake

[Mika Kuoppala]

Chris Wilson <chris at chris-wilson.co.uk> writes:

> On Thu, Sep 18, 2014 at 05:58:32PM +0300, Mika Kuoppala wrote:
>> Render context on gen8 is not guaranteed to be loaded (active)
>> at the instant when forcewake ack shows up. So we need extra
>> steps to get it in before we access specific registers.
>> 
>> We could do register white listing to do the extra dance only on
>> specific render context access. However the main concern is
>> is ring initialization after reset/resume, so only take the extra
>> steps on user forcewake as it is already guarding ring init. And not incur
>> extra perf penalty to regular register accesses. This allows us to be
>> sure that we don't read all zeros on RMW cycles. And we to show a
>> consistent state to igt when user fw has been acquired.
>
> Might I just ask why? This talks about the need to serialise with the
> LRI use to load the context registers, so be explicit. When reading
> those registers, we should know what is going on with the GPU or just
> don't care. Writing to those registers once the ring is running is
> verboten.
>
> This is just very thin papering over an unexplained problem.

It is not clear why but on fw ack showing up, we have a short
delay before some registers on render contexts start to return
other than all zeroes. Usually you can get 2-3 reads before
the values show up. This manifests by sometimes the dfs/
i915_ppgtt_info will return 'render ring:PDP0' as zeroes or
top 32bits zeroes, ss it is the first read(s).

Also as our wa verification tests reads through mmio, after
getting user forcewake, we see sometimes read returning zeros.

If we do workaround verification by STORE_REGISTER_MEMs on
igt side and accept that debugfs/i915_forcewake_user doesn't
guarantee anything with regards to access to render context,
then I think that we can drop this patch.

And be very extra careful with workarounds that need RWM
on this area.

-Mika