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

[Chris Wilson]

On Thu, Sep 18, 2014 at 06:54:15PM +0300, Mika Kuoppala wrote:
> 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.

I think you want to push the burden of work into the igt here. It first
must flush the GPU and ensure that is idle (which is done for us by the
framework anyway), then busy spin waiting for the hardware to quiesce
before checking the w/a in that case.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre