lxfb driver regression

lxfb driver regression

[Andres Salomon]

Hi,

I noticed that a patch from you went into 2.6.26-rc1 to adjust the PLL table
in the lxfb driver.  Unfortunately, it breaks on OLPC machines (I haven't
tested it on other Geode platforms yet, but I don't have any other Geodes
with panels anyways).  It's this commit:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3888d4639e78802c4ec1086127124e890461b9e4

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     

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          

Re: lxfb driver regression

[Andrew Morton]

On Wed, 7 May 2008 21:08:36 -0400 Andres Salomon <dilinger@queued.net> wrote:

> Hi,
> 
> I noticed that a patch from you went into 2.6.26-rc1 to adjust the PLL table
> in the lxfb driver.  Unfortunately, it breaks on OLPC machines (I haven't
> tested it on other Geode platforms yet, but I don't have any other Geodes
> with panels anyways).  It's this commit:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3888d4639e78802c4ec1086127124e890461b9e4
> 
> 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     
> 
> 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 queued a reversion but (as is often the case with non-critical
regressions) I'll hold off for a few days, see if we can get things fixed
up.

Re: lxfb driver regression

[Jens Rottmann]

Hi Andres,

> 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     

> 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?

Thanks a lot for your help.

Regards,
Jens Rottmann

=============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 <JRottmann@LiPPERT-AT.de>
---

--- linux-2.6.25/drivers/video/geode/lxfb_ops.c
+++ lxfb_clocks_added/drivers/video/geode/lxfb_ops.c
@@ -34,35 +34,63 @@ static const struct {
   unsigned int pllval;
   unsigned int freq;
 } pll_table[] = {
-  { 0x000031AC, 24923 },
-  { 0x0000215D, 25175 },
-  { 0x00001087, 27000 },
-  { 0x0000216C, 28322 },
-  { 0x0000218D, 28560 },
-  { 0x000010C9, 31200 },
-  { 0x00003147, 31500 },
-  { 0x000010A7, 33032 },
-  { 0x00002159, 35112 },
-  { 0x00004249, 35500 },
-  { 0x00000057, 36000 },
-  { 0x0000219A, 37889 },
-  { 0x00002158, 39168 },
-  { 0x00000045, 40000 },
-  { 0x00000089, 43163 },
-  { 0x000010E7, 44900 },
-  { 0x00002136, 45720 },
-  { 0x00003207, 49500 },
-  { 0x00002187, 50000 },
-  { 0x00004286, 56250 },
-  { 0x000010E5, 60065 },
-  { 0x00004214, 65000 },
-  { 0x00001105, 68179 },
-  { 0x000031E4, 74250 },
-  { 0x00003183, 75000 },
-  { 0x00004284, 78750 },
-  { 0x00001104, 81600 },
-  { 0x00006363, 94500 },
-  { 0x00005303, 97520 },
+  { 0x000131AC,   6231 },
+  { 0x0001215D,   6294 },
+  { 0x00011087,   6750 },
+  { 0x0001216C,   7081 },
+  { 0x0001218D,   7140 },
+  { 0x000110C9,   7800 },
+  { 0x00013147,   7875 },
+  { 0x000110A7,   8258 },
+  { 0x00012159,   8778 },
+  { 0x00014249,   8875 },
+  { 0x00010057,   9000 },
+  { 0x0001219A,   9472 },
+  { 0x00012158,   9792 },
+  { 0x00010045,  10000 },
+  { 0x00010089,  10791 },
+  { 0x000110E7,  11225 },
+  { 0x00012136,  11430 },
+  { 0x00013207,  12375 },
+  { 0x00012187,  12500 },
+  { 0x00014286,  14063 },
+  { 0x000110E5,  15016 },
+  { 0x00014214,  16250 },
+  { 0x00011105,  17045 },
+  { 0x000131E4,  18563 },
+  { 0x00013183,  18750 },
+  { 0x00014284,  19688 },
+  { 0x00011104,  20400 },
+  { 0x00016363,  23625 },
+  { 0x000031AC,  24923 },
+  { 0x0000215D,  25175 },
+  { 0x00001087,  27000 },
+  { 0x0000216C,  28322 },
+  { 0x0000218D,  28560 },
+  { 0x000010C9,  31200 },
+  { 0x00003147,  31500 },
+  { 0x000010A7,  33032 },
+  { 0x00002159,  35112 },
+  { 0x00004249,  35500 },
+  { 0x00000057,  36000 },
+  { 0x0000219A,  37889 },
+  { 0x00002158,  39168 },
+  { 0x00000045,  40000 },
+  { 0x00000089,  43163 },
+  { 0x000010E7,  44900 },
+  { 0x00002136,  45720 },
+  { 0x00003207,  49500 },
+  { 0x00002187,  50000 },
+  { 0x00004286,  56250 },
+  { 0x000010E5,  60065 },
+  { 0x00004214,  65000 },
+  { 0x00001105,  68179 },
+  { 0x000031E4,  74250 },
+  { 0x00003183,  75000 },
+  { 0x00004284,  78750 },
+  { 0x00001104,  81600 },
+  { 0x00006363,  94500 },
+  { 0x00005303,  97520 },
   { 0x00002183, 100187 },
   { 0x00002122, 101420 },
   { 0x00001081, 108000 },
@@ -137,7 +165,7 @@ static void lx_set_clock(struct fb_info
 	unsigned int diff, min, best = 0;
 	unsigned int freq, i;

-	freq = (unsigned int) (0x3b9aca00 / info->var.pixclock);
+	freq = (unsigned int) (1000000000 / info->var.pixclock);

 	min = abs(pll_table[0].freq - freq);

@@ -149,7 +177,7 @@ static void lx_set_clock(struct fb_info
 		}
 	}

-	lx_set_dotpll(pll_table[best].pllval & 0x7FFF);
+	lx_set_dotpll(pll_table[best].pllval & 0x00017FFF);
 }

 static void lx_graphics_disable(struct fb_info *info)

Re: lxfb driver regression

[Andres Salomon]

On Thu, 08 May 2008 15:56:36 +0200
Jens Rottmann <JRottmann@LiPPERT-AT.de> wrote:

> Hi Andres,
> 
> > 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     
> 
> > 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.


I played with it a bit last night. The pixclock that's specified is
17460 (from the olpc dcon table).  This gives a freq of 0xdfb9.
lx_set_clock then tries to figure out the best pll from the pll_table
by looking at the closest frequency.  Prior to your patch, this was:

  { 0x00004286, 56250 },
The freq difference was -1023, the closest of any in the table.   So,
we stuff 0x4286 into MSR_GLCP_DOTPLL, and all is good.

Your patch adds:
  { 0x00014170, 57375 },
The freq difference there is only 102, so lx_set_clock chooses
0x14170 as the pllval.

I'm unsure as to how that ends up causing the vc cols/rows stuff
to change..



> 
> 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"?
> 

Nope, that's a separate bug; IDE hangs for 20 seconds and then times
out.  I believe it's a regression in rc1, but I haven't had the chance
to look at it yet.  There's no initrd being used in this kernel.


> 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?
> 

I'm not sure if I'll be able to get to this today, but certainly by
tomorrow.  BTW, where did the intermediate values in your table come from?
The LX data book shows the DOTPLL equation (6.14.2.14), but very little
documentation of DIV4 or the usable values below 15MHz.



> Thanks a lot for your help.
> 
> Regards,
> Jens Rottmann
> 
> =============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 <JRottmann@LiPPERT-AT.de>
> ---
> 
> --- linux-2.6.25/drivers/video/geode/lxfb_ops.c
> +++ lxfb_clocks_added/drivers/video/geode/lxfb_ops.c
> @@ -34,35 +34,63 @@ static const struct {
>    unsigned int pllval;
>    unsigned int freq;
>  } pll_table[] = {
> -  { 0x000031AC, 24923 },
> -  { 0x0000215D, 25175 },
> -  { 0x00001087, 27000 },
> -  { 0x0000216C, 28322 },
> -  { 0x0000218D, 28560 },
> -  { 0x000010C9, 31200 },
> -  { 0x00003147, 31500 },
> -  { 0x000010A7, 33032 },
> -  { 0x00002159, 35112 },
> -  { 0x00004249, 35500 },
> -  { 0x00000057, 36000 },
> -  { 0x0000219A, 37889 },
> -  { 0x00002158, 39168 },
> -  { 0x00000045, 40000 },
> -  { 0x00000089, 43163 },
> -  { 0x000010E7, 44900 },
> -  { 0x00002136, 45720 },
> -  { 0x00003207, 49500 },
> -  { 0x00002187, 50000 },
> -  { 0x00004286, 56250 },
> -  { 0x000010E5, 60065 },
> -  { 0x00004214, 65000 },
> -  { 0x00001105, 68179 },
> -  { 0x000031E4, 74250 },
> -  { 0x00003183, 75000 },
> -  { 0x00004284, 78750 },
> -  { 0x00001104, 81600 },
> -  { 0x00006363, 94500 },
> -  { 0x00005303, 97520 },
> +  { 0x000131AC,   6231 },
> +  { 0x0001215D,   6294 },
> +  { 0x00011087,   6750 },
> +  { 0x0001216C,   7081 },
> +  { 0x0001218D,   7140 },
> +  { 0x000110C9,   7800 },
> +  { 0x00013147,   7875 },
> +  { 0x000110A7,   8258 },
> +  { 0x00012159,   8778 },
> +  { 0x00014249,   8875 },
> +  { 0x00010057,   9000 },
> +  { 0x0001219A,   9472 },
> +  { 0x00012158,   9792 },
> +  { 0x00010045,  10000 },
> +  { 0x00010089,  10791 },
> +  { 0x000110E7,  11225 },
> +  { 0x00012136,  11430 },
> +  { 0x00013207,  12375 },
> +  { 0x00012187,  12500 },
> +  { 0x00014286,  14063 },
> +  { 0x000110E5,  15016 },
> +  { 0x00014214,  16250 },
> +  { 0x00011105,  17045 },
> +  { 0x000131E4,  18563 },
> +  { 0x00013183,  18750 },
> +  { 0x00014284,  19688 },
> +  { 0x00011104,  20400 },
> +  { 0x00016363,  23625 },
> +  { 0x000031AC,  24923 },
> +  { 0x0000215D,  25175 },
> +  { 0x00001087,  27000 },
> +  { 0x0000216C,  28322 },
> +  { 0x0000218D,  28560 },
> +  { 0x000010C9,  31200 },
> +  { 0x00003147,  31500 },
> +  { 0x000010A7,  33032 },
> +  { 0x00002159,  35112 },
> +  { 0x00004249,  35500 },
> +  { 0x00000057,  36000 },
> +  { 0x0000219A,  37889 },
> +  { 0x00002158,  39168 },
> +  { 0x00000045,  40000 },
> +  { 0x00000089,  43163 },
> +  { 0x000010E7,  44900 },
> +  { 0x00002136,  45720 },
> +  { 0x00003207,  49500 },
> +  { 0x00002187,  50000 },
> +  { 0x00004286,  56250 },
> +  { 0x000010E5,  60065 },
> +  { 0x00004214,  65000 },
> +  { 0x00001105,  68179 },
> +  { 0x000031E4,  74250 },
> +  { 0x00003183,  75000 },
> +  { 0x00004284,  78750 },
> +  { 0x00001104,  81600 },
> +  { 0x00006363,  94500 },
> +  { 0x00005303,  97520 },
>    { 0x00002183, 100187 },
>    { 0x00002122, 101420 },
>    { 0x00001081, 108000 },
> @@ -137,7 +165,7 @@ static void lx_set_clock(struct fb_info
>  	unsigned int diff, min, best = 0;
>  	unsigned int freq, i;
> 
> -	freq = (unsigned int) (0x3b9aca00 / info->var.pixclock);
> +	freq = (unsigned int) (1000000000 / info->var.pixclock);
> 
>  	min = abs(pll_table[0].freq - freq);
> 
> @@ -149,7 +177,7 @@ static void lx_set_clock(struct fb_info
>  		}
>  	}
> 
> -	lx_set_dotpll(pll_table[best].pllval & 0x7FFF);
> +	lx_set_dotpll(pll_table[best].pllval & 0x00017FFF);
>  }
> 
>  static void lx_graphics_disable(struct fb_info *info)
> 

