[PATCH] debug-flicker.patch

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> On Mon, Mar 10, 2008 at 07:22:54PM +0000, Andy Green wrote:
>> It seems the place where the slow clock rate is defined for landscape is
>> outside of the kernel?  Where is this actually selected?
> IIRC, it is set by Xglamo on rotation.

Ah I see, thanks for the explanation.

Well I will force it in the kernel for testing I guess.

>> I tried to use fbset but it just seems to trash the stride of the
>> display somehow... has this ever worked?
>> Eg,
>> # fbset -g 480 640 480 640 16
>> should be a "no-op" when done on the default text framebuffer, but it
>> trashes the stride.
> It is a no-op on my GTA02v5 when in the console (X not running) or X is
> in portrait mode.  I run the daily build from last Friday.

Hum me too now (I must say the rootfs has come on quite a bit since the
old one I have been using for ages... makes sounds and everything...
encouraging).

> It trashes the stride when X is in landscape mode.  It is an expected
> behavior since the kernel doesn't(?) notify Xglamo about geometry
> change.

OK.  It makes a bit of sense now that there is no rotation option in
fbset then, this is happening on the X layer above.

I will try to force the landscape to use 24.5MHz in the kernel with
correct settings for HSYNC and so on and see what happens.  Currently I
forced the pixel clock to be the same 40ns in the kernel regardless of
how it was set, and I see the artifacts you mentioned.  Right now in
addition it seems each line is repeated because I only see the top half
of the video... I guess this is due to my messing up its calculations by
forcing the pixel clock somehow.

PCLK:  24.5MHz
VSYNC: 42Hz
HSYNC: 26.8kHz

HSYNC / PCLK period --> ~930 pixels/line  <==== !!!
VSYNC / HSYNC = 643 lines / frame

But the most interesting thing is that like this redraws from the CPU to
the video become incredibly slow, updating a digit on the clock takes a
seconds or so and is visible.  Clearly we are starving the CPU from
accessing the glamo RAM because we are maxing out the bandwidth to the
glamo RAM.  Maybe this can be the reason for the twinkling.

Either way this is interesting news, at 930x643 24.5MHz frames CPU side
access to the Glamo memory appears to be pretty badly starved in
arbitration.  But the pixel clock rate is the same, just longer lines.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH1liYOjLpvpq7dMoRAumrAJ9B0a+oMpTQzcgA5+XkrKrpFFKGhACgiBX0
732G2FPo7k3SxwPDURmWpdQ=
=grbm
-----END PGP SIGNATURE-----