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@xxxxxxxxx> writes: > > > >>On Thu, Sep 25, 2014 at 11:17:00AM +0100, Tvrtko Ursulin wrote: > >>>From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >>> > >>>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@xxxxxxxxx> > >> > >>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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
