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

[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.)

When I was involved with the kernel side of etnaviv, I had arranged
for the driver to use devcoredump, and had tools to disect the device
coredumps to investigate issues.  However, those coredump files tend to
be /very/ large as they contain everything - all buffers that are
associated with the GPU.  It's likely also that the MMU fault is
happening after the command buffer has been retired, so any core dump
is not going to be useful.

Moreover, I have no iMX6QP - well, I may have an iMX6QP SolidRun
Microsom from their initial test run that I could plug onto a baseboard,
but they never produced a version of uboot that worked with it, because
they saw no beneficial enhancements with the SoC.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up