Re: lxfb driver regression

[Jordan Crouse]

On 08/05/08 15:56 +0200, Jens Rottmann wrote:
> Hi Andres,
> 
> > 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     
> 
> > 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 <JRottmann@LiPPERT-AT.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>

> ---
> 
> --- linux-2.6.25/drivers/video/geode/lxfb_ops.c
> +++ lxfb_clocks_added/drivers/video/geode/lxfb_ops.c
> @@ -34,35 +34,63 @@ static const struct {
>    unsigned int pllval;
>    unsigned int freq;
>  } pll_table[] = {
> -  { 0x000031AC, 24923 },
> -  { 0x0000215D, 25175 },
> -  { 0x00001087, 27000 },
> -  { 0x0000216C, 28322 },
> -  { 0x0000218D, 28560 },
> -  { 0x000010C9, 31200 },
> -  { 0x00003147, 31500 },
> -  { 0x000010A7, 33032 },
> -  { 0x00002159, 35112 },
> -  { 0x00004249, 35500 },
> -  { 0x00000057, 36000 },
> -  { 0x0000219A, 37889 },
> -  { 0x00002158, 39168 },
> -  { 0x00000045, 40000 },
> -  { 0x00000089, 43163 },
> -  { 0x000010E7, 44900 },
> -  { 0x00002136, 45720 },
> -  { 0x00003207, 49500 },
> -  { 0x00002187, 50000 },
> -  { 0x00004286, 56250 },
> -  { 0x000010E5, 60065 },
> -  { 0x00004214, 65000 },
> -  { 0x00001105, 68179 },
> -  { 0x000031E4, 74250 },
> -  { 0x00003183, 75000 },
> -  { 0x00004284, 78750 },
> -  { 0x00001104, 81600 },
> -  { 0x00006363, 94500 },
> -  { 0x00005303, 97520 },
> +  { 0x000131AC,   6231 },
> +  { 0x0001215D,   6294 },
> +  { 0x00011087,   6750 },
> +  { 0x0001216C,   7081 },
> +  { 0x0001218D,   7140 },
> +  { 0x000110C9,   7800 },
> +  { 0x00013147,   7875 },
> +  { 0x000110A7,   8258 },
> +  { 0x00012159,   8778 },
> +  { 0x00014249,   8875 },
> +  { 0x00010057,   9000 },
> +  { 0x0001219A,   9472 },
> +  { 0x00012158,   9792 },
> +  { 0x00010045,  10000 },
> +  { 0x00010089,  10791 },
> +  { 0x000110E7,  11225 },
> +  { 0x00012136,  11430 },
> +  { 0x00013207,  12375 },
> +  { 0x00012187,  12500 },
> +  { 0x00014286,  14063 },
> +  { 0x000110E5,  15016 },
> +  { 0x00014214,  16250 },
> +  { 0x00011105,  17045 },
> +  { 0x000131E4,  18563 },
> +  { 0x00013183,  18750 },
> +  { 0x00014284,  19688 },
> +  { 0x00011104,  20400 },
> +  { 0x00016363,  23625 },
> +  { 0x000031AC,  24923 },
> +  { 0x0000215D,  25175 },
> +  { 0x00001087,  27000 },
> +  { 0x0000216C,  28322 },
> +  { 0x0000218D,  28560 },
> +  { 0x000010C9,  31200 },
> +  { 0x00003147,  31500 },
> +  { 0x000010A7,  33032 },
> +  { 0x00002159,  35112 },
> +  { 0x00004249,  35500 },
> +  { 0x00000057,  36000 },
> +  { 0x0000219A,  37889 },
> +  { 0x00002158,  39168 },
> +  { 0x00000045,  40000 },
> +  { 0x00000089,  43163 },
> +  { 0x000010E7,  44900 },
> +  { 0x00002136,  45720 },
> +  { 0x00003207,  49500 },
> +  { 0x00002187,  50000 },
> +  { 0x00004286,  56250 },
> +  { 0x000010E5,  60065 },
> +  { 0x00004214,  65000 },
> +  { 0x00001105,  68179 },
> +  { 0x000031E4,  74250 },
> +  { 0x00003183,  75000 },
> +  { 0x00004284,  78750 },
> +  { 0x00001104,  81600 },
> +  { 0x00006363,  94500 },
> +  { 0x00005303,  97520 },
>    { 0x00002183, 100187 },
>    { 0x00002122, 101420 },
>    { 0x00001081, 108000 },
> @@ -137,7 +165,7 @@ static void lx_set_clock(struct fb_info
>  	unsigned int diff, min, best = 0;
>  	unsigned int freq, i;
> 
> -	freq = (unsigned int) (0x3b9aca00 / info->var.pixclock);
> +	freq = (unsigned int) (1000000000 / info->var.pixclock);
> 
>  	min = abs(pll_table[0].freq - freq);
> 
> @@ -149,7 +177,7 @@ static void lx_set_clock(struct fb_info
>  		}
>  	}
> 
> -	lx_set_dotpll(pll_table[best].pllval & 0x7FFF);
> +	lx_set_dotpll(pll_table[best].pllval & 0x00017FFF);
>  }
> 
>  static void lx_graphics_disable(struct fb_info *info)
> 
> 

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

