Re: lxfb driver regression

On 08/05/08 15:56 +0200, Jens Rottmann wrote:

Hi Andres,

quoted

Without this patch, I get the following (correct) output from the lxfb
and console code:
[    0.939827] lxfb 0000:00:01.1: 16384 KB of video memory at 0xfd000000
[    1.009194] Console: switching to colour frame buffer device 150x56     

quoted

Without it, the cols/width is screwy (and I get a blank white screen):
[   20.706836] lxfb 0000:00:01.1: 16384 KB of video memory at 0xfd000000
[   20.788538] Console: switching to colour frame buffer device 100x40          

I've searched all morning, but I don't get it. The only place the (changed)
pll_table[] gets used is lx_set_clock(), and this doesn't return anything at
all. lx_set_clock() gets told which dotclock to configure and it does its best
to comply, but it doesn't report back, which clock it actually was able to
select. So how on earth can changing this table cause fbcon or lxfb to decide
for a completely different videomode?? Without the patch it seems to use the
special 1200x900 OLPC DCON mode. With the patch it looks like it switches to
some 800x640 mode. No idea where this mode might come from.

And why does the lxfb init take place 20 sec later with the patch? Is there
some initrd manually setting a different mode? Is this offending 800x640 mode
maybe not coming from the kernel, but from some startup script via "fbset" and
"/etc/fb.modes"?

I don't have an OLPC, so could you please run "fbset -i -v" with and without
my patch. Hopefully this gives some clues...

I have also attached a cut down version of my patch. It still adds all the PLL
settings for < 25 MHz dotclocks, but it no longer supplements the > 25 MHz
clocks with intermediate steps. I'm only guessing here, I don't see what big
difference this would make, but still ... could you please give it a try if
you have time?

Part of what was happening here was that one of the DIV4 generated frequencies
( 0x00014170, 57375) was a closer match for the OLPC intended frequency
(57.273) then the original value (56.250), which in retrospect is probably
a better choice for ths display.

The DIV4 bit was really only intended to provide frequencies less then what
it could cleanly generate on its own.  The datasheet says '
This bit is intended for generating frequencies below the PLL spec limit
of 15Mhz'.  I don't think we really need divided signals > 24Mhz.
The new patch you sent out was good, and I'll ack it.

That said, Andres has some interesting behaviors in his report that
probably need to be looked at, but the different clock could
explain the white screen, especially with the LCD situation on the XO.

Thanks,
Jordan

=============X8=================X8==============================
lxfb: extend PLL table to support dotclocks below 25 MHz

Extends the PLL frequency table of the AMD Geode-LX frame buffer
driver to make use of the DIV4 bit, thus adding support for
dotclocks between 6 and 24 MHz.  These are needed for small LCDs
(e.g. 320x240).

Signed-off-by: Jens Rottmann <redacted>

Acked-by: Jordan Crouse <redacted>

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.