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

[Luís Mendes]

Hi Russel, Lucas,

I have some news regarding the above topic...
I was supposed to check the X server API, but unfortunately I still didn't
find the time to do it, however I've noticed that these commits in
linux-4.14-rc5 improve the situation regarding the corrupted screen and
screen blanking in the Ubuntu Mate 17.04 login screen with i.MX6 Quad Plus:

*gpu: ipu-v3: pre: implement workaround for ERR009624*
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
linux.git/commit/?h=v4.14-rc6&id=11aff4b4c7c4b7257660ef890920f2ac72911ed0

*gpu: ipu-v3: prg: wait for double buffers to be filled on channel startup*
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
linux.git/commit/?h=v4.14-rc6&id=263c3b8044f9c9356a34fdb2640b52d27e378f9c

*gpu: ipu-v3: Allow channel burst locking on i.MX6 only*
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
linux.git/commit/?h=v4.14-rc6&id=cda77556447c782b3c9c068f81ef58136cb487c3

I've just tested kernel 4.14-rc5 on my Wandboard Quad Plus and it is able
to display the login screen without blanking or corrupting the image, while
in linux-4.13 it wasn't working. I used the new Fabio's DTBs for the
Wandboard Quad Plus rev. D1 in both kernel versions. These DTBs fix the
problem I was having with corrupted screen during early boot, but not the
login screen.

Unfortunately the MMU faults remain along with the missing text in menus
and icons as already reported.

I would like to contribute more to this topic, but unfortunately I am not
being able to find the time do it.

Regards,
Luís Mendes

On Thu, Aug 31, 2017 at 1:44 PM, Lucas Stach <l.stach at pengutronix.de> wrote:

> Am Donnerstag, den 31.08.2017, 13:36 +0100 schrieb Luís Mendes:
>
>
>
> > The imx6q is not showing any issues on this Ubuntu Mate 17.04, even
> > for the conditions:
> > Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=24),
> > dst(y=0,h=25), dy=0
> > Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=24),
> > dst(y=-25,h=25), dy=25
> > Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=1),
> > dst(y=-25,h=25), dy=1
> > Aug 31 11:58:12 picolo etnaviv[4694]: Mismatch src(y=0,h=1),
> > dst(y=0,h=25), dy=0
> >
> >
> > No MMU faults, no screen corruptions.
> >
>
> The GPUs on MY6Q are unable to produce MMU faults, so with incorrect
> programming they are reading/writing unrelated data, or the MMU scratch
> page.
>
>
> > The imx6qp always have MMU faults and is showing the issues when
> > removing the "goto callback" instruction.
> > Aug 30 18:41:32 picolo etnaviv[1722]: Mismatch src(y=0,h=24),
> > dst(y=0,h=25), dy=0
> > Aug 30 18:41:34 picolo etnaviv[1722]: Mismatch src(y=0,h=24),
> > dst(y=-25,h=25), dy=25
> > Aug 30 18:41:34 picolo etnaviv[1722]: Mismatch src(y=0,h=1),
> > dst(y=-25,h=25), dy=1
> > Aug 30 18:41:41 picolo etnaviv[1722]: Mismatch src(y=0,h=1),
> > dst(y=0,h=25), dy=0
>
> The MX6QP is much stricter on the MMU side and will stop the GPU from
> processing any further commands if it is trying to read/write unmapped
> data.
>
> >
> > This probably indicates that there is no implementation issue with
> > CopyNtoN and this is rather a side effect of the MMU faults.
> >
>
> This indicates there is in fact an implementation error in CopyNtoN, but
> as Russell pointed out it seems to be caused by core X server functions.
> The question is if we can reasonably work around the issue.
>
> Regards,
> Lucas
>
>
Thanks for the clarification.
I will have a look at the X server APIs that Russell is referring to... and
check the CopyNToN implementation.
Maybe I can find something, although I am not familiar with these APIs.

Regards,
Luís
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/etnaviv/attachments/20171023/ae8a2de2/attachment-0001.html>