Re: lxfb driver regression

[Jens Rottmann]

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

Re: lxfb driver regression

[Andres Salomon]

On Thu, 08 May 2008 15:56:36 +0200
Jens Rottmann <JRottmann@LiPPERT-AT.de> wrote:

> Hi Andres,
> 
[...]
> 
> 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?
> 

Sorry for the delay, I got around to testing this today.  It works
much better on an XO, so I've ack'd it.

Since updating to -rc2, I'm unable to reproduce the strange mode
setting differences; the original patch, reverting the original
patch, and also applying the new patch now all show:

[    1.005011] Console: switching to colour frame buffer device 150x56


> Thanks a lot for your help.
> 
> Regards,
> Jens Rottmann
> 
> =============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 <JRottmann@LiPPERT-AT.de>


Acked-by: Andres Salomon <dilinger@debian.org>


> ---
> 
> --- linux-2.6.25/drivers/video/geode/lxfb_ops.c
> +++ lxfb_clocks_added/drivers/video/geode/lxfb_ops.c
> @@ -34,35 +34,63 @@ static const struct {
>    unsigned int pllval;
>    unsigned int freq;
>  } pll_table[] = {
> -  { 0x000031AC, 24923 },
> -  { 0x0000215D, 25175 },
> -  { 0x00001087, 27000 },
> -  { 0x0000216C, 28322 },
> -  { 0x0000218D, 28560 },
> -  { 0x000010C9, 31200 },
> -  { 0x00003147, 31500 },
> -  { 0x000010A7, 33032 },
> -  { 0x00002159, 35112 },
> -  { 0x00004249, 35500 },
> -  { 0x00000057, 36000 },
> -  { 0x0000219A, 37889 },
> -  { 0x00002158, 39168 },
> -  { 0x00000045, 40000 },
> -  { 0x00000089, 43163 },
> -  { 0x000010E7, 44900 },
> -  { 0x00002136, 45720 },
> -  { 0x00003207, 49500 },
> -  { 0x00002187, 50000 },
> -  { 0x00004286, 56250 },
> -  { 0x000010E5, 60065 },
> -  { 0x00004214, 65000 },
> -  { 0x00001105, 68179 },
> -  { 0x000031E4, 74250 },
> -  { 0x00003183, 75000 },
> -  { 0x00004284, 78750 },
> -  { 0x00001104, 81600 },
> -  { 0x00006363, 94500 },
> -  { 0x00005303, 97520 },
> +  { 0x000131AC,   6231 },
> +  { 0x0001215D,   6294 },
> +  { 0x00011087,   6750 },
> +  { 0x0001216C,   7081 },
> +  { 0x0001218D,   7140 },
> +  { 0x000110C9,   7800 },
> +  { 0x00013147,   7875 },
> +  { 0x000110A7,   8258 },
> +  { 0x00012159,   8778 },
> +  { 0x00014249,   8875 },
> +  { 0x00010057,   9000 },
> +  { 0x0001219A,   9472 },
> +  { 0x00012158,   9792 },
> +  { 0x00010045,  10000 },
> +  { 0x00010089,  10791 },
> +  { 0x000110E7,  11225 },
> +  { 0x00012136,  11430 },
> +  { 0x00013207,  12375 },
> +  { 0x00012187,  12500 },
> +  { 0x00014286,  14063 },
> +  { 0x000110E5,  15016 },
> +  { 0x00014214,  16250 },
> +  { 0x00011105,  17045 },
> +  { 0x000131E4,  18563 },
> +  { 0x00013183,  18750 },
> +  { 0x00014284,  19688 },
> +  { 0x00011104,  20400 },
> +  { 0x00016363,  23625 },
> +  { 0x000031AC,  24923 },
> +  { 0x0000215D,  25175 },
> +  { 0x00001087,  27000 },
> +  { 0x0000216C,  28322 },
> +  { 0x0000218D,  28560 },
> +  { 0x000010C9,  31200 },
> +  { 0x00003147,  31500 },
> +  { 0x000010A7,  33032 },
> +  { 0x00002159,  35112 },
> +  { 0x00004249,  35500 },
> +  { 0x00000057,  36000 },
> +  { 0x0000219A,  37889 },
> +  { 0x00002158,  39168 },
> +  { 0x00000045,  40000 },
> +  { 0x00000089,  43163 },
> +  { 0x000010E7,  44900 },
> +  { 0x00002136,  45720 },
> +  { 0x00003207,  49500 },
> +  { 0x00002187,  50000 },
> +  { 0x00004286,  56250 },
> +  { 0x000010E5,  60065 },
> +  { 0x00004214,  65000 },
> +  { 0x00001105,  68179 },
> +  { 0x000031E4,  74250 },
> +  { 0x00003183,  75000 },
> +  { 0x00004284,  78750 },
> +  { 0x00001104,  81600 },
> +  { 0x00006363,  94500 },
> +  { 0x00005303,  97520 },
>    { 0x00002183, 100187 },
>    { 0x00002122, 101420 },
>    { 0x00001081, 108000 },
> @@ -137,7 +165,7 @@ static void lx_set_clock(struct fb_info
>  	unsigned int diff, min, best = 0;
>  	unsigned int freq, i;
> 
> -	freq = (unsigned int) (0x3b9aca00 / info->var.pixclock);
> +	freq = (unsigned int) (1000000000 / info->var.pixclock);
> 
>  	min = abs(pll_table[0].freq - freq);
> 
> @@ -149,7 +177,7 @@ static void lx_set_clock(struct fb_info
>  		}
>  	}
> 
> -	lx_set_dotpll(pll_table[best].pllval & 0x7FFF);
> +	lx_set_dotpll(pll_table[best].pllval & 0x00017FFF);
>  }
> 
>  static void lx_graphics_disable(struct fb_info *info)
> 

