etnaviv-gpu 134000.gpu: MMU fault status 0x00000002 on i.XM6 Quad Plus

[Lucas Stach]

Am Mittwoch, den 30.08.2017, 12:52 +0100 schrieb Russell King - ARM
Linux:
> On Wed, Aug 30, 2017 at 12:20:32PM +0100, Luís Mendes wrote:
> > I've found a couple of minutes to test these and I have found that on
> > iMX6QP:
> > 
> > static RegionPtr
> > etnaviv_CopyArea(DrawablePtr pSrc, DrawablePtr pDst, GCPtr pGC,
> >     int srcx, int srcy, int w, int h, int dstx, int dsty)
> > 
> > when forcing the unaccel call, no missing text areas occur in the menus and
> > dialog windows, however the MMU fault still occur.
> 
> It would be good to know the failure case - this has been tested with
> the various X test programs which do not reveal any issues with it.
> 
> I've found it rather difficult and very time consuming to setup test
> scenarios for issues that other people see with my DDX driver (which
> basically mean downloading an entire distro and trying to replicate
> their setup.)
> 
> > The MMU fault seem to not cause any visibile disruption, in fact, if I
> > disable all acceleration functions in the function below, like shown:
> > 
> > 
> > static void
> > etnaviv_ValidateGC(GCPtr pGC, unsigned long changes, DrawablePtr
> > pDrawable)  {
> > ...
> > /* if (!etnaviv->force_fallback && etnaviv_GC_can_accel(pGC, pDrawable))
> >         pGC->ops = &etnaviv_GCOps;
> >     else */
> >         pGC->ops = &etnaviv_unaccel_GCOps;
> > 
> > The MMU faults still occur.
> 
> That doesn't disable /all/ acceleration functions.  That disables the
> acceleration functions for the GC - in other words, operations that
> require a graphic context.  There's a number of other operations that
> the backend can use that do not use a GC and are unaffected by this.
> CopyWindow is one such example, but also the Render backend as well.
> 
> Now, all that said, this could be due to a known GC320 bug: the GC320
> fails to properly flush its caches after performing operations even if
> you ask it to.  In order to work around this, it is necessary to insert
> into the command stream an additional copy operation.  That copy
> operation pushes the previous operation out of the GC320's caches, but
> it could very well result in this very operation also falling foul of
> the very same bug (the difference being that its with the dummy buffer
> rather than with a real buffer, so the user shouldn't see any on-screen
> corruption.)

This issue is no longer present in the GC320 revision on the QuadPlus.
In fact I have a local patch to disable the workaround for this GC320
revision and have been unable to trigger the bug with a testcase that
was easily hitting the issue on the Quad/Duallite.

Regards,
Lucas