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

[Russell King - ARM Linux]

On Thu, Nov 02, 2017 at 11:10:33PM +0000, Luís Mendes wrote:
> Even if I make all calls of copyNtoN(...) go to the unaccelerated fallback
> the MMUs still occur in the same amount.

I've looked at your emails so far - I don't think you're selecting the
correct one.  Yes, you're finding those with a destination pixmap size
of the required size, but remember that the clip window was 1024x24.
We're looking for one where the extent matches that.

> I get this different kernel MMU fault:
> === Register dump
> 0000000c = 000000df
> 00000000 = 00040900
> 00000004 = 7ffffff8 Idle: FE- DE- PE- SH+ PA+ SE+ RA+ TX+ VG+ IM+ FP+ TS+
> 00000008 = 00002200
> 00000014 = ffffffff
> 00000018 = 14010000
> 0000001c = e02c7eca
> 00000020 = 00000320
> 00000024 = 00005303
> 00000028 = 20140510
> 0000002c = 20353900
> 00000034 = e9399eff
> 00000038 = e9399eff
> 00000070 = 00000000
> 00000100 = 00140021
> 00000104 = 00000000
> 00000108 = 000000fa
> 0000010c = 00000000
> 00000400 = 00000000
> 00000404 = 00000000
> 00000408 = 00000000
> 0000040c = 00000000
> 00000410 = 00000000
> 00000414 = 3c000000
> 00000418 = 00000000
> 0000041c = 00000000
> 00000420 = 00000000
> 00000424 = 00000000
> 00000428 = 00000000
> 0000042c = 00030000
> 00000480 = 000000a8
> 0000065c = 00000001
> 00000660 = 00000803 Cmd: [load0 DMA: idle Fetch: valid] Req idle Cal idle
> 00000664 = 000010b0 Command DMA address
> === Buffers
>  Num Name  IOVA     Size
>    0 reg   00000000 00000128      296
>    1 mmu   00000000 00401000  4198400
>    2 ring  00000000 00001000     4096
> *  3 cmd   00001000 000001a0      416
>    4 cmd   00002000 00000190      400
>    5 cmd   00003000 000001a0      416
>    6 cmd   00004000 00000190      400
>    7 bomap 00000000 000018d8     6360
>    8 bo    00040000 00300000  3145728
>    9 bo    00340000 00001000     4096
>   10 bo    02316000 00001000     4096
>   11 bo    0231e000 00001000     4096
>   12 bo    02320000 00018000    98304
> Checking MMU entries... ok

00000: 08050480 00040000  LDST 0x1200=0x00040000
                00001000  LDST 0x1204=0x00001000
                00000000  LDST 0x1208=0x00000000
                06000046  LDST 0x120c=0x06000046
                ffe80000  LDST 0x1210=0xffe80000
00018: 0804048a 02320000  LDST 0x1228=0x02320000
                00001000  LDST 0x122c=0x00001000
                00000000  LDST 0x1230=0x00000000
                00002006  LDST 0x1234=0x00002006
00030: 0802049f 00ff0001  LDST 0x127c=0x00ff0001
                01000100  LDST 0x1280=0x01000100
00040: 080304b2 ff000000  LDST 0x12c8=0xff000000
                00000000  LDST 0x12cc=0x00000000
                00000000  LDST 0x12d0=0x00000000
00050: 08030497 0030cccc  LDST 0x125c=0x0030cccc
                00000000  LDST 0x1260=0x00000000
                00180400  LDST 0x1264=0x00180400
00060: 20000100 00000000
                            00000000 00180400  0,-24,1024,0 -> 0,0,1024,24
        Blit: Dst:02320000 Src:00040000 Clip 0,0,1024,24
        Src: 0x00040000-0x00041000 (1024,0)
        Dst: 0x02320000-0x02339000 (1024,24)

This shows the same issue - a destination overrun.  Digging a bit
further into the dump shows that the states at 0x127c, 0x1280, 0x12c8
indicate that it's actually a blend operation, looks like PictOpSrc
with a source global alpha of 0xff.

That would make the operation from copy_to_vtemp in
etnaviv_acquire_src().

The other thing I notice is the source top y is -24, which is definitely
wrong.  Hmm, not sure quite what to make of that just yet...  I'll
think on it.

-- 
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