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