update from s-media regarding landscape flicker

Andy Green andy at openmoko.com
Tue Mar 25 13:01:07 CET 2008


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

Somebody in the thread at some point said:

> **pixelclock** has to go down in landscape? Is this for the different address 
> sequence scheme in RAM for each of the 2 modes, or does glamo some internal 
> transformation by blitting, thus eating 2/3 of the bandwidth or what?

Yes, I guess the problem for this chip comes from the fact it still
issues a portrait raster to the LCM, so it has to compose each portrait
line from pixels that are totally disjoint in memory.

In portrait, adjacent pixels are in ascending order in memory, so after
issuing the address to the DRAM and paying the penalty for random
access, prefetch or block fetch modes from the memory work well since
you are going to use that data for the next pixels.

In this "rotated portrait" mode, scanline-adjacent pixels are 640 x 2 =
1280 bytes away from each other in memory, and you have to compose your
scan line from them at video speed.  Whatever penalty the DRAM in the
Glamo makes you pay in clocks for random access, you are paying it on
every single pixel in the scan line you send out.  (If it made you get a
page at a time -- 16 bytes or whatever -- then you are discarding 14
bytes of the 16 for every pixel too.)

It is able to just about keep up at lower pixel clock and frame rates
but not at 24.5MHz pixel clock.

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

iD8DBQFH6OmDOjLpvpq7dMoRAr8wAJ9QEvQ4XC6Btu48uXiZeegvhblPYQCgimOb
I4zQ9eDwwmNoQUrIobOr2TY=
=nUvS
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list