Debugging pxafb and am200epd

Hi Eric,

Just some quick questions and notes while trying to implement am200epd
sharing pxafb's framebuffer.

1. pxafb_init is set to __devinit, but it is only called from
module_init. Is my understanding correct that it should be __init?
2. pxafb currently doesn't implement module unloading support.  Is
there a reason for this?

3. I'm seeing weird behavior with insmod of am200epd on my test system
on a gumstix. Probably something that I'm doing wrong but I wanted to
ask advice here anyway. Here's what I'm doing:
# insmod drivers/video/cfbcopyarea.ko && insmod
drivers/video/cfbfillrect.ko && insmod drivers/video/cfbimgblt.ko
# insmod drivers/video/syscopyarea.ko && insmod
drivers/video/sysfillrect.ko && insmod drivers/video/sysimgblt.ko &&
insmod drivers/video/fb_sys_fops.ko
# insmod drivers/video/metronomefb.ko ; insmod drivers/video/pxafb.ko
# grep pxafb_probe /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]
# grep bf014000 /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]
bf014000 t $a   [pxafb]

The reason I was debugging this was because platform_device_add was
failing from am200epd when am200epd is trying to add pxa2xx-fb. It
would fail from platform_drv_probe. I found that it was because the
pxafb's probe routine somehow gets replaced by other stuff. I was
worried if it was due to am200epd so I then took out all the code from
am200epd's init_module so it does nothing other than return 0. So the
following insmod is of am200epd that has a completely empty
init_module.

# insmod arch/arm/mach-pxa/am200epd.ko

# grep pxafb_probe /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]

# grep bf014000 /proc/kallsyms
bf014000 t am200_exit   [am200epd]
bf014000 t $a   [am200epd]
bf014000 t cleanup_module       [am200epd]
bf014000 t pxafb_probe  [pxafb]
bf014000 t $a   [pxafb]

The above doesn't make sense to me. I don't understand why am200_exit
is overloaded at the same address as pxafb_probe. Any suggestions on
how to debug this?

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Hi Jaya,

-----Original Message-----
From: Jaya Kumar [mailto:jayakumar.lkml@gmail.com]
Sent: Friday, May 09, 2008 4:07 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Debugging pxafb and am200epd

Hi Eric,

Just some quick questions and notes while trying to implement am200epd
sharing pxafb's framebuffer.

1. pxafb_init is set to __devinit, but it is only called from
module_init. Is my understanding correct that it should be __init?

Yes indeed, it is not a HOTPLUG device obviously, there are some
variables associated, like g_options[], so will have another look
into this.

2. pxafb currently doesn't implement module unloading support.  Is
there a reason for this?

From technical, I don't think so, yet there might be some if u want :)
 - this driver really has a long history, and
 - most uses it as builtin and never unload it

3. I'm seeing weird behavior with insmod of am200epd on my test system
on a gumstix. Probably something that I'm doing wrong but I wanted to
ask advice here anyway. Here's what I'm doing:
# insmod drivers/video/cfbcopyarea.ko && insmod
drivers/video/cfbfillrect.ko && insmod drivers/video/cfbimgblt.ko
# insmod drivers/video/syscopyarea.ko && insmod
drivers/video/sysfillrect.ko && insmod drivers/video/sysimgblt.ko &&
insmod drivers/video/fb_sys_fops.ko
# insmod drivers/video/metronomefb.ko ; insmod drivers/video/pxafb.ko
# grep pxafb_probe /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]
# grep bf014000 /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]
bf014000 t $a   [pxafb]

The reason I was debugging this was because platform_device_add was
failing from am200epd when am200epd is trying to add pxa2xx-fb. It
would fail from platform_drv_probe. I found that it was because the
pxafb's probe routine somehow gets replaced by other stuff. I was
worried if it was due to am200epd so I then took out all the code from
am200epd's init_module so it does nothing other than return 0. So the
following insmod is of am200epd that has a completely empty
init_module.

# insmod arch/arm/mach-pxa/am200epd.ko

# grep pxafb_probe /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]

# grep bf014000 /proc/kallsyms
bf014000 t am200_exit   [am200epd]
bf014000 t $a   [am200epd]
bf014000 t cleanup_module       [am200epd]
bf014000 t pxafb_probe  [pxafb]
bf014000 t $a   [pxafb]

The above doesn't make sense to me. I don't understand why am200_exit
is overloaded at the same address as pxafb_probe. Any suggestions on
how to debug this?

