OK, I know what happened on this one.  Since I'm running an initrd'd uImage, I'm using
two separate build areas, one for the uImage-initrd and the other for the throw-away
uImage but functional modules (plus rest of user-space system).  I do this simply
because it's way too painful to use one area for two different configuration set-ups.
Gumstix.o is included in the kernel/uImage, so the pxafb.ko module I'm using is
picking up the mode list structures from the uImage-initrd (which had the Samsung
configuration with nonstd=24).  Hence, any modifications I do in gumstix.c in the
main (non-initrd) build area, where I put in a Sony configuration, is not going to
get used.  A module depending on some configuration items pre-built into the
kernel defeats the notion of independent modules (especially when the kernel
comes from some other configuration, such as an initrd'd one).  A module should
really only pick up options via the modprobe command line or modprobe.conf,
and these options should not be tainted by old, irrelevant, configuration items
in the kernel.

The fix to set nonstd to 0 in pxafb.c cleans up this problem.  There may be
others similar issues.

On 9/5/07, Craig Hughes <craig@gumstix.com> wrote:
On Sep 5, 2007, at 11:05 AM, Peter Lu wrote:

   case 8:
   case 16:
        inf->modes[0].bpp = bpp;
        inf->modes[0].nonstd = 0; // standard bpp

I'm not sure where it's getting set to something other than 0 either, but it's prudent to set nonstd=0 there.  I've also added an if() there to make sure you didn't specify /xyz and to error out if you did for those bpps.  subversion r1518


This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>   http://get.splunk.com/
gumstix-users mailing list