Fwd: LCM flicker

[Andy Green]

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

> I only have "LCM_TD028TTEC1 product spec Ver 0.0 20060105.pdf".  It
> talks about a min PCLK of 20MHz.  So, yeah, we do not satisfy the
> requirement of PCLK when in landscape mode.

What does this mean?

Can we move this thread to openmoko-kernel?
Wolfgang

On Mar 8, 2008, at 12:15 AM, Chia-I Wu wrote:

> On Fri, Mar 07, 2008 at 03:31:22PM +0000, Andy Green wrote:
>>>> about 60Hz (24MHz / ((480 + 120) * (640 + 20))) refresh rate.
>> Studying the LCM data, it seems the frame there should be 648 x 520
>> (table 7.1, p10 LCM_TD028TTEC1 product spec Ver 0.20  
>> 20070319.pdf)... is
>> this correct?  Where did the (480 + 120) and (640 + 20) actually  
>> come from?
> Page 8 of "TP076 Softwave Design Guide for TD028TTEC1- 
> V10-20060613.pdf".
> 660x600 are listed as typical values, while 648x559 are listed as min.
> values.
>> I didn't find a figure in the LCM datasheet for a minimum refresh  
>> rate,
>> but it does talk about a min PCLK of 22MHz.
> I only have "LCM_TD028TTEC1 product spec Ver 0.0 20060105.pdf".  It
> talks about a min PCLK of 20MHz.  So, yeah, we do not satisfy the
> requirement of PCLK when in landscape mode.

It means we operate the LCM outside of its rated pixel clock speed range
when we use landscape with this "quarter speed" workaround for the
landscape artifact issue.

TD028TTEC1 Softwave Design Guide.-V13-20070411.pdf p8 specifies the
valid range as 22 - 28MHz, it seems we drive it at 12MHz in landscape.

It suggests we need to back up to having the artifacts and try to
understand the source of the problem in the Glamo.

The only reason I can think for the minimum frequency is to enforce a
minimum effective frame rate.  The QVGA mode allows a minimum PCLK of
6.5MHz which fits with that.  If that's right it is basically telling
you if you run PCLK < 22MHz you won't refresh frames fast enough for the
panel (and see flicker).

So that is a separate issue about Landscape -only that can explain why
the flicker is worse.


It seems we have been using canned register init for 680 x 600 (==
408000 == 60Hz at 24.5MHz PCLK) pixel clocks when we only need to use
648 x 520 (== 336960 == 72Hz at 24.5MHz PCLK).  If the flicker really
does come from TFT decay / refresh rate, we can increase our refresh
rate from 60Hz -> 72Hz with the same pixel clock by using the minimal
timings... there is no reason to use the current bloated timings since
the video doesn't interoperate with anything else like NTSC out.

But those numbers (60Hz) already should be fine and not make flicker
AFAIK.  So this isn't a satisfying explanation.


There is an internal "booster" that is not documented in the LCM to
generate AVDD and XVDD.  It is mentioned on three registers in the
control ASIC, one of which sets the "booster frequency" for these two
rails whatever that means.

Additionally there is an "internal oscillator" mentioned in the docs but
not defined anywhere as to what it does.

We need a bit more information about the internal structure of the LCM.

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

iD8DBQFH0mWdOjLpvpq7dMoRAhk2AJ9ZbVA0PqoZK1SFcIzu5aucqQXzgwCggi61
rhvtUG2p4VJZleH9Dm47gHM=
=oZQB
-----END PGP SIGNATURE-----