doesn't make sense to me either :), but check your am200epd.ko which I
wonder if it has included the pxafb.o already to avoid duplication code
being inserted (insmod should complain but I'm not sure)

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Fri, May 9, 2008 at 5:20 AM, Eric Miao [off-list ref] wrote:

Hi Jaya,

quoted

-----Original Message-----
From: Jaya Kumar [mailto:jayakumar.lkml@gmail.com]
Sent: Friday, May 09, 2008 4:07 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Debugging pxafb and am200epd

Hi Eric,

Just some quick questions and notes while trying to implement am200epd
sharing pxafb's framebuffer.

1. pxafb_init is set to __devinit, but it is only called from
module_init. Is my understanding correct that it should be __init?

Yes indeed, it is not a HOTPLUG device obviously, there are some
variables associated, like g_options[], so will have another look
into this.

quoted

2. pxafb currently doesn't implement module unloading support.  Is
there a reason for this?

From technical, I don't think so, yet there might be some if u want :)
 - this driver really has a long history, and
 - most uses it as builtin and never unload it

I see. The reason I encountered it was because I was debugging and it
was troublesome to reboot each time after testing. If you like, I can
try to add the exit and remove code. It'll be useful if anyone else
wants to do more weird stuff like am200epd. :-)

quoted

3. I'm seeing weird behavior with insmod of am200epd on my test system
on a gumstix. Probably something that I'm doing wrong but I wanted to
ask advice here anyway. Here's what I'm doing:
# insmod drivers/video/cfbcopyarea.ko && insmod
drivers/video/cfbfillrect.ko && insmod drivers/video/cfbimgblt.ko
# insmod drivers/video/syscopyarea.ko && insmod
drivers/video/sysfillrect.ko && insmod drivers/video/sysimgblt.ko &&
insmod drivers/video/fb_sys_fops.ko
# insmod drivers/video/metronomefb.ko ; insmod drivers/video/pxafb.ko
# grep pxafb_probe /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]
# grep bf014000 /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]
bf014000 t $a   [pxafb]

The reason I was debugging this was because platform_device_add was
failing from am200epd when am200epd is trying to add pxa2xx-fb. It
would fail from platform_drv_probe. I found that it was because the
pxafb's probe routine somehow gets replaced by other stuff. I was
worried if it was due to am200epd so I then took out all the code from
am200epd's init_module so it does nothing other than return 0. So the
following insmod is of am200epd that has a completely empty
init_module.

# insmod arch/arm/mach-pxa/am200epd.ko

# grep pxafb_probe /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]

# grep bf014000 /proc/kallsyms
bf014000 t am200_exit   [am200epd]
bf014000 t $a   [am200epd]
bf014000 t cleanup_module       [am200epd]
bf014000 t pxafb_probe  [pxafb]
bf014000 t $a   [pxafb]

The above doesn't make sense to me. I don't understand why am200_exit
is overloaded at the same address as pxafb_probe. Any suggestions on
how to debug this?

doesn't make sense to me either :), but check your am200epd.ko which I
wonder if it has included the pxafb.o already to avoid duplication code
being inserted (insmod should complain but I'm not sure)

I've moved am200epd.ko to arch/arm/mach-pxa. The build for that says:
obj-y                           += clock.o devices.o generic.o irq.o dma.o \
                                   time.o gpio.o
obj-$(CONFIG_MACH_AM200EPD)     += am200epd.o

It doesn't include pxafb.o. I even took out #include pxafb.h to see if
that was the cause but it still happens. I just tested something
different which was to load the empty am200epd first. Then load pxafb.
When I do that, the overlap doesn't occur. But if I load pxafb first,
and then load am200epd, then the overlap happens. I'm really confused
why. I think I'll sleep on it and see what I can figure out this
weekend. If anyone has any suggestions, that would be greatly
appreciated.

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Fri, May 9, 2008 at 6:17 AM, Jaya Kumar [off-list ref] wrote:

On Fri, May 9, 2008 at 5:20 AM, Eric Miao [off-list ref] wrote:

quoted

Hi Jaya,

quoted

-----Original Message-----
From: Jaya Kumar [mailto:jayakumar.lkml@gmail.com]
Sent: Friday, May 09, 2008 4:07 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Debugging pxafb and am200epd

Hi Eric,

Just some quick questions and notes while trying to implement am200epd
sharing pxafb's framebuffer.

1. pxafb_init is set to __devinit, but it is only called from
module_init. Is my understanding correct that it should be __init?

Yes indeed, it is not a HOTPLUG device obviously, there are some
variables associated, like g_options[], so will have another look
into this.

quoted

2. pxafb currently doesn't implement module unloading support.  Is
there a reason for this?

From technical, I don't think so, yet there might be some if u want :)
 - this driver really has a long history, and
 - most uses it as builtin and never unload it

I see. The reason I encountered it was because I was debugging and it
was troublesome to reboot each time after testing. If you like, I can
try to add the exit and remove code. It'll be useful if anyone else
wants to do more weird stuff like am200epd. :-)

