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

[Russell King - ARM Linux]

On Fri, Nov 03, 2017 at 10:45:04AM +0000, Luís Mendes wrote:
> Hi Russel,

"Russell" ;)

> I was able to identify and circumvent the root cause of the MMU faults. We
> had 4 MMU faults, it seems.
> Each one for each of these conditions:
> Nov  3 10:26:26 picolo xf86_armada[1271]: A: clip[x1=0,y1=0],
> vSrc[w=1024,h=768], drawable[x=0,y=0], src_offset[x=0,y=0}
> Nov  3 10:26:26 picolo xf86_armada[1271]: A: clip[x1=0,y1=0],
> vSrc[w=1024,h=768], drawable[x=0,y=0], src_offset[x=0,y=0}
> Nov  3 10:26:29 picolo xf86_armada[1271]: B: clip[x1=0,y1=0],
> vSrc[w=1024,h=768], drawable[x=0,y=0], src_offset[x=0,y=0}
> Nov  3 10:26:32 picolo xf86_armada[1271]: B: clip[x1=0,y1=0],
> vSrc[w=1024,h=27], drawable[x=0,y=0], src_offset[x=0,y=0}
> 
> The modified etnaviv_render.c - etnaviv_acquire_src(...), that is able to
> circumvent the MMU faults and generate the above log is this one (changes
> in bold):
> static struct etnaviv_pixmap *etnaviv_acquire_src(ScreenPtr pScreen,
>     PicturePtr pict, const BoxRec *clip, PixmapPtr *ppPixTemp,
>     xPoint *src_topleft, Bool force_vtemp)
> {
>     struct etnaviv *etnaviv = etnaviv_get_screen_priv(pScreen);
>     struct etnaviv_pixmap *vSrc, *vTemp;
>     struct etnaviv_blend_op copy_op;
>     DrawablePtr drawable;
>     uint32_t colour;
>     xPoint src_offset;
>     int tx, ty;
> 
>     if (etnaviv_pict_solid_argb(pict, &colour)) {
>         vTemp = etnaviv_get_scratch_argb(pScreen, ppPixTemp,
>                          clip->x2, clip->y2);
>         if (!vTemp)
>             return NULL;
> 
>         if (!etnaviv_fill_single(etnaviv, vTemp, clip, colour))
>             return NULL;
> 
>         src_topleft->x = 0;
>         src_topleft->y = 0;
>         return vTemp;
>     }
> 
>     drawable = pict->pDrawable;
>     vSrc = etnaviv_drawable_offset(drawable, &src_offset);
>     if (!vSrc)
>         goto fallback;
> 
>     if (vSrc->width < clip->x2 || vSrc->height < clip->y2)
>         goto fallback;
> 
>     etnaviv_set_format(vSrc, pict);
>     if (!etnaviv_src_format_valid(etnaviv, vSrc->pict_format))
>         goto fallback;
> 
>     if (!transform_is_integer_translation(pict->transform, &tx, &ty))
>         goto fallback;
> 
>     if (picture_needs_repeat(pict, src_topleft->x + tx, src_topleft->y + ty,
>                  clip->x2, clip->y2))
>         goto fallback;
> 
> 
> 
>     src_topleft->x += drawable->x + src_offset.x + tx;
>     src_topleft->y += drawable->y + src_offset.y + ty;
>     if (force_vtemp) {
>         goto copy_to_vtemp;
>     }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *    if (clip->x2 == 1024 && clip->y2 == 24) {        syslog(LOG_ERR, "A:
> clip[x1=%d,y1=%d], vSrc[w=%d,h=%d], drawable[x=%d,y=%d],
> src_offset[x=%d,y=%d}\n",             clip->x1, clip->y1, vSrc->width,
> vSrc->height, drawable->x, drawable->y, src_offset.x, src_offset.y);
> goto fallback;    }    if (clip->x2 == 1024 && clip->y2 == 27) {
> syslog(LOG_ERR, "B: clip[x1=%d,y1=%d], vSrc[w=%d,h=%d],
> drawable[x=%d,y=%d], src_offset[x=%d,y=%d}\n",             clip->x1,
> clip->y1, vSrc->width, vSrc->height, drawable->x, drawable->y,
> src_offset.x, src_offset.y);        goto fallback;    }*
>     return vSrc;
>    ...

I'm not sure if the above is what you wanted to send - but I don't read
email using a mailer that understands HTML, so the above is what I saw.
"bold" doesn't work for the plain text part of emails, nor do colours!

It looks like you added your debugging to the fall-through path, where
we use the provided source picture/drawable.  Is that the path that's
giving the problems - I thought the faults were coming from the
etnaviv_render() call from this function, which implies that we need
to be taking the "copy_to_vtemp" branch of the if() statement above.

Note, it's worth using the picture_desc() helper to print the details
of the PicturePtr - this includes the basic details of the picture,
and the underlying drawable.  Also, please include the src_topleft
coordinates - I think you'll find one of those will be 0,-24.

I think the question is why we're ending up with the source top-left
being 0,-24.

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