From jordan.crouse at amd.com  Wed May  7 12:18:33 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Wed, 7 May 2008 10:18:33 -0600
Subject: [PATCH] Update Geode mailing list in MAINTAINERS
Message-ID: <20080507161833.GA1217@cosmic.amd.com>

The AMD Geode linux list has a new home (thank goodness).  This 
patch updates MAINTAINERS accordingly.

Jordan
-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-maintainers.patch
Type: text/x-diff
Size: 972 bytes
Desc: not available
Url : http://bombadil.infradead.org/pipermail/linux-geode/attachments/20080507/1f484e1c/attachment.bin 

From dilinger at queued.net  Wed May  7 21:08:36 2008
From: dilinger at queued.net (Andres Salomon)
Date: Wed, 7 May 2008 21:08:36 -0400
Subject: lxfb driver regression
Message-ID: <20080507210836.1eb61b8f@ephemeral>

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          



From akpm at linux-foundation.org  Wed May  7 21:11:40 2008
From: akpm at linux-foundation.org (Andrew Morton)
Date: Wed, 7 May 2008 18:11:40 -0700
Subject: lxfb driver regression
In-Reply-To: <20080507210836.1eb61b8f@ephemeral>
References: <20080507210836.1eb61b8f@ephemeral>
Message-ID: <20080507181140.ecea2305.akpm@linux-foundation.org>

On Wed, 7 May 2008 21:08:36 -0400 Andres Salomon <dilinger at 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.



From JRottmann at LiPPERT-AT.de  Thu May  8 09:56:36 2008
From: JRottmann at LiPPERT-AT.de (Jens Rottmann)
Date: Thu, 08 May 2008 15:56:36 +0200
Subject: lxfb driver regression
In-Reply-To: <20080507210836.1eb61b8f@ephemeral>
References: <20080507210836.1eb61b8f@ephemeral>
Message-ID: <48230694.5010505@LiPPERT-AT.de>

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 at 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)



From dilinger at queued.net  Thu May  8 10:48:08 2008
From: dilinger at queued.net (Andres Salomon)
Date: Thu, 8 May 2008 10:48:08 -0400
Subject: lxfb driver regression
In-Reply-To: <48230694.5010505@LiPPERT-AT.de>
References: <20080507210836.1eb61b8f@ephemeral>
	<48230694.5010505@LiPPERT-AT.de>
Message-ID: <20080508104808.77f48f41@ephemeral>

On Thu, 08 May 2008 15:56:36 +0200
Jens Rottmann <JRottmann at 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 at 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)
> 


From jordan.crouse at amd.com  Thu May  8 11:06:53 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 8 May 2008 09:06:53 -0600
Subject: lxfb driver regression
In-Reply-To: <48230694.5010505@LiPPERT-AT.de>
References: <20080507210836.1eb61b8f@ephemeral>
	<48230694.5010505@LiPPERT-AT.de>
Message-ID: <20080508150653.GA18117@cosmic.amd.com>

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 at LiPPERT-AT.de>
Acked-by: Jordan Crouse <jordan.crouse at 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.



From JRottmann at LiPPERT-AT.de  Fri May  9 06:33:32 2008
From: JRottmann at LiPPERT-AT.de (Jens Rottmann)
Date: Fri, 09 May 2008 12:33:32 +0200
Subject: lxfb driver regression
In-Reply-To: <20080508104808.77f48f41@ephemeral>
References: <20080507210836.1eb61b8f@ephemeral>	<48230694.5010505@LiPPERT-AT.de>
	<20080508104808.77f48f41@ephemeral>
Message-ID: <4824287C.4050300@LiPPERT-AT.de>

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


From dilinger at queued.net  Mon May 12 18:51:48 2008
From: dilinger at queued.net (Andres Salomon)
Date: Mon, 12 May 2008 18:51:48 -0400
Subject: lxfb driver regression
In-Reply-To: <48230694.5010505@LiPPERT-AT.de>
References: <20080507210836.1eb61b8f@ephemeral>
	<48230694.5010505@LiPPERT-AT.de>
Message-ID: <20080512185148.104fc4c3@ephemeral>

On Thu, 08 May 2008 15:56:36 +0200
Jens Rottmann <JRottmann at 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 at LiPPERT-AT.de>


Acked-by: Andres Salomon <dilinger at 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)
> 


From JRottmann at LiPPERT-AT.de  Tue May 13 06:29:23 2008
From: JRottmann at LiPPERT-AT.de (Jens Rottmann)
Date: Tue, 13 May 2008 12:29:23 +0200
Subject: lxfb driver regression
In-Reply-To: <20080512185148.104fc4c3@ephemeral>
References: <20080507210836.1eb61b8f@ephemeral>	<48230694.5010505@LiPPERT-AT.de>
	<20080512185148.104fc4c3@ephemeral>
Message-ID: <48296D83.3020007@LiPPERT-AT.de>

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


From torvalds at linux-foundation.org  Tue May 13 11:48:02 2008
From: torvalds at linux-foundation.org (Linus Torvalds)
Date: Tue, 13 May 2008 08:48:02 -0700 (PDT)
Subject: lxfb driver regression
In-Reply-To: <20080512185148.104fc4c3@ephemeral>
References: <20080507210836.1eb61b8f@ephemeral>
	<48230694.5010505@LiPPERT-AT.de>
	<20080512185148.104fc4c3@ephemeral>
Message-ID: <alpine.LFD.1.10.0805130847150.3019@woody.linux-foundation.org>



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


From akpm at linux-foundation.org  Tue May 13 12:35:54 2008
From: akpm at linux-foundation.org (Andrew Morton)
Date: Tue, 13 May 2008 09:35:54 -0700
Subject: lxfb driver regression
In-Reply-To: <alpine.LFD.1.10.0805130847150.3019@woody.linux-foundation.org>
References: <20080507210836.1eb61b8f@ephemeral>
	<48230694.5010505@LiPPERT-AT.de>
	<20080512185148.104fc4c3@ephemeral>
	<alpine.LFD.1.10.0805130847150.3019@woody.linux-foundation.org>
Message-ID: <20080513093554.64466981.akpm@linux-foundation.org>

On Tue, 13 May 2008 08:48:02 -0700 (PDT) Linus Torvalds <torvalds at 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 },
_



From dilinger at queued.net  Tue May 13 13:50:15 2008
From: dilinger at queued.net (Andres Salomon)
Date: Tue, 13 May 2008 13:50:15 -0400
Subject: lxfb driver regression
In-Reply-To: <20080513093554.64466981.akpm@linux-foundation.org>
References: <20080507210836.1eb61b8f@ephemeral>
	<48230694.5010505@LiPPERT-AT.de>
	<20080512185148.104fc4c3@ephemeral>
	<alpine.LFD.1.10.0805130847150.3019@woody.linux-foundation.org>
	<20080513093554.64466981.akpm@linux-foundation.org>
Message-ID: <20080513135015.4452fb8f@ephemeral>

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

> On Tue, 13 May 2008 08:48:02 -0700 (PDT) Linus Torvalds
> <torvalds at 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 at 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 },
> _
> 


From dilinger at queued.net  Tue May 13 13:55:01 2008
From: dilinger at queued.net (Andres Salomon)
Date: Tue, 13 May 2008 13:55:01 -0400
Subject: lxfb driver regression
In-Reply-To: <20080513135015.4452fb8f@ephemeral>
References: <20080507210836.1eb61b8f@ephemeral>
	<48230694.5010505@LiPPERT-AT.de>
	<20080512185148.104fc4c3@ephemeral>
	<alpine.LFD.1.10.0805130847150.3019@woody.linux-foundation.org>
	<20080513093554.64466981.akpm@linux-foundation.org>
	<20080513135015.4452fb8f@ephemeral>
Message-ID: <20080513135501.5c9b4650@ephemeral>

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

> On Tue, 13 May 2008 09:35:54 -0700
> Andrew Morton <akpm at linux-foundation.org> wrote:
> 
> > On Tue, 13 May 2008 08:48:02 -0700 (PDT) Linus Torvalds
> > <torvalds at 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 at 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 at 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 at bombadil.infradead.org
> http://bombadil.infradead.org/mailman/listinfo/linux-geode


