<div dir="ltr">Hi Lucas,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 30, 2017 at 11:31 AM, Lucas Stach <span dir="ltr"><<a href="mailto:l.stach@pengutronix.de" target="_blank">l.stach@pengutronix.de</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"><div class="gmail-HOEnZb"><div>Am Mittwoch, den 30.08.2017, 11:20 +0100 schrieb Luís Mendes:<br>
><br>
> On Wed, Aug 30, 2017 at 10:56 AM, Lucas Stach <<a href="mailto:l.stach@pengutronix.de">l.stach@pengutronix.de</a>><br>
> wrote:<br>
> Am Mittwoch, den 30.08.2017, 10:46 +0100 schrieb Luís Mendes:<br>
> > Hi Lucas,<br>
> ><br>
> ><br>
> > I see in xf86-video-armada/etnaviv/<wbr>etnaviv.c, that each of<br>
> the<br>
> > functions etnaviv_PolyLines,..., has a respective fallback<br>
> function<br>
> > call name unaccel_...<br>
> ><br>
> ><br>
> > When you say disable individual acceleration function, you<br>
> are saying<br>
> > to force the call to the respective unaccel function?<br>
> ><br>
> Yes, this way you should be able to narrow down which of the<br>
> acceleration functions is causing the GPU MMU faults. When you<br>
> have that<br>
> you can dump the parameters for all invocations of this<br>
> function, to<br>
> figure out why the GPU is accessing invalid memory regions.<br>
><br>
><br>
> Ok, I'll try to do that as soon as I find some spare time.</div></div></blockquote><div><br></div><div>I've found a couple of minutes to test these and I have found that on iMX6QP:<br></div><div><br></div><div>static RegionPtr<br>etnaviv_CopyArea(DrawablePtr pSrc, DrawablePtr pDst, GCPtr pGC,<br> int srcx, int srcy, int w, int h, int dstx, int dsty)</div><div><br></div><div>when forcing the unaccel call, no missing text areas occur in the menus and dialog windows, however the MMU fault still occur.</div><div>The MMU fault seem to not cause any visibile disruption, in fact, if I disable all acceleration functions in the function below, like shown:<br></div><div><br></div><div><br></div><div>static void<br>etnaviv_ValidateGC(GCPtr pGC, unsigned long changes, DrawablePtr pDrawable) {</div><div>...</div><div>/* if (!etnaviv->force_fallback && etnaviv_GC_can_accel(pGC, pDrawable))<br> pGC->ops = &etnaviv_GCOps;<br> else */<br> pGC->ops = &etnaviv_unaccel_GCOps;</div><div><br></div><div>The MMU faults still occur.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
><br>
><br>
> Regarding the screen blanking do you have a suggestion on how to debug<br>
> it? I found that it is related with the prefetech unit enablement<br>
> introduced in kernel 4.12.0, kernels 4.11.x do not exhibit such<br>
> behaviour. What is happening is that when the X session is started for<br>
> the login screen, sometimes the mouse arrow is seen for a second and<br>
> then the screen blanks, sometimes the whole login screen can be seen<br>
> for 10 seconds or so, and then either blanks or shows a corrupted<br>
> screen image. Sometimes nothing is seen and screen just blanks before<br>
> the X session starts.<br>
<br>
</div></div>Make sure to use an upstream DT, where the PRE/PRG units are actually<br>
used. The IPU driver will switch to using low-priority IPU channels when<br>
it's on a QuadPlus IPU, which will starve the display when the PRG/PRE<br>
units aren't set up correctly.<br></blockquote><div>In respect to the DT, I believe I don't have to do any special configuration other than include imx6qp.dtsi from the upstream, it where pre and prg units are defined, and I am already doing that. I see no other board DT file to add any further configurations to it. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Lucas<br>
<br></blockquote><div>Regards,</div><div>Luís<br></div></div></div></div></div>