LCM Flicker source cause and solution

Andy Green andy at openmoko.com
Wed Mar 26 13:15:48 CET 2008


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

Hi folks -

We finally understood the root cause of the flicker together with most
of an explanation, and a solution so we are able to go back to hardware
rotation without flicker.

LCM ASIC register "ASW signal slew rate adjustment (BDh)" offers five
settings in the three LSBs (ASW appear to be individual pixel colour
strobe signals clocking pixel data to the panel) :

0: pixel strobe ordering R - G - B
1: pixel strobe ordering B - G - R
2: alternate 0 / 1 above each frame  <=====[ default ]
3: alternate 0 / 1 above each HSYNC
4: alternate 0 / 1 above both each frame and HSYNC

So it defaults to swapping R and B ordering per frame in how they are
sent to the panel, but *green* stays where it is.  This is why we do not
see flicker on green.

Basically ANY other setting removes the flicker, only 3 has a very
subtle horizontal lining artifact to my eye.

Since this swapping is done to "reduce EMI" from a static image (or
rather, disorder EMI), I think we should start with option 4.

I also experimented with reducing PCLK in portrait now the flicker was
gone, but 16MHz (/3) had horizontal artifacts for some reason -- it had
these last time I tried it with landscape as well --  and 12MHz (/4)
looked like a sensitive eye could find a much more subtle flicker.  So I
left it at 24.5MHz for now.

If someone can test the patch that follows in a moment (and is on the
"andy" git branch) with landscape and confirm it works okay we should be
sorted.

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

iD8DBQFH6j50OjLpvpq7dMoRApn3AJ40uElH5kaG74nhOGkg9pN9h1toNgCcDxe2
smiHrqub2yBfNXLMn4CFz7A=
=kiNV
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list