Re: lxfb driver regression

[Jens Rottmann]

I wrote:
> > Yes, of course that was my first idea, too. [...] But I'm
> > almost prepared to bet this is not the root of the evil.

Andres Salomon wrote:
> It works much better on an XO, so I've ack'd it.

Oops. Lucky I didn't bet, I'd have lost!
But it wasn't all fair, this strange fb resolution switch got me off track. ;-)


But it still surprises me that you get a white screen if you run the XO panel
with the specified frequency, and it only works as long as this is unavailable.
Are you sure the dotclock setting in olpc_dcon_modedb[] is correct?

Anyway, glad the problem is solved, now.

Again, many thanks for your help!
Jens

Re: lxfb driver regression

[Linus Torvalds]

On Mon, 12 May 2008, Andres Salomon wrote:
> 
> Sorry for the delay, I got around to testing this today.  It works
> much better on an XO, so I've ack'd it.

If people expect me to apply that patch, I hope they'll re-send (with acks 
etc). Otherwise I just expect I'll get it through the normal fbdev queues 
(which is often Andrew, but shouldn't be).

		Linus

Re: lxfb driver regression

[Andrew Morton]

On Tue, 13 May 2008 08:48:02 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Mon, 12 May 2008, Andres Salomon wrote:
> > 
> > Sorry for the delay, I got around to testing this today.  It works
> > much better on an XO, so I've ack'd it.
> 
> If people expect me to apply that patch, I hope they'll re-send (with acks 
> etc). Otherwise I just expect I'll get it through the normal fbdev queues 
> (which is often Andrew, but shouldn't be).
> 

It got confusing.  Turns out that I had a speculative revert patch,
followed by a new patch with an identical changelog to the first one.

I folded them together and below is what I presently have against
mainline, but I have no changelog describing what it fixes.

Can someone send some text please?

--- a/drivers/video/geode/lxfb_ops.c~fix-lxfb-extend-pll-table-to-support-dotclocks-below-25-mhz
+++ a/drivers/video/geode/lxfb_ops.c
@@ -63,54 +63,32 @@ static const struct {
   { 0x00014284,  19688 },
   { 0x00011104,  20400 },
   { 0x00016363,  23625 },
-  { 0x00015303,  24380 },
   { 0x000031AC,  24923 },
   { 0x0000215D,  25175 },
   { 0x00001087,  27000 },
   { 0x0000216C,  28322 },
   { 0x0000218D,  28560 },
-  { 0x00010041,  29913 },
   { 0x000010C9,  31200 },
   { 0x00003147,  31500 },
-  { 0x000141A1,  32400 },
   { 0x000010A7,  33032 },
-  { 0x00012182,  33375 },
-  { 0x000141B1,  33750 },
   { 0x00002159,  35112 },
   { 0x00004249,  35500 },
   { 0x00000057,  36000 },
-  { 0x000141E1,  37125 },
   { 0x0000219A,  37889 },
   { 0x00002158,  39168 },
   { 0x00000045,  40000 },
-  { 0x000131A1,  40500 },
-  { 0x00010061,  42301 },
   { 0x00000089,  43163 },
-  { 0x00012151,  43875 },
   { 0x000010E7,  44900 },
   { 0x00002136,  45720 },
-  { 0x000152E1,  47250 },
-  { 0x00010071,  48000 },
   { 0x00003207,  49500 },
   { 0x00002187,  50000 },
-  { 0x00014291,  50625 },
-  { 0x00011101,  51188 },
-  { 0x00017481,  54563 },
   { 0x00004286,  56250 },
-  { 0x00014170,  57375 },
-  { 0x00016210,  58500 },
   { 0x000010E5,  60065 },
-  { 0x00013140,  62796 },
   { 0x00004214,  65000 },
-  { 0x00016250,  65250 },
   { 0x00001105,  68179 },
-  { 0x000141C0,  69600 },
-  { 0x00015220,  70160 },
-  { 0x00010050,  72000 },
   { 0x000031E4,  74250 },
   { 0x00003183,  75000 },
   { 0x00004284,  78750 },
-  { 0x00012130,  80052 },
   { 0x00001104,  81600 },
   { 0x00006363,  94500 },
   { 0x00005303,  97520 },
_

Re: lxfb driver regression

[Andres Salomon]

On Tue, 13 May 2008 09:35:54 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Tue, 13 May 2008 08:48:02 -0700 (PDT) Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> 
> > 
> > 
> > On Mon, 12 May 2008, Andres Salomon wrote:
> > > 
> > > Sorry for the delay, I got around to testing this today.  It works
> > > much better on an XO, so I've ack'd it.
> > 
> > If people expect me to apply that patch, I hope they'll re-send
> > (with acks etc). Otherwise I just expect I'll get it through the
> > normal fbdev queues (which is often Andrew, but shouldn't be).
> > 
> 
> It got confusing.  Turns out that I had a speculative revert patch,
> followed by a new patch with an identical changelog to the first one.
> 
> I folded them together and below is what I presently have against
> mainline, but I have no changelog describing what it fixes.
> 
> Can someone send some text please?
> 

How's this?  Jordan and Jens, please correct me if I'm off.




[PATCH] lxfb: fix regression on OLPC caused by PLL table updates

The following patch caused a regression with OLPC panels:

 commit 3888d4639e78802c4ec1086127124e890461b9e4
    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 25
    MHz.  These are needed for small LCDs (e.g.  320x240).  Also inserts some
    intermediate steps between pre-existing frequencies.

The problem was the insertion of intermediate steps into the frequency
table; they would cause the wrong frequency to be matched.  This patch
drops those intermediate frequencies while keeping the sub-25MHz
frequencies.

Signed-off-by: Andres Salomon <dilinger@debian.org>


> ---
> a/drivers/video/geode/lxfb_ops.c~fix-lxfb-extend-pll-table-to-support-dotclocks-below-25-mhz
> +++ a/drivers/video/geode/lxfb_ops.c @@ -63,54 +63,32 @@ static const
> struct { { 0x00014284,  19688 },
>    { 0x00011104,  20400 },
>    { 0x00016363,  23625 },
> -  { 0x00015303,  24380 },
>    { 0x000031AC,  24923 },
>    { 0x0000215D,  25175 },
>    { 0x00001087,  27000 },
>    { 0x0000216C,  28322 },
>    { 0x0000218D,  28560 },
> -  { 0x00010041,  29913 },
>    { 0x000010C9,  31200 },
>    { 0x00003147,  31500 },
> -  { 0x000141A1,  32400 },
>    { 0x000010A7,  33032 },
> -  { 0x00012182,  33375 },
> -  { 0x000141B1,  33750 },
>    { 0x00002159,  35112 },
>    { 0x00004249,  35500 },
>    { 0x00000057,  36000 },
> -  { 0x000141E1,  37125 },
>    { 0x0000219A,  37889 },
>    { 0x00002158,  39168 },
>    { 0x00000045,  40000 },
> -  { 0x000131A1,  40500 },
> -  { 0x00010061,  42301 },
>    { 0x00000089,  43163 },
> -  { 0x00012151,  43875 },
>    { 0x000010E7,  44900 },
>    { 0x00002136,  45720 },
> -  { 0x000152E1,  47250 },
> -  { 0x00010071,  48000 },
>    { 0x00003207,  49500 },
>    { 0x00002187,  50000 },
> -  { 0x00014291,  50625 },
> -  { 0x00011101,  51188 },
> -  { 0x00017481,  54563 },
>    { 0x00004286,  56250 },
> -  { 0x00014170,  57375 },
> -  { 0x00016210,  58500 },
>    { 0x000010E5,  60065 },
> -  { 0x00013140,  62796 },
>    { 0x00004214,  65000 },
> -  { 0x00016250,  65250 },
>    { 0x00001105,  68179 },
> -  { 0x000141C0,  69600 },
> -  { 0x00015220,  70160 },
> -  { 0x00010050,  72000 },
>    { 0x000031E4,  74250 },
>    { 0x00003183,  75000 },
>    { 0x00004284,  78750 },
> -  { 0x00012130,  80052 },
>    { 0x00001104,  81600 },
>    { 0x00006363,  94500 },
>    { 0x00005303,  97520 },
> _
> 

Re: lxfb driver regression

[Andres Salomon]

On Tue, 13 May 2008 13:50:15 -0400
Andres Salomon <dilinger@queued.net> wrote:

> On Tue, 13 May 2008 09:35:54 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Tue, 13 May 2008 08:48:02 -0700 (PDT) Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > 
> > > 
> > > 
> > > On Mon, 12 May 2008, Andres Salomon wrote:
> > > > 
> > > > Sorry for the delay, I got around to testing this today.  It
> > > > works much better on an XO, so I've ack'd it.
> > > 
> > > If people expect me to apply that patch, I hope they'll re-send
> > > (with acks etc). Otherwise I just expect I'll get it through the
> > > normal fbdev queues (which is often Andrew, but shouldn't be).
> > > 
> > 
> > It got confusing.  Turns out that I had a speculative revert patch,
> > followed by a new patch with an identical changelog to the first
> > one.
> > 
> > I folded them together and below is what I presently have against
> > mainline, but I have no changelog describing what it fixes.
> > 
> > Can someone send some text please?
> > 
> 
> How's this?  Jordan and Jens, please correct me if I'm off.
> 
> 
> 

Oh, and of course:


From: Jens Rottmann <JRottmann@LiPPERT-AT.de>


> 
> [PATCH] lxfb: fix regression on OLPC caused by PLL table updates
> 
> The following patch caused a regression with OLPC panels:
> 
>  commit 3888d4639e78802c4ec1086127124e890461b9e4
>     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 25 MHz.  These are needed for small LCDs (e.g.
> 320x240).  Also inserts some intermediate steps between pre-existing
> frequencies.
> 
> The problem was the insertion of intermediate steps into the frequency
> table; they would cause the wrong frequency to be matched.  This patch
> drops those intermediate frequencies while keeping the sub-25MHz
> frequencies.
> 
> Signed-off-by: Andres Salomon <dilinger@debian.org>
> 
> 
> > ---
> > a/drivers/video/geode/lxfb_ops.c~fix-lxfb-extend-pll-table-to-support-dotclocks-below-25-mhz
> > +++ a/drivers/video/geode/lxfb_ops.c @@ -63,54 +63,32 @@ static
> > const struct { { 0x00014284,  19688 },
> >    { 0x00011104,  20400 },
> >    { 0x00016363,  23625 },
> > -  { 0x00015303,  24380 },
> >    { 0x000031AC,  24923 },
> >    { 0x0000215D,  25175 },
> >    { 0x00001087,  27000 },
> >    { 0x0000216C,  28322 },
> >    { 0x0000218D,  28560 },
> > -  { 0x00010041,  29913 },
> >    { 0x000010C9,  31200 },
> >    { 0x00003147,  31500 },
> > -  { 0x000141A1,  32400 },
> >    { 0x000010A7,  33032 },
> > -  { 0x00012182,  33375 },
> > -  { 0x000141B1,  33750 },
> >    { 0x00002159,  35112 },
> >    { 0x00004249,  35500 },
> >    { 0x00000057,  36000 },
> > -  { 0x000141E1,  37125 },
> >    { 0x0000219A,  37889 },
> >    { 0x00002158,  39168 },
> >    { 0x00000045,  40000 },
> > -  { 0x000131A1,  40500 },
> > -  { 0x00010061,  42301 },
> >    { 0x00000089,  43163 },
> > -  { 0x00012151,  43875 },
> >    { 0x000010E7,  44900 },
> >    { 0x00002136,  45720 },
> > -  { 0x000152E1,  47250 },
> > -  { 0x00010071,  48000 },
> >    { 0x00003207,  49500 },
> >    { 0x00002187,  50000 },
> > -  { 0x00014291,  50625 },
> > -  { 0x00011101,  51188 },
> > -  { 0x00017481,  54563 },
> >    { 0x00004286,  56250 },
> > -  { 0x00014170,  57375 },
> > -  { 0x00016210,  58500 },
> >    { 0x000010E5,  60065 },
> > -  { 0x00013140,  62796 },
> >    { 0x00004214,  65000 },
> > -  { 0x00016250,  65250 },
> >    { 0x00001105,  68179 },
> > -  { 0x000141C0,  69600 },
> > -  { 0x00015220,  70160 },
> > -  { 0x00010050,  72000 },
> >    { 0x000031E4,  74250 },
> >    { 0x00003183,  75000 },
> >    { 0x00004284,  78750 },
> > -  { 0x00012130,  80052 },
> >    { 0x00001104,  81600 },
> >    { 0x00006363,  94500 },
> >    { 0x00005303,  97520 },
> > _
> > 
> 
> _______________________________________________
> Linux-geode mailing list
> Linux-geode@bombadil.infradead.org
> http://bombadil.infradead.org/mailman/listinfo/linux-geode

Re: lxfb driver regression

[Jordan Crouse]

On 13/05/08 13:50 -0400, Andres Salomon wrote:
> On Tue, 13 May 2008 09:35:54 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Tue, 13 May 2008 08:48:02 -0700 (PDT) Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > 
> > > 
> > > 
> > > On Mon, 12 May 2008, Andres Salomon wrote:
> > > > 
> > > > Sorry for the delay, I got around to testing this today.  It works
> > > > much better on an XO, so I've ack'd it.
> > > 
> > > If people expect me to apply that patch, I hope they'll re-send
> > > (with acks etc). Otherwise I just expect I'll get it through the
> > > normal fbdev queues (which is often Andrew, but shouldn't be).
> > > 
> > 
> > It got confusing.  Turns out that I had a speculative revert patch,
> > followed by a new patch with an identical changelog to the first one.
> > 
> > I folded them together and below is what I presently have against
> > mainline, but I have no changelog describing what it fixes.
> > 
> > Can someone send some text please?
> > 
> 
> How's this?  Jordan and Jens, please correct me if I'm off.

Acked-by: Jordan Crouse <jordan.crouse@amd.com>

> [PATCH] lxfb: fix regression on OLPC caused by PLL table updates
> 
> The following patch caused a regression with OLPC panels:
> 
>  commit 3888d4639e78802c4ec1086127124e890461b9e4
>     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 25
>     MHz.  These are needed for small LCDs (e.g.  320x240).  Also inserts some
>     intermediate steps between pre-existing frequencies.
> 
> The problem was the insertion of intermediate steps into the frequency
> table; they would cause the wrong frequency to be matched.  This patch
> drops those intermediate frequencies while keeping the sub-25MHz
> frequencies.
> 
> Signed-off-by: Andres Salomon <dilinger@debian.org>
> 
> 
> > ---
> > a/drivers/video/geode/lxfb_ops.c~fix-lxfb-extend-pll-table-to-support-dotclocks-below-25-mhz
> > +++ a/drivers/video/geode/lxfb_ops.c @@ -63,54 +63,32 @@ static const
> > struct { { 0x00014284,  19688 },
> >    { 0x00011104,  20400 },
> >    { 0x00016363,  23625 },
> > -  { 0x00015303,  24380 },
> >    { 0x000031AC,  24923 },
> >    { 0x0000215D,  25175 },
> >    { 0x00001087,  27000 },
> >    { 0x0000216C,  28322 },
> >    { 0x0000218D,  28560 },
> > -  { 0x00010041,  29913 },
> >    { 0x000010C9,  31200 },
> >    { 0x00003147,  31500 },
> > -  { 0x000141A1,  32400 },
> >    { 0x000010A7,  33032 },
> > -  { 0x00012182,  33375 },
> > -  { 0x000141B1,  33750 },
> >    { 0x00002159,  35112 },
> >    { 0x00004249,  35500 },
> >    { 0x00000057,  36000 },
> > -  { 0x000141E1,  37125 },
> >    { 0x0000219A,  37889 },
> >    { 0x00002158,  39168 },
> >    { 0x00000045,  40000 },
> > -  { 0x000131A1,  40500 },
> > -  { 0x00010061,  42301 },
> >    { 0x00000089,  43163 },
> > -  { 0x00012151,  43875 },
> >    { 0x000010E7,  44900 },
> >    { 0x00002136,  45720 },
> > -  { 0x000152E1,  47250 },
> > -  { 0x00010071,  48000 },
> >    { 0x00003207,  49500 },
> >    { 0x00002187,  50000 },
> > -  { 0x00014291,  50625 },
> > -  { 0x00011101,  51188 },
> > -  { 0x00017481,  54563 },
> >    { 0x00004286,  56250 },
> > -  { 0x00014170,  57375 },
> > -  { 0x00016210,  58500 },
> >    { 0x000010E5,  60065 },
> > -  { 0x00013140,  62796 },
> >    { 0x00004214,  65000 },
> > -  { 0x00016250,  65250 },
> >    { 0x00001105,  68179 },
> > -  { 0x000141C0,  69600 },
> > -  { 0x00015220,  70160 },
> > -  { 0x00010050,  72000 },
> >    { 0x000031E4,  74250 },
> >    { 0x00003183,  75000 },
> >    { 0x00004284,  78750 },
> > -  { 0x00012130,  80052 },
> >    { 0x00001104,  81600 },
> >    { 0x00006363,  94500 },
> >    { 0x00005303,  97520 },
> > _
> > 
> 

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

Re: lxfb driver regression

[Jens Rottmann]

Andres Salomon wrote:
> How's this?  Jordan and Jens, please correct me if I'm off.

It's truly beautiful.

Summing up to avoid complaints.



[PATCH] lxfb: fix regression on OLPC caused by PLL table updates

The following patch caused a regression with OLPC panels:

 commit 3888d4639e78802c4ec1086127124e890461b9e4
    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 25
    MHz.  These are needed for small LCDs (e.g. 320x240).  Also inserts some
    intermediate steps between pre-existing frequencies.

The problem was the insertion of intermediate steps into the frequency
table; they would cause the wrong frequency to be matched.  This patch
drops those intermediate frequencies while keeping the sub-25MHz
frequencies.

Signed-off-by: Andres Salomon <dilinger@debian.org>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
Signed-off-by: Jens Rottmann <JRottmann@LiPPERT-AT.de>
---

--- a/drivers/video/geode/lxfb_ops.c~fix-lxfb-extend-pll-table-to-support-dotclocks-below-25-mhz
+++ a/drivers/video/geode/lxfb_ops.c
@@ -63,54 +63,32 @@ static const struct {
   { 0x00014284,  19688 },
   { 0x00011104,  20400 },
   { 0x00016363,  23625 },
-  { 0x00015303,  24380 },
   { 0x000031AC,  24923 },
   { 0x0000215D,  25175 },
   { 0x00001087,  27000 },
   { 0x0000216C,  28322 },
   { 0x0000218D,  28560 },
-  { 0x00010041,  29913 },
   { 0x000010C9,  31200 },
   { 0x00003147,  31500 },
-  { 0x000141A1,  32400 },
   { 0x000010A7,  33032 },
-  { 0x00012182,  33375 },
-  { 0x000141B1,  33750 },
   { 0x00002159,  35112 },
   { 0x00004249,  35500 },
   { 0x00000057,  36000 },
-  { 0x000141E1,  37125 },
   { 0x0000219A,  37889 },
   { 0x00002158,  39168 },
   { 0x00000045,  40000 },
-  { 0x000131A1,  40500 },
-  { 0x00010061,  42301 },
   { 0x00000089,  43163 },
-  { 0x00012151,  43875 },
   { 0x000010E7,  44900 },
   { 0x00002136,  45720 },
-  { 0x000152E1,  47250 },
-  { 0x00010071,  48000 },
   { 0x00003207,  49500 },
   { 0x00002187,  50000 },
-  { 0x00014291,  50625 },
-  { 0x00011101,  51188 },
-  { 0x00017481,  54563 },
   { 0x00004286,  56250 },
-  { 0x00014170,  57375 },
-  { 0x00016210,  58500 },
   { 0x000010E5,  60065 },
-  { 0x00013140,  62796 },
   { 0x00004214,  65000 },
-  { 0x00016250,  65250 },
   { 0x00001105,  68179 },
-  { 0x000141C0,  69600 },
-  { 0x00015220,  70160 },
-  { 0x00010050,  72000 },
   { 0x000031E4,  74250 },
   { 0x00003183,  75000 },
   { 0x00004284,  78750 },
-  { 0x00012130,  80052 },
   { 0x00001104,  81600 },
   { 0x00006363,  94500 },
   { 0x00005303,  97520 },