[Intel-gfx] [PATCH] drm/i915/skl: Use correct use counters for force wakes

Damien Lespiau damien.lespiau at intel.com
Thu Sep 25 15:13:00 CEST 2014


On Thu, Sep 25, 2014 at 01:43:31PM +0100, Tvrtko Ursulin wrote:
> 
> On 09/25/2014 01:05 PM, Mika Kuoppala wrote:
> >Damien Lespiau <damien.lespiau at intel.com> writes:
> >
> >>On Thu, Sep 25, 2014 at 11:17:00AM +0100, Tvrtko Ursulin wrote:
> >>>From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>>
> >>>Write and reads following the block changed use engine specific use counters
> >>>and unless that is matched here force wake use counting goes bad. Same
> >>>force wake is attempted to be taken twice which leads to at least time outs.
> >>>
> >>>Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>
> >>Is it worth a v2 to have gen >= 9 here?
> >
> >I think we should have gen >= 8 here.
> 
> But that would not match against the current implementation of GEN8
> vs CHV read/write functions.

The first problem here is that we have two sets of reference counts, one
for FORCEWAKE_ALL (uncore.forcewake_count) and one for each forcewake
engine on CHV/SKL. CHV has 2 fw engines, SKL 3.

So, in that regard, maybe the fw engine abstraction needs work to unify
the reference counts.

The least intrusive change to make SKL not error out would be to have a
separate code path for gen >= 9 with the 3 engines.

The thread leading to that patch is great and already has all the right
questions. We just ignored them.

The most immediate one is, why are we waking up all the fw engines when
writing a specific ring ELSP, but the whole thread is worth reading.

> >Shadowed ELSP's seems not to work on gen8. And the posting read will
> >need fw anyways.
> >
> >Assuming the shadowing works on skl and we can get rid of the posting
> >read, we could run this part without taking forcewake.
> 
> I don't know what criteria would need to be satisfied to get rid of
> the posting read. On GEN9 only you are saying?
> 
> 2nd part, how to test if shadowing works? Just remove force wakes
> and see what happens?

And that's a separate issue, can we use the shadow register mechanism to
ensure the write lands and is that enough? Let's try to ask people
internally about that.

HTH,

-- 
Damien



More information about the Intel-gfx mailing list