Thread (14 messages) 14 messages, 5 authors, 2008-05-14

Re: lxfb driver regression

flat view

From: Jens Rottmann <hidden>
Date: 2008-05-09 10:33:41
Also in: lkml

Andres Salomon wrote:
The pixclock that's specified is 17460 (from the olpc dcon table)
[...] Prior to your patch, this was:  { 0x00004286, 56250 },
[...] Your patch adds:  { 0x00014170, 57375 },
Yes, of course that was my first idea, too. And this was my motivation for
sending you the cut down patch without the > 25 MHz entries. But I'm almost
prepared to bet this is not the root of the evil.

As I said, this does not explain why the resolution seems to switch to 800x640,
because lx_set_clock() does not return any feedback. I somehow doubt you'll get
a white screen just by raising the dotclock by 2 % (and getting it _closer_ to
the intended value)?

And before I wrote my mail yesterday, I checked the dotclock for the 0x00004286
and 0x00014170 PLL values with a scope, and both settings produced a fine signal
with the expected frequencies.

Anyway, I hope I'm wrong, then at least we'd have a solution for this issue.
BTW, where did the intermediate values in your table come from?
Took the original table from lxfb_ops.c, everywhere set DIV4 and divided
frequency by 4, merged it back into the original table, dropping all lines
within 300 kHz of an preexisting setting.
I wrote a small script to do this, to avoid typos when mangling the table
(assuming the original table was ok).
The LX data book shows the DOTPLL equation (6.14.2.14), but very
little documentation of DIV4 or the usable values below 15MHz.
LX Data Book, p. 554:
"DIV4: Divide by 4. When set, the PLL output is divided by 4 before clocking the
logic."

Sounds like a simple divider circuit _behind_ the PLL, so as long as the
original frequency is ok, the DIV4-ed should be, too.

As I said, I assumed the original table in lxfb_ops.c to contain usable values.
And all of the few settings I checked with the scope looked ok.

Jordan Crouse wrote:
... the original value (56.250), which in retrospect is probably
a better choice for ths display.
So in case the increased dotclock in fact causes the white screen, it might be
cleaner to lower the _requested_ dotclock in the OLPC DCON mode timing to 56.250
MHz instead of cutting out PLL settings.
I don't think we really need divided signals > 24Mhz.
Well, in my opinion it would be nice to have some intermediate steps in the
available dotclocks. However, I don't actually need those for the 320x240 panel,
so I don't care much.

Regards,
Jens

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help