quoted

quoted

3. I'm seeing weird behavior with insmod of am200epd on my test system
on a gumstix. Probably something that I'm doing wrong but I wanted to
ask advice here anyway. Here's what I'm doing:
# insmod drivers/video/cfbcopyarea.ko && insmod
drivers/video/cfbfillrect.ko && insmod drivers/video/cfbimgblt.ko
# insmod drivers/video/syscopyarea.ko && insmod
drivers/video/sysfillrect.ko && insmod drivers/video/sysimgblt.ko &&
insmod drivers/video/fb_sys_fops.ko
# insmod drivers/video/metronomefb.ko ; insmod drivers/video/pxafb.ko
# grep pxafb_probe /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]
# grep bf014000 /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]
bf014000 t $a   [pxafb]

The reason I was debugging this was because platform_device_add was
failing from am200epd when am200epd is trying to add pxa2xx-fb. It
would fail from platform_drv_probe. I found that it was because the
pxafb's probe routine somehow gets replaced by other stuff. I was
worried if it was due to am200epd so I then took out all the code from
am200epd's init_module so it does nothing other than return 0. So the
following insmod is of am200epd that has a completely empty
init_module.

# insmod arch/arm/mach-pxa/am200epd.ko

# grep pxafb_probe /proc/kallsyms
bf014000 t pxafb_probe  [pxafb]

# grep bf014000 /proc/kallsyms
bf014000 t am200_exit   [am200epd]
bf014000 t $a   [am200epd]
bf014000 t cleanup_module       [am200epd]
bf014000 t pxafb_probe  [pxafb]
bf014000 t $a   [pxafb]

The above doesn't make sense to me. I don't understand why am200_exit
is overloaded at the same address as pxafb_probe. Any suggestions on
how to debug this?

doesn't make sense to me either :), but check your am200epd.ko which I
wonder if it has included the pxafb.o already to avoid duplication code
being inserted (insmod should complain but I'm not sure)

I've moved am200epd.ko to arch/arm/mach-pxa. The build for that says:
obj-y                           += clock.o devices.o generic.o irq.o dma.o \
                                  time.o gpio.o
obj-$(CONFIG_MACH_AM200EPD)     += am200epd.o

the exact compile line that is generated by kbuild is:

  arm-linux-gcc -Wp,-MD,arch/arm/mach-pxa/.am200epd.o.d  -nostdinc
-isystem /home/jaya/metronome/gumstix-buildroot/build_arm_nofpu/staging_dir/lib/gcc/arm-linux-uclibcgnueabi/4.1.1/include
-D__KERNEL__ -Iinclude  -include include/linux/autoconf.h
-mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Os   -fno-stack-protector -marm -fno-omit-frame-pointer -mapcs
-mno-sched-prolog -mabi=aapcs-linux -mno-thumb-interwork
-D__LINUX_ARM_ARCH__=5 -march=armv5te -mtune=xscale -Wa,-mcpu=xscale
-msoft-float -Uarm -fno-omit-frame-pointer -fno-optimize-sibling-calls
-Wdeclaration-after-statement -Wno-pointer-sign    -DMODULE
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(am200epd)"
-D"KBUILD_MODNAME=KBUILD_STR(am200epd)" -c -o
arch/arm/mach-pxa/am200epd.o arch/arm/mach-pxa/am200epd.c

  arm-linux-ld -EL -r    -o arch/arm/mach-pxa/am200epd.ko
arch/arm/mach-pxa/am200epd.o arch/arm/mach-pxa/am200epd.mod.o

It doesn't include pxafb.o. I even took out #include pxafb.h to see if
that was the cause but it still happens. I just tested something
different which was to load the empty am200epd first. Then load pxafb.
When I do that, the overlap doesn't occur. But if I load pxafb first,
and then load am200epd, then the overlap happens. I'm really confused
why. I think I'll sleep on it and see what I can figure out this
weekend. If anyone has any suggestions, that would be greatly
appreciated.

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Fri, May 9, 2008 at 5:20 AM, Eric Miao [off-list ref] wrote:

Hi Jaya,

quoted

-----Original Message-----
From: Jaya Kumar [mailto:jayakumar.lkml@gmail.com]
Sent: Friday, May 09, 2008 4:07 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Debugging pxafb and am200epd

Hi Eric,

Just some quick questions and notes while trying to implement am200epd
sharing pxafb's framebuffer.

1. pxafb_init is set to __devinit, but it is only called from
module_init. Is my understanding correct that it should be __init?

Yes indeed, it is not a HOTPLUG device obviously, there are some
variables associated, like g_options[], so will have another look
into this.

quoted

2. pxafb currently doesn't implement module unloading support.  Is
there a reason for this?

From technical, I don't think so, yet there might be some if u want :)
 - this driver really has a long history, and
 - most uses it as builtin and never unload it

quoted

3. I'm seeing weird behavior with insmod of am200epd on my test system
on a gumstix. Probably something that I'm doing wrong but I wanted to

Hi Eric,

It looks like the issue is tied to the __devinit used on pxafb_init. I
switched pxafb_init to __init and the problem goes away. Here's my
current result from testing:

# grep pxafb_probe /proc/kallsyms
bf01401c t pxafb_probe  [pxafb]
# grep bf01401c /proc/kallsyms
bf01401c t pxafb_probe  [pxafb]
bf01401c t $a   [pxafb]
# insmod arch/arm/mach-pxa/am200epd.ko
# grep bf01401c /proc/kallsyms
bf01401c t pxafb_probe  [pxafb]
bf01401c t $a   [pxafb]
# grep am200_exit /proc/kallsyms
bf014000 t am200_exit   [am200epd]

So it looks okay now. I didn't quite analyze why the setting of
__devinit on pxafb_init seems to affect pxafb_probe but maybe there's
a relationship there.

While I was doing this, I cooked up the following patch to pxafb to
make it unloadable. I've appended the code below. If it looks okay to
you, I would like to test it a bit and then submit it as a patch.

Thanks,
jaya

diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index 3ab6e3d..ffbce49 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c

@@ -1778,8 +1797,35 @@ failed:
        return ret;
 }

