[PATCH] fix-glamofb-flicker-72hz-refresh.patch

[joerg]

Am Mo  10. März 2008 schrieb Werner Almesberger:
> Andy Green wrote:
> > This is on a 200MHz bandwidth 'scope, that's really what
> > the "square wave" actually looks like at the LCM connector :-)
> 
> My breakfast almost hit the screen :-(
> 
> I wouldn't be surprised if this caused yield issues or, worse,
> misbehaviour in the field.
> 
> We also had a LCM clock problem in GTA01 development, where a clock
> was accidently inverted. (Not sure if this was pixels or data.)
> Surprisingly, the LCM tolerated this abuse more often than not,
> that's why it took us months to find that problem, but there was
> surely a lot of anger on our side about the "lousy quality" we got
> from our supplier ...
> 
> (I kind of wonder what they thought of us ;-)
> 
> > If there is no objection maybe we could try 12pF or somesuch there
> > instead of 47pF.  But at this time near production I can imagine the
> > urge is to let all sleeping dogs lie.
> 
> 47pF really seems to be pushing our luck. Allen, do you remember
> what kind of interference issue this fixes ?
> 
> - Werner
> 

It's not only waveshape and VIL/VIH thresholds not being reached(!!), it's 
first of all about *timing*.
RGB-data has to be stable & steady t-DSU before and t-DHO after rising edge of 
PCLK (duh, which edge?).

From datasheet (p.13):
VVVVVVVVVVVVVVVVVVVVVVVV
AC Characteristics:
                                                                Ratings
          Parameter               Symbol   Conditions                           
Unit
                                                        MIN      TYP       MAX
     VSYNC Setup time               VSSU        －         5       －           
－  ns
      VSYNC Hold time               VSHO        －        10       －           
－  ns
     HSYNC Setup time               HSSU        －         5       －           
－  ns
      HSYNC Hold time               HSHO     HS = 8 dot   5       －           
－  ns
      VSYNC-HSYNC
                                    HVPD        －         0       －           
－  ns
         Falling edge
       PCLK cycle time            PCLKCYC       －        34       －           
－  ns
  Clock “L” pulse width            PCLKL        －        12       －           
－  ns
  Clock “H” pulse width            PCLKH        －        12       －           
－  ns
        DE setup time                ESU        －         5       －           
－  ns
        DE Hold time                EHO         －        10       －           
－  ns
        Data setup time             DSU         －         5       －           
－  ns
        Data Hold time              DHO         －        10       －           
－  ns
Note 1：Input signal rise/fall time：tr, tf ≦5 ns
Note 2：The threshold voltage of input signal：VIH = 0.7xVDDIO, VIL = 0.3Xvddio
AAAAAAAAAAAAAAAAAAAAAAA

See last 4 lines (DSU, DHO, Note1&2)! As well as PCLKL & PCLKH! We are running 
LCM out of specs for at least 6 parameters - with 24Mhz PCLK.

With this R-C combination the square wave is integrated to make an 
astonishingly linear (probably that's L, not R) triangular wave, with 
Vpp < (VIH - VIL) !!!
As long as the LCM clock recovery circuitry gets triggered at all, there 
normally will be not THAT much impact, just the data acquisition time 
completely undetermined. Best case is we capture one pixel off, worst case we 
get random data while data lines are floating (what is the case at vertical 
edges in screen picture).

For my opinion, there MUST NOT be any R-C in any of the bus lines, because it 
introduces propagation delay (or better: phase shift). Even with a C a 
magnitude smaller, there still is no simple way to program glamo LCD I/F 
timing correctly. 

A bus has to have an equal propagation delay on all lines. That's why bus 
leads are usually designed and routed to have equal length and run in 
parallel. If one of the lines is intentionally delayed, this will work only 
for a _fixed_ timing scheme resp. frequency (or to compensate for delays in 
the other lines). Here we don't need to use any hardware delay, for glamo 
supports programmable timing (if i'm correct with what i see in this 300+pp 
manual), and we *mustn't* use hardware delay because of multiple PCLK freq 
(unless you reprogram glamo I/F timing for each PCLK freq).

My suggestion: make that C a NC (the good news: doesn't need a PCB redesign). 
Whatever might have been the reason for introducing it, find another 
solution.

cheers
jOERG