From jordan.crouse at amd.com  Tue May 13 16:05:58 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Tue, 13 May 2008 14:05:58 -0600
Subject: lxfb driver regression
In-Reply-To: <20080513135015.4452fb8f@ephemeral>
References: <20080507210836.1eb61b8f@ephemeral>
	<48230694.5010505@LiPPERT-AT.de>
	<20080512185148.104fc4c3@ephemeral>
	<alpine.LFD.1.10.0805130847150.3019@woody.linux-foundation.org>
	<20080513093554.64466981.akpm@linux-foundation.org>
	<20080513135015.4452fb8f@ephemeral>
Message-ID: <20080513200558.GK28172@cosmic.amd.com>

On 13/05/08 13:50 -0400, Andres Salomon wrote:
> On Tue, 13 May 2008 09:35:54 -0700
> Andrew Morton <akpm at linux-foundation.org> wrote:
> 
> > On Tue, 13 May 2008 08:48:02 -0700 (PDT) Linus Torvalds
> > <torvalds at 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 at 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 at 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.



From JRottmann at LiPPERT-AT.de  Wed May 14 08:44:40 2008
From: JRottmann at LiPPERT-AT.de (Jens Rottmann)
Date: Wed, 14 May 2008 14:44:40 +0200
Subject: lxfb driver regression
In-Reply-To: <20080513135015.4452fb8f@ephemeral>
References: <20080507210836.1eb61b8f@ephemeral>	<48230694.5010505@LiPPERT-AT.de>	<20080512185148.104fc4c3@ephemeral>	<alpine.LFD.1.10.0805130847150.3019@woody.linux-foundation.org>	<20080513093554.64466981.akpm@linux-foundation.org>
	<20080513135015.4452fb8f@ephemeral>
Message-ID: <482ADEB8.4030103@LiPPERT-AT.de>

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 at debian.org>
Acked-by: Jordan Crouse <jordan.crouse at amd.com>
Signed-off-by: Jens Rottmann <JRottmann at 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 },



From ConiKost at gmx.de  Thu May 15 03:25:23 2008
From: ConiKost at gmx.de (ConiKost at gmx.de)
Date: Thu, 15 May 2008 09:25:23 +0200
Subject: Patch for Supporting FBSplash?
Message-ID: <20080515072523.189450@gmx.net>

Hello!
I am using here under gentoo uvesafb, so get a nice fbsplash during booting. But i noticed, that this only works with uvesafb. I can't use lxfb. It this normal? (lxfb only loads an framebuffer, but the fbsplash it not getting loadad) I am asking, because lxfb seems a little bit faster for me.

Conrad


From jordan.crouse at amd.com  Thu May 15 10:25:34 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Thu, 15 May 2008 08:25:34 -0600
Subject: Patch for Supporting FBSplash?
In-Reply-To: <20080515072523.189450@gmx.net>
References: <20080515072523.189450@gmx.net>
Message-ID: <20080515142534.GA31775@cosmic.amd.com>

On 15/05/08 09:25 +0200, ConiKost at gmx.de wrote:
> Hello!
> I am using here under gentoo uvesafb, so get a nice fbsplash during booting. But i noticed, that this only works with uvesafb. I can't use lxfb. It this normal? (lxfb only loads an framebuffer, but the fbsplash it not getting loadad) I am asking, because lxfb seems a little bit faster for me.

You would probably need to change both gentoo and fbsplash to get it to work
with something other the the VESA framebuffer driver, but I wouldn't worry
about it - unless you are using a non VESA resolution (which you obviously
are not), then there is no advantage to using lxfb.

Jordan

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



From reynaldo at opendot.cl  Thu May 15 15:23:10 2008
From: reynaldo at opendot.cl (Reynaldo H. Verdejo Pinochet)
Date: Thu, 15 May 2008 15:23:10 -0400
Subject: Blank screen but session seems to start otherwise normally
Message-ID: <482C8D9E.40502@opendot.cl>

Hey list

I know this post is going to violate several conventions
on how to get help, first, I need to solve this issue
(if at all possible) with an ubuntu packaged version of
the driver. Thats why I'm not trying with a more current
snapshot of the driver.

The problem I'm facing is the one outlined in the subject.
I 'hear' the session start, the greeting sound* is kind of
distorted but i hear it nonetheless (using startx, I know
the sound problem is in other lands) but the screen reminds
blank.

This is on a locally branded umpc that seems to be a painted-black
(literaly) version of some 'airis kira 1070' and/or 'kojinsha SA1F00A'.

*I have set the videomen to be 64M on the bios setup utility

