<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 31, 2017 at 9:41 AM, Russell King - ARM Linux <span dir="ltr"><<a href="mailto:linux@armlinux.org.uk" target="_blank">linux@armlinux.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wed, Aug 30, 2017 at 06:40:09PM +0100, Luís Mendes wrote:<br>
> Hi,<br>
><br>
> I've reduced the set of cases that cause the copy areas to fail to single<br>
> logic condition on void etnaviv_accel_CopyNtoN(...).<br>
> I was able to fix the screen with:<br>
> ...<br>
> if (pSrc->height != pDst->height) {<br>
> syslog(LOG_WARNING, "Mismatch src.w=%d, dst.w=%d\n", pSrc->height,<br>
> pDst->height);<br>
> goto fallback;<br>
> }<br>
> ...<br>
><br>
> What is happening is that areas that fail to copy have a pSrc.height value<br>
> of 24 pixels, but pDst.height value of 25 pixels, etc.<br>
<br>
</span>It's also important to know the pSrc and pDst y, and dy values.<br>
<br>
If these are all zero, what we're being asked to do is to copy a<br>
drawable that is 24 pixels high into the top of a drawable that is<br>
25 pixels high. This function is only (afaik) defined for copying.<br>
So what should it be doing with the extra line that the destination<br>
has if the set of boxes are requesting that line be written?<br><br></blockquote><div> </div><div>I've conducted further tests with a imx6q and a imx6qp with the same connected monitor and resolution of 1024x768.</div><div>I modified the code of etnaviv_accel.c to the imx6qp to:</div><div><br></div><div>
void etnaviv_accel_CopyNtoN(..) {</div><div>...<br></div><div>if (pSrc->height < pDst->height) {<br> syslog(LOG_WARNING, "Mismatch src(y=%d,h=%d), dst(y=%d,h=%d), dy=%d\n", pSrc->y, pSrc->height, pDst->y, pDst->height, dy);<br> goto fallback;<br>} <br></div><div><br></div><div>which is enough to mask the copy area problems.<br></div><div><br></div><div>On the imx6q I modified it to:</div><div><div><br>
</div><div>void etnaviv_accel_CopyNtoN(..) {</div><div>...<br></div><div>if (pSrc->height < pDst->height) {<br>
syslog(LOG_WARNING, "Mismatch src(y=%d,h=%d), dst(y=%d,h=%d), dy=%d\n",
pSrc->y, pSrc->height, pDst->y, pDst->height, dy);<br>} <br></div><div><br></div></div><div><br></div><div>The imx6q is not showing any issues on this Ubuntu Mate 17.04, even for the conditions:</div><div>Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=24), dst(y=0,h=25), dy=0<br>Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=24), dst(y=-25,h=25), dy=25<br>Aug 31 11:58:08 picolo etnaviv[4694]: Mismatch src(y=0,h=1), dst(y=-25,h=25), dy=1<br>Aug 31 11:58:12 picolo etnaviv[4694]: Mismatch src(y=0,h=1), dst(y=0,h=25), dy=0</div><div><br></div><div>No MMU faults, no screen corruptions.<br></div><div><br></div><div><br></div><div>The imx6qp always have MMU faults and is showing the issues when removing the "goto callback" instruction.</div><div>Aug 30 18:41:32 picolo etnaviv[1722]: Mismatch src(y=0,h=24), dst(y=0,h=25), dy=0<br>Aug 30 18:41:34 picolo etnaviv[1722]: Mismatch src(y=0,h=24), dst(y=-25,h=25), dy=25<br>Aug 30 18:41:34 picolo etnaviv[1722]: Mismatch src(y=0,h=1), dst(y=-25,h=25), dy=1<br>Aug 30 18:41:41 picolo etnaviv[1722]: Mismatch src(y=0,h=1), dst(y=0,h=25), dy=0</div><div><br></div><div>This probably indicates that there is no implementation issue with CopyNtoN and this is rather a side effect of the MMU faults.<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
from what I can see in the Xorg fb layer, it entirely ignores the<br>
boundaries of the drawable, and just copies from the source even if<br>
this means overflowing its width and height, which sounds very<br>
problematical as that can end up running off the end of the allcoated<br>
memory - or in the case of a GPU, end up running off the end of the<br>
mapped buffer and causing GPU faults / crashes.<br>
<br>
However, miDoCopy() should be generating exposures for those areas<br>
(see the comments in the Xorg source above miHandleExposures().) It<br>
sounds like this is failing in some way, but that is all generic Xorg<br>
code, so should afflict all DDX drivers including the fallbacks.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
--<br>
RMK's Patch system: <a href="http://www.armlinux.org.uk/developer/patches/" rel="noreferrer" target="_blank">http://www.armlinux.org.uk/<wbr>developer/patches/</a><br>
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up<br>
According to <a href="http://speedtest.net" rel="noreferrer" target="_blank">speedtest.net</a>: 8.21Mbps down 510kbps up<br>
</div></div></blockquote></div><br></div></div>