[PATCH] fix-glamofb-flicker-72hz-refresh.patch
joerg
joerg.twinklephone at gmx.de
Mon Mar 10 22:34:25 CET 2008
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
More information about the openmoko-kernel
mailing list