Here is the my latest try out for a config:
	http://pastebin.ca/1019303

And here is the log the xorg server spites:
	http://pastebin.ca/1019296

Hope you can five me a hand, Im basically looking for a list
of options I might need to try out.

Bests
--
Reynaldo


From reynaldo at opendot.cl  Thu May 15 23:19:57 2008
From: reynaldo at opendot.cl (Reynaldo H. Verdejo Pinochet)
Date: Thu, 15 May 2008 23:19:57 -0400
Subject: Blank screen but session seems to start otherwise normally
In-Reply-To: <482C8D9E.40502@opendot.cl>
References: <482C8D9E.40502@opendot.cl>
Message-ID: <482CFD5D.40405@opendot.cl>

Hey list, not wantig to leave this unanswered I figured out
I'd post here the solution Jordan Crouse come up with while
helping me on IRC.

Reynaldo H. Verdejo Pinochet wrote:
> The problem I'm facing is the one outlined in the subject.
> I 'hear' the session start, the greeting sound* is kind of
> distorted but i hear it nonetheless (using startx, I know
> the sound problem is in other lands) but the screen reminds
> blank.

OK. First, the laptop/UMPC is LX800 based and is branded in any of
the following ways:

- Packard Bell S18P
- Airis Kira
- kohjinsha SA1F00A

And while I know this might be not _directly_ related to the list
I'm almost sure there must be some desesperate souls seeking  for
the info ;)

The problem is then, the lack of harcoded modelines for this
display's native resolution, that is 800x480 (When using this
laptop with windows the modelines are probably stored in the
bios or in the windows driver itself). You will find  a completely
working (as of today ubuntu hardy's versions of the software
involved) xorg.conf config attached here.

Mind you can make it work with vesa at 640x480 at 60Hz without this
changes but the result is faAr from perfect.

I mean it. UGLY. ;)

Bests
--
Reynaldo H. Verdejo Pinochet
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xorg.conf
Url: http://bombadil.infradead.org/pipermail/linux-geode/attachments/20080515/c392a450/attachment.pl 

From kganesan at handylab.com  Fri May 16 13:03:30 2008
From: kganesan at handylab.com (Karthik Ganesan)
Date: Fri, 16 May 2008 13:03:30 -0400
Subject: FC 8/9 IDE problems on Ampro LX800 board...
Message-ID: <1210957410.30650.32.camel@localhost.localdomain>

Hello,
I tried to install Fedora Core 8 and Fedora Core 9 (linux 2.6.23/2.6.24)
and am having IDE problems. I am installing on an Ampro ETX board
(ETX610) which has the secondary IDE channel brought out to two compact
flash slots: one on the ETX board itself and the other one on the base
board. The primary IDE channel is brought out to a standard IDE header
on the baseboard and I have a DVD drive plugged in here.

This ETX board has the Geode LX800 w/ CS5536 chipset.

Perusing the boot messages while installing, I find that libata is using
pata_amd to configure the IDE and is reporting that ata2 (secondary
channel) is disabled! I cannot access either compact flash drive.

      * Should it be using pata_cs5536?
      * Any clues to diagnosing this problem? Does libata parse any
        kernel arguments that I can set to find out more?

Fedora Core 6 (2.6.19) functions very well on this board.

Thanks,
-karthik





From mart.raudsepp at artecdesign.ee  Mon May 19 04:49:13 2008
From: mart.raudsepp at artecdesign.ee (Mart Raudsepp)
Date: Mon, 19 May 2008 11:49:13 +0300 (EEST)
Subject: FC 8/9 IDE problems on Ampro LX800 board...
Message-ID: <53005.10.2.10.133.1211186953.squirrel@www.artecdesign.ee>

Hello,

> This ETX board has the Geode LX800 w/ CS5536 chipset.
>
> Perusing the boot messages while installing, I find that libata is using
> pata_amd to configure the IDE and is reporting that ata2 (secondary
> channel) is disabled! I cannot access either compact flash drive.

What is the kernel message exactly? Does it say "ata2: Disabled by BIOS",
or what is the exact message line from kernel log? That would help locate
the exact check in the code that makes it disabled

>       * Should it be using pata_cs5536?
>       * Any clues to diagnosing this problem? Does libata parse any
>         kernel arguments that I can set to find out more?

Among other things it checks if the channel has been enabled by
firmware/BIOS, by reading the appropriate MSR register. If that is not set
up for the given ata channel, it will not use it.

Regards,
Mart Raudsepp



From ciVic at web.de  Mon May 19 15:58:51 2008
From: ciVic at web.de (Oliver Urbann)
Date: Mon, 19 May 2008 21:58:51 +0200
Subject: Bug in lxv4l2?
Message-ID: <D4E567B752544FEBB0698F42E907942D@ciVicBook>

Hi,

i am using an AMD Geode with a cam (with v4l driver). In some cases the
kernel shows the following when i am reading from /dev/video0:

------------[ cut here ]------------
kernel BUG at kernel/rtmutex.c:682!
invalid opcode: 0000 [#1]
PREEMPT
Modules linked in: lxv4l2 i2c_serial zd1211rw
CPU:    0
EIP:    0060:[<c0344c23>]    Not tainted VLI
EFLAGS: 00010046   (2.6.22.9-aldebaran-rt #1)
EIP is at rt_spin_lock_slowlock+0x5e/0x176
eax: ceb92bf0   ebx: 00000282   ecx: c13d8414   edx: ceb92bf0
esi: c13d8404   edi: c13d8404   ebp: ce06001c   esp: ca467e80
ds: 007b   es: 007b   fs: 0000  gs: 0033  ss: 0068  preempt:00000002
Process naoqi (pid: 2992, ti=ca466000 task=ceb92bf0 task.ti=ca466000)
Stack: 00000086 307f4268 00000026 00000046 c0403998 ceb92bf0 307f4268
00000026
       ffffffff ca466000 ceb92bf0 ca467ec0 c034462d 00000000 d03d547c
ce06001c
       c13d8400 c13d8404 ce06001c d08d9f39 d0342000 d03d547c 086261bc
d0342000
Call Trace:
 [<c034462d>] preempt_schedule_irq+0x3b/0x53
 [<d08d9f39>] v4l_capt_unstall+0x15/0x81 [lxv4l2]
 [<d08da00b>] v4l_qbfr+0x66/0x75 [lxv4l2]
 [<d08daad7>] v4l_stream_copy+0x279/0x2b4 [lxv4l2]
 [<d08dc7bd>] vid_read+0x130/0x13c [lxv4l2]
 [<d08dc68d>] vid_read+0x0/0x13c [lxv4l2]
 [<c01588f2>] vfs_read+0x88/0x110
 [<c0158c33>] sys_read+0x41/0x67
 [<c0103d1a>] syscall_call+0x7/0xb
 =======================
Code: f0 e8 8a 08 df ff 85 c0 74 11 53 9d 89 e0 25 00 e0 ff ff ff 48 14 e9
14 01 00 00 8b 15 00 f0 3f c0 8b 46 10 83 e0 fc 39 d0 75 04 <0f> 0b eb fe b8
04 00 00 00 87 02 89 44 24 04 89 e5 81 e5 00 e0
EIP: [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176 SS:ESP 0068:ca467e80
note: naoqi[2992] exited with preempt_count 1
BUG: scheduling while atomic: naoqi/0x00000002/2992, CPU#0
 [<c0343ec0>] __schedule+0x85/0x383
 [<c012ef0b>] hrtimer_interrupt+0x16e/0x196
 [<c034442a>] schedule+0xe5/0xfb
 [<c0344f37>] rt_mutex_slowlock+0x193/0x237
 [<c0344bc2>] rt_mutex_lock+0x2b/0x2e
 [<c01342dd>] futex_wake+0x22/0xc2
 [<c0130000>] timekeeping_resume+0x30/0xc2
 [<c01343fe>] do_futex+0x81/0x9d3
 [<c02563ab>] serial8250_console_putchar+0x33/0x76
 [<c0251c9e>] uart_console_write+0x29/0x33
 [<c0256378>] serial8250_console_putchar+0x0/0x76
 [<c011da98>] release_console_sem+0x180/0x1b0
 [<c0134e35>] sys_futex+0xe5/0xf7
 [<c010609a>] do_IRQ+0x67/0x7d
 [<c011b96e>] mm_release+0x81/0x87
 [<c011ea46>] exit_mm+0x12/0xd3
 [<c011fec1>] do_exit+0x1ba/0x722
 [<c01050a5>] die+0x1d3/0x1db
 [<c010542a>] do_invalid_op+0x0/0x8a
 [<c01054ab>] do_invalid_op+0x81/0x8a
 [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176
 [<c0108ee7>] pit_next_event+0x2f/0x34
 [<c0131f96>] clockevents_program_event+0xb5/0xbc
 [<c0132cf6>] tick_program_event+0x2a/0x49
 [<c0119251>] update_curr+0x235/0x256
 [<c0345612>] error_code+0x6a/0x70
 [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176
 [<c034462d>] preempt_schedule_irq+0x3b/0x53
 [<d08d9f39>] v4l_capt_unstall+0x15/0x81 [lxv4l2]
 [<d08da00b>] v4l_qbfr+0x66/0x75 [lxv4l2]
 [<d08daad7>] v4l_stream_copy+0x279/0x2b4 [lxv4l2]
 [<d08dc7bd>] vid_read+0x130/0x13c [lxv4l2]
 [<d08dc68d>] vid_read+0x0/0x13c [lxv4l2]
 [<c01588f2>] vfs_read+0x88/0x110
 [<c0158c33>] sys_read+0x41/0x67
 [<c0103d1a>] syscall_call+0x7/0xb
 =======================
BUG: scheduling while atomic: naoqi/0x00000002/2992, CPU#0
 [<c0343ec0>] __schedule+0x85/0x383
 [<c034442a>] schedule+0xe5/0xfb
 [<c0344f37>] rt_mutex_slowlock+0x193/0x237
 [<c0344bc2>] rt_mutex_lock+0x2b/0x2e
 [<c011ea58>] exit_mm+0x24/0xd3
 [<c011fec1>] do_exit+0x1ba/0x722
 [<c01050a5>] die+0x1d3/0x1db
 [<c010542a>] do_invalid_op+0x0/0x8a
 [<c01054ab>] do_invalid_op+0x81/0x8a
 [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176
 [<c0108ee7>] pit_next_event+0x2f/0x34
 [<c0131f96>] clockevents_program_event+0xb5/0xbc
 [<c0132cf6>] tick_program_event+0x2a/0x49
 [<c0119251>] update_curr+0x235/0x256
 [<c0345612>] error_code+0x6a/0x70
 [<c0344c23>] rt_spin_lock_slowlock+0x5e/0x176
 [<c034462d>] preempt_schedule_irq+0x3b/0x53
 [<d08d9f39>] v4l_capt_unstall+0x15/0x81 [lxv4l2]
 [<d08da00b>] v4l_qbfr+0x66/0x75 [lxv4l2]
 [<d08daad7>] v4l_stream_copy+0x279/0x2b4 [lxv4l2]
 [<d08dc7bd>] vid_read+0x130/0x13c [lxv4l2]
 [<d08dc68d>] vid_read+0x0/0x13c [lxv4l2]
 [<c01588f2>] vfs_read+0x88/0x110
 [<c0158c33>] sys_read+0x41/0x67
 [<c0103d1a>] syscall_call+0x7/0xb
 =======================


On the call stack i found the function v4l_capt_unstall() just before
preempt_schedule_irq and so i took a look into the lxv4l2 driver. I
found the following function, which calls v4l_capt_unstall(), in v4l.c:

int v4l_qbfr(VidDevice *dp,struct list_head *lp,io_buf *bp,int capt)
{
   unsigned long flags;
   FilePriv *fp = &dp->fp;
   io_queue *io = fp->io;
   spin_lock_irqsave(&io->lock, flags);
   list_move_tail(&bp->bfrq,lp);
   bp->sequence = io->sequence++;
   bp->flags &= ~V4L2_BUF_FLAG_DONE;
   bp->flags |= V4L2_BUF_FLAG_QUEUED;
   if( capt != 0 && dp->capt_stalled != 0 )
      v4l_capt_unstall(dp);
   spin_unlock_irqrestore(&io->lock, flags);
}


And here is v4l_capt_unstall():

int v4l_capt_unstall(VidDevice *dp)
{
   unsigned long flags;
   int ret = 0;
   FilePriv *fp = &dp->fp;
   io_queue *io = fp->io;
   spin_lock_irqsave(&io->lock, flags);
   if( dp->capt_state == capt_state_run ) {
      if( io != NULL ) {
         if( dp->capt_stalled != 0 )
            DMSG(4,"capt resumed\n");
         ret = lx_capt_resume(dp,io);
      }
   }
   spin_unlock_irqrestore(&io->lock, flags);
   return ret;
}

I was wondering about the spin lock. The function v4l_capt_unstall() already
locks io->lock, calls v4l_capt_unstall() and there again it tries to lock
io->lock. I think this should end in a deadlock?

Oliver Urbann
 



From dilinger at queued.net  Mon May 19 16:29:31 2008
From: dilinger at queued.net (Andres Salomon)
Date: Mon, 19 May 2008 16:29:31 -0400
Subject: Bug in lxv4l2?
In-Reply-To: <D4E567B752544FEBB0698F42E907942D@ciVicBook>
References: <D4E567B752544FEBB0698F42E907942D@ciVicBook>
Message-ID: <20080519162931.6223b2b9@ephemeral>

On Mon, 19 May 2008 21:58:51 +0200
"Oliver Urbann" <ciVic at web.de> wrote:

> Hi,
> 
> i am using an AMD Geode with a cam (with v4l driver). In some cases
> the kernel shows the following when i am reading from /dev/video0:
> 
[...]
> 
> I was wondering about the spin lock. The function v4l_capt_unstall()
> already locks io->lock, calls v4l_capt_unstall() and there again it
> tries to lock io->lock. I think this should end in a deadlock?
> 
> Oliver Urbann


Erm, where is this code from?  It doesn't appear to be in the
mainline kernel...


From ciVic at web.de  Mon May 19 16:36:16 2008
From: ciVic at web.de (Oliver Urbann)
Date: Mon, 19 May 2008 22:36:16 +0200
Subject: Bug in lxv4l2?
References: <D4E567B752544FEBB0698F42E907942D@ciVicBook>
	<20080519162931.6223b2b9@ephemeral>
Message-ID: <36E6392DF3B84E40A7FB08EFA278D318@ciVicBook>



--------------------------------------------------
From: "Andres Salomon" <dilinger at queued.net>
Sent: Monday, May 19, 2008 10:29 PM
To: "Oliver Urbann" <ciVic at web.de>
Cc: <linux-geode at bombadil.infradead.org>
Subject: Re: Bug in lxv4l2?

> On Mon, 19 May 2008 21:58:51 +0200
> "Oliver Urbann" <ciVic at web.de> wrote:
>
>> I was wondering about the spin lock. The function v4l_capt_unstall()
>> already locks io->lock, calls v4l_capt_unstall() and there again it
>> tries to lock io->lock. I think this should end in a deadlock?
>>
>> Oliver Urbann
>
>
> Erm, where is this code from?  It doesn't appear to be in the
> mainline kernel...
>

I found them in the lxv4l2 driver (file v4l.c):

http://www.amd.com/files/connectivitysolutions/geode/geode_lx/04_-_Graphics_Video4Linux2_03.02.0100.tar.gz

Oliver Urbann 



From jordan.crouse at amd.com  Mon May 19 16:39:32 2008
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 19 May 2008 14:39:32 -0600
Subject: Bug in lxv4l2?
In-Reply-To: <20080519162931.6223b2b9@ephemeral>
References: <D4E567B752544FEBB0698F42E907942D@ciVicBook>
	<20080519162931.6223b2b9@ephemeral>
Message-ID: <20080519203932.GA10818@cosmic.amd.com>

On 19/05/08 16:29 -0400, Andres Salomon wrote:
> On Mon, 19 May 2008 21:58:51 +0200
> "Oliver Urbann" <ciVic at web.de> wrote:
> 
> > Hi,
> > 
> > i am using an AMD Geode with a cam (with v4l driver). In some cases
> > the kernel shows the following when i am reading from /dev/video0:
> > 
> [...]
> > 
> > I was wondering about the spin lock. The function v4l_capt_unstall()
> > already locks io->lock, calls v4l_capt_unstall() and there again it
> > tries to lock io->lock. I think this should end in a deadlock?
> > 
> > Oliver Urbann
> 
> 
> Erm, where is this code from?  It doesn't appear to be in the
> mainline kernel...

Its not - this is the last of the LX drivers that needs to be ported
to mainline.  

Jordan