+static int __devexit pxafb_remove(struct platform_device *dev)
+{
+       struct pxafb_info *fbi = platform_get_drvdata(dev);
+       struct resource *r;
+       int irq;
+
+       if (fbi) {
+               struct fb_info *info = &fbi->fb;
+
+               irq = platform_get_irq(dev, 0);
+               free_irq(irq, fbi);
+
+               r = platform_get_resource(dev, IORESOURCE_MEM, 0);
+               release_mem_region(r->start, r->end - r->start + 1);
+
+               iounmap(fbi->mmio_base);
+
+               dma_free_writecombine(&dev->dev, fbi->map_size,
+                                       fbi->map_cpu, fbi->map_dma);
+               fb_dealloc_cmap(&info->cmap);
+               unregister_framebuffer(info);
+               kfree(fbi);
+       }
+       return 0;
+}
+
 static struct platform_driver pxafb_driver = {
        .probe          = pxafb_probe,
+       .remove         = pxafb_remove,
        .suspend        = pxafb_suspend,
        .resume         = pxafb_resume,
        .driver         = {

@@ -1787,7 +1833,7 @@ static struct platform_driver pxafb_driver = {
        },
 };

-static int __devinit pxafb_init(void)
+static int __init pxafb_init(void)
 {
        if (pxafb_setup_options())
                return -EINVAL;

@@ -1795,7 +1841,13 @@ static int __devinit pxafb_init(void)
        return platform_driver_register(&pxafb_driver);
 }

+static void __exit pxafb_exit(void)
+{
+       platform_driver_unregister(&pxafb_driver);
+}
+
 module_init(pxafb_init);
+module_exit(pxafb_exit);

 MODULE_DESCRIPTION("loadable framebuffer driver for PXA");
 MODULE_LICENSE("GPL");

-------------------------------------------------------------------------

This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

-----Original Message-----
From: Jaya Kumar [mailto:jayakumar.lkml@gmail.com]
Sent: Saturday, May 10, 2008 1:38 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Re: Debugging pxafb and am200epd

On Fri, May 9, 2008 at 5:20 AM, Eric Miao [off-list ref] wrote:

quoted

Hi Jaya,

quoted

-----Original Message-----
From: Jaya Kumar [mailto:jayakumar.lkml@gmail.com]
Sent: Friday, May 09, 2008 4:07 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Debugging pxafb and am200epd

Hi Eric,

Just some quick questions and notes while trying to implement am200epd
sharing pxafb's framebuffer.

1. pxafb_init is set to __devinit, but it is only called from
module_init. Is my understanding correct that it should be __init?

Yes indeed, it is not a HOTPLUG device obviously, there are some
variables associated, like g_options[], so will have another look
into this.

quoted

2. pxafb currently doesn't implement module unloading support.  Is
there a reason for this?

From technical, I don't think so, yet there might be some if u want :)
 - this driver really has a long history, and
 - most uses it as builtin and never unload it

quoted

3. I'm seeing weird behavior with insmod of am200epd on my test system
on a gumstix. Probably something that I'm doing wrong but I wanted to

Hi Eric,

It looks like the issue is tied to the __devinit used on pxafb_init. I
switched pxafb_init to __init and the problem goes away. Here's my
current result from testing:

# grep pxafb_probe /proc/kallsyms
bf01401c t pxafb_probe  [pxafb]
# grep bf01401c /proc/kallsyms
bf01401c t pxafb_probe  [pxafb]
bf01401c t $a   [pxafb]
# insmod arch/arm/mach-pxa/am200epd.ko
# grep bf01401c /proc/kallsyms
bf01401c t pxafb_probe  [pxafb]
bf01401c t $a   [pxafb]
# grep am200_exit /proc/kallsyms
bf014000 t am200_exit   [am200epd]

So it looks okay now. I didn't quite analyze why the setting of
__devinit on pxafb_init seems to affect pxafb_probe but maybe there's
a relationship there.

Mmm... this is interesting, I'm not able to figure out why for the moment,
but if you do, please let me know.

The pxafb_init() should really be __init, as well as the pxafb_probe(), since
the device itself isn't a hotplug one, according to the ocumentation/PCI/pci.txt

And I think it's better to fire a separate patch to fix this.

While I was doing this, I cooked up the following patch to pxafb to
make it unloadable. I've appended the code below. If it looks okay to
you, I would like to test it a bit and then submit it as a patch.

This is good, I like this one. Please also submit to the linux-arm-kernel
[off-list ref], we have some users there who
might be also interested in a removable pxafb driver.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Sun, May 11, 2008 at 11:07 PM, Eric Miao [off-list ref] wrote:

The pxafb_init() should really be __init, as well as the pxafb_probe(), since
the device itself isn't a hotplug one, according to the ocumentation/PCI/pci.txt

I got things to work only if I set pxafb_init to __init and
pxafb_probe as __devinit. With pxafb_probe as __init, the overlap
still occurred. I think this is consistent with the explanation in
pci.txt.

And I think it's better to fire a separate patch to fix this.

Agreed. I'll make sure to do each of the patches as individual ones.

quoted

While I was doing this, I cooked up the following patch to pxafb to
make it unloadable. I've appended the code below. If it looks okay to
you, I would like to test it a bit and then submit it as a patch.

This is good, I like this one. Please also submit to the linux-arm-kernel
[off-list ref], we have some users there who
might be also interested in a removable pxafb driver.

Ok, will do.

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

-----Original Message-----
From: Jaya Kumar [mailto:jayakumar.lkml@gmail.com]
Sent: Monday, May 12, 2008 11:23 AM
To: Eric Miao
Cc: Linux Frame Buffer Device Development
Subject: Re: Debugging pxafb and am200epd

On Sun, May 11, 2008 at 11:07 PM, Eric Miao [off-list ref] wrote:

quoted

The pxafb_init() should really be __init, as well as the pxafb_probe(), since
the device itself isn't a hotplug one, according to the

ocumentation/PCI/pci.txt

I got things to work only if I set pxafb_init to __init and
pxafb_probe as __devinit. With pxafb_probe as __init, the overlap
still occurred. I think this is consistent with the explanation in
pci.txt.

Please also try modify pxafb_setup_options() and g_options[] to __init,
I don't think they deserve a __devinit either.

quoted

And I think it's better to fire a separate patch to fix this.

Agreed. I'll make sure to do each of the patches as individual ones.

quoted

quoted

While I was doing this, I cooked up the following patch to pxafb to
make it unloadable. I've appended the code below. If it looks okay to
you, I would like to test it a bit and then submit it as a patch.

This is good, I like this one. Please also submit to the linux-arm-kernel
[off-list ref], we have some users there who
might be also interested in a removable pxafb driver.

Ok, will do.

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone