pxafb: Is it actually working in 2.6.21?

pxafb: Is it actually working in 2.6.21?

[Hans-Jürgen Koch]

In the last few days, I desperately tried to make pxafb work on a 2.6.21
vanilla kernel. All I got so far is some white and black blur on my display.
I asked for help on the linux-arm-kernel mailing list, but though friendly
and competent people answered my request, it still doesn't work.

So, I'd like to know if pxafb in 2.6.21 is actually working for somebody 
with a similar setup.

Here's what I've got:

- Kernel 2.6.21, gcc 4.1.0 or 3.4.1 (same behaviour)
- PXA270, TFT 800x600
- At boot time, pxafb reports no errors
- fbset -i shows the expected values
- BUT the display shows only white and black blur

Now I find mysterious things going on in pxafb_enable_controller(). The driver
calculates reasonable values for e.g. LCCR0, but they disappear soon after
they've been set. I added some pr_debug lines, the code looks like this:

static void pxafb_enable_controller(struct pxafb_info *fbi)
{
        pr_debug("pxafb: Enabling LCD controller\n");
        pr_debug("fdadr0 0x%08x\n", (unsigned int) fbi->fdadr0);
        pr_debug("fdadr1 0x%08x\n", (unsigned int) fbi->fdadr1);
        pr_debug("reg_lccr0 0x%08x\n", (unsigned int) fbi->reg_lccr0);
        pr_debug("reg_lccr1 0x%08x\n", (unsigned int) fbi->reg_lccr1);
        pr_debug("reg_lccr2 0x%08x\n", (unsigned int) fbi->reg_lccr2);
        pr_debug("reg_lccr3 0x%08x\n", (unsigned int) fbi->reg_lccr3);

        /* enable LCD controller clock */
        pxa_set_cken(CKEN16_LCD, 1);

        pr_debug("1.LCCR0 0x%08x\n", (unsigned int) LCCR0);
        LCCR0 = fbi->reg_lccr0 & ~LCCR0_ENB; /* Make sure it's disabled */
        pr_debug("2.LCCR0 0x%08x\n", (unsigned int) LCCR0);

        /* Sequence from 11.7.10 */
        LCCR3 = fbi->reg_lccr3;
        LCCR2 = fbi->reg_lccr2;
        LCCR1 = fbi->reg_lccr1;
        LCCR0 = fbi->reg_lccr0 & ~LCCR0_ENB;
        pr_debug("LCCR0 (0x%08x) = 0x%08x\n", &LCCR0, (unsigned int)LCCR0);

        FDADR0 = fbi->fdadr0;
        FDADR1 = fbi->fdadr1;
        LCCR0 |= LCCR0_ENB;

        pr_debug("FDADR0 0x%08x\n", (unsigned int) FDADR0);
        pr_debug("FDADR1 0x%08x\n", (unsigned int) FDADR1);
        pr_debug("LCCR0 0x%08x\n", (unsigned int) LCCR0);
        pr_debug("LCCR1 0x%08x\n", (unsigned int) LCCR1);
        pr_debug("LCCR2 0x%08x\n", (unsigned int) LCCR2);
        pr_debug("LCCR3 0x%08x\n", (unsigned int) LCCR3);
}

At boot time, I get the following output from that code:

[    9.780000] pxafb: Enabling LCD controller
[    9.830000] fdadr0 0xa3d00fe0
[    9.870000] fdadr1 0xa3d00fd0
[    9.900000] reg_lccr0 0x003008f8
[    9.940000] reg_lccr1 0x5727ff1f
[    9.980000] reg_lccr2 0x1c010e57
[   10.020000] reg_lccr3 0x04700002
[   10.060000] 1.LCCR0 0x00000005
[   10.090000] 2.LCCR0 0x003008f8
[   10.130000] LCCR0 (0xf4000000) = 0x003008f8
[   10.180000] FDADR0 0x000000d1
[   10.210000] FDADR1 0x000000d1
[   10.250000] LCCR0 0x000000d1
[   10.280000] LCCR1 0x0000001f
[   10.320000] LCCR2 0x000000d1
[   10.350000] LCCR3 0x0000001f

ATM, I only looked at LCCR0 and find this strange:

- First (in "1.LCCR0..."), Bit 0 is set, meaning it's already enabled
- Then (in "2.LCCR0..."), the value is set properly
- It ends up with 0xd1 in LCCR0, which is complete crap

Russell King suggested to disassemble the code, but as I get the same 
behaviour with two very different versions of gcc, I don't really 
believe that this is the problem. Eric Miao thought it might be the
DMA controller that's not set up properly and overwrites my registers.
As this is completely independent of my board setup, it should apply
to _everybody_ using pxafb.

If I don't get this to work soon, my wife will divorce me, my bank will
cancel my account, and my dog will get lice and fleas.

So, please give a lonely hacker a helping hand and tell me what's going on.
Does it work for somebody? Anybody with similar problems?

I'll be offline for a few hours of dreamless sleep.

Thanks,
Hans


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: pxafb: Is it actually working in 2.6.21?

[Richard Purdie]

On Fri, 2007-06-08 at 01:18 +0200, Hans-Jürgen Koch wrote:
> In the last few days, I desperately tried to make pxafb work on a 2.6.21
> vanilla kernel. All I got so far is some white and black blur on my display.
> I asked for help on the linux-arm-kernel mailing list, but though friendly
> and competent people answered my request, it still doesn't work.
> 
> So, I'd like to know if pxafb in 2.6.21 is actually working for somebody 
> with a similar setup.

pxafb works for me on the Spitz (PXA270 based) machine in 2.6.21.

Regards,

Richard


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Re: pxafb: Is it actually working in 2.6.21?

[Antonino A. Daplas]

On Fri, 2007-06-08 at 01:18 +0200, Hans-Jürgen Koch wrote:
I'm top posting intentionally.

It looks like something is clobbering your registers, and it happens
after enabling the LCD.

I'm adding the Zaurus people to the CC list.  He worked on this driver
too.

Tony
> In the last few days, I desperately tried to make pxafb work on a 2.6.21
> vanilla kernel. All I got so far is some white and black blur on my display.
> I asked for help on the linux-arm-kernel mailing list, but though friendly
> and competent people answered my request, it still doesn't work.
> 
> So, I'd like to know if pxafb in 2.6.21 is actually working for somebody 
> with a similar setup.
> 
> Here's what I've got:
> 
> - Kernel 2.6.21, gcc 4.1.0 or 3.4.1 (same behaviour)
> - PXA270, TFT 800x600
> - At boot time, pxafb reports no errors
> - fbset -i shows the expected values
> - BUT the display shows only white and black blur
> 
> Now I find mysterious things going on in pxafb_enable_controller(). The driver
> calculates reasonable values for e.g. LCCR0, but they disappear soon after
> they've been set. I added some pr_debug lines, the code looks like this:
> 
> static void pxafb_enable_controller(struct pxafb_info *fbi)
> {
>         pr_debug("pxafb: Enabling LCD controller\n");
>         pr_debug("fdadr0 0x%08x\n", (unsigned int) fbi->fdadr0);
>         pr_debug("fdadr1 0x%08x\n", (unsigned int) fbi->fdadr1);
>         pr_debug("reg_lccr0 0x%08x\n", (unsigned int) fbi->reg_lccr0);
>         pr_debug("reg_lccr1 0x%08x\n", (unsigned int) fbi->reg_lccr1);
>         pr_debug("reg_lccr2 0x%08x\n", (unsigned int) fbi->reg_lccr2);
>         pr_debug("reg_lccr3 0x%08x\n", (unsigned int) fbi->reg_lccr3);
> 
>         /* enable LCD controller clock */
>         pxa_set_cken(CKEN16_LCD, 1);
> 
>         pr_debug("1.LCCR0 0x%08x\n", (unsigned int) LCCR0);
>         LCCR0 = fbi->reg_lccr0 & ~LCCR0_ENB; /* Make sure it's disabled */
>         pr_debug("2.LCCR0 0x%08x\n", (unsigned int) LCCR0);
> 
>         /* Sequence from 11.7.10 */
>         LCCR3 = fbi->reg_lccr3;
>         LCCR2 = fbi->reg_lccr2;
>         LCCR1 = fbi->reg_lccr1;
>         LCCR0 = fbi->reg_lccr0 & ~LCCR0_ENB;
>         pr_debug("LCCR0 (0x%08x) = 0x%08x\n", &LCCR0, (unsigned int)LCCR0);
> 
>         FDADR0 = fbi->fdadr0;
>         FDADR1 = fbi->fdadr1;
>         LCCR0 |= LCCR0_ENB;
> 
>         pr_debug("FDADR0 0x%08x\n", (unsigned int) FDADR0);
>         pr_debug("FDADR1 0x%08x\n", (unsigned int) FDADR1);
>         pr_debug("LCCR0 0x%08x\n", (unsigned int) LCCR0);
>         pr_debug("LCCR1 0x%08x\n", (unsigned int) LCCR1);
>         pr_debug("LCCR2 0x%08x\n", (unsigned int) LCCR2);
>         pr_debug("LCCR3 0x%08x\n", (unsigned int) LCCR3);
> }
> 
> At boot time, I get the following output from that code:
> 
> [    9.780000] pxafb: Enabling LCD controller
> [    9.830000] fdadr0 0xa3d00fe0
> [    9.870000] fdadr1 0xa3d00fd0
> [    9.900000] reg_lccr0 0x003008f8
> [    9.940000] reg_lccr1 0x5727ff1f
> [    9.980000] reg_lccr2 0x1c010e57
> [   10.020000] reg_lccr3 0x04700002
> [   10.060000] 1.LCCR0 0x00000005
> [   10.090000] 2.LCCR0 0x003008f8
> [   10.130000] LCCR0 (0xf4000000) = 0x003008f8
> [   10.180000] FDADR0 0x000000d1
> [   10.210000] FDADR1 0x000000d1
> [   10.250000] LCCR0 0x000000d1
> [   10.280000] LCCR1 0x0000001f
> [   10.320000] LCCR2 0x000000d1
> [   10.350000] LCCR3 0x0000001f
> 
> ATM, I only looked at LCCR0 and find this strange:
> - First (in "1.LCCR0..."), Bit 0 is set, meaning it's already enabled
> - Then (in "2.LCCR0..."), the value is set properly
> - It ends up with 0xd1 in LCCR0, which is complete crap
> 
> Russell King suggested to disassemble the code, but as I get the same 
> behaviour with two very different versions of gcc, I don't really 
> believe that this is the problem. Eric Miao thought it might be the
> DMA controller that's not set up properly and overwrites my registers.
> As this is completely independent of my board setup, it should apply
> to _everybody_ using pxafb.
> 
> If I don't get this to work soon, my wife will divorce me, my bank will
> cancel my account, and my dog will get lice and fleas.
> 
> So, please give a lonely hacker a helping hand and tell me what's going on.
> Does it work for somebody? Anybody with similar problems?
> 
> I'll be offline for a few hours of dreamless sleep.
> 
> Thanks,
> Hans
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: pxafb: Is it actually working in 2.6.21?

[Antonino A. Daplas]

On Fri, 2007-06-08 at 01:18 +0200, Hans-Jürgen Koch wrote:
> In the last few days, I desperately tried to make pxafb work on a 2.6.21
> vanilla kernel. All I got so far is some white and black blur on my display.
> I asked for help on the linux-arm-kernel mailing list, but though friendly
> and competent people answered my request, it still doesn't work.
> 
> So, I'd like to know if pxafb in 2.6.21 is actually working for somebody 
> with a similar setup.
> 
> Here's what I've got:
> 
> - Kernel 2.6.21, gcc 4.1.0 or 3.4.1 (same behaviour)
> - PXA270, TFT 800x600
> - At boot time, pxafb reports no errors
> - fbset -i shows the expected values
> - BUT the display shows only white and black blur

Just to be sure we're not missing anything obvious:

Have you tried cat <file> > /dev/fb0 without any response from the
display?

Have you tried using the driver with the framebuffer console?

Tony



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: pxafb: Is it actually working in 2.6.21?

[eric miao]

Richard Purdie wrote:
> On Fri, 2007-06-08 at 01:18 +0200, Hans-Jürgen Koch wrote:
>> In the last few days, I desperately tried to make pxafb work on a 2.6.21
>> vanilla kernel. All I got so far is some white and black blur on my display.
>> I asked for help on the linux-arm-kernel mailing list, but though friendly
>> and competent people answered my request, it still doesn't work.
>>
>> So, I'd like to know if pxafb in 2.6.21 is actually working for somebody 
>> with a similar setup.
> 
> pxafb works for me on the Spitz (PXA270 based) machine in 2.6.21.

Also, pxafb works for me on the Mainstone (PXA270) and Lubbock (PXA255)
in 2.6.21.

- eric

> Regards,
> 
> Richard
> 
> 
> -------------------------------------------------------------------
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
> 


-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: pxafb: Is it actually working in 2.6.21?

[Hans-Jürgen Koch]

Am Freitag 08 Juni 2007 02:31 schrieb Antonino A. Daplas:
> On Fri, 2007-06-08 at 01:18 +0200, Hans-Jürgen Koch wrote:
> > In the last few days, I desperately tried to make pxafb work on a 2.6.21
> > vanilla kernel. All I got so far is some white and black blur on my display.
> > I asked for help on the linux-arm-kernel mailing list, but though friendly
> > and competent people answered my request, it still doesn't work.
> > 
> > So, I'd like to know if pxafb in 2.6.21 is actually working for somebody 
> > with a similar setup.
> > 
> > Here's what I've got:
> > 
> > - Kernel 2.6.21, gcc 4.1.0 or 3.4.1 (same behaviour)
> > - PXA270, TFT 800x600
> > - At boot time, pxafb reports no errors
> > - fbset -i shows the expected values
> > - BUT the display shows only white and black blur
> 
> Just to be sure we're not missing anything obvious:
> 
> Have you tried cat <file> > /dev/fb0 without any response from the
> display?

Yes, no visible changes.

> 
> Have you tried using the driver with the framebuffer console?

Yes, nothing visible.

Thanks,
Hans

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [SOLVED] pxafb: Is it actually working in 2.6.21?

[Hans-Jürgen Koch]

Am Freitag 08 Juni 2007 schrieb Hans-Jürgen Koch:
> In the last few days, I desperately tried to make pxafb work on a 2.6.21
> vanilla kernel. All I got so far is some white and black blur on my
> display. I asked for help on the linux-arm-kernel mailing list, but though
> friendly and competent people answered my request, it still doesn't work.
>
> So, I'd like to know if pxafb in 2.6.21 is actually working for somebody
> with a similar setup.
>
> Here's what I've got:
>
> - Kernel 2.6.21, gcc 4.1.0 or 3.4.1 (same behaviour)
> - PXA270, TFT 800x600
> - At boot time, pxafb reports no errors
> - fbset -i shows the expected values
> - BUT the display shows only white and black blur
>
> Now I find mysterious things going on in pxafb_enable_controller(). The
> driver calculates reasonable values for e.g. LCCR0, but they disappear soon
> after they've been set. I added some pr_debug lines, the code looks like
> this:
>
> static void pxafb_enable_controller(struct pxafb_info *fbi)
> {
>         pr_debug("pxafb: Enabling LCD controller\n");
>         pr_debug("fdadr0 0x%08x\n", (unsigned int) fbi->fdadr0);
>         pr_debug("fdadr1 0x%08x\n", (unsigned int) fbi->fdadr1);
>         pr_debug("reg_lccr0 0x%08x\n", (unsigned int) fbi->reg_lccr0);
>         pr_debug("reg_lccr1 0x%08x\n", (unsigned int) fbi->reg_lccr1);
>         pr_debug("reg_lccr2 0x%08x\n", (unsigned int) fbi->reg_lccr2);
>         pr_debug("reg_lccr3 0x%08x\n", (unsigned int) fbi->reg_lccr3);
>
>         /* enable LCD controller clock */
>         pxa_set_cken(CKEN16_LCD, 1);
>
>         pr_debug("1.LCCR0 0x%08x\n", (unsigned int) LCCR0);
>         LCCR0 = fbi->reg_lccr0 & ~LCCR0_ENB; /* Make sure it's disabled */
>         pr_debug("2.LCCR0 0x%08x\n", (unsigned int) LCCR0);
>
>         /* Sequence from 11.7.10 */
>         LCCR3 = fbi->reg_lccr3;
>         LCCR2 = fbi->reg_lccr2;
>         LCCR1 = fbi->reg_lccr1;
>         LCCR0 = fbi->reg_lccr0 & ~LCCR0_ENB;
>         pr_debug("LCCR0 (0x%08x) = 0x%08x\n", &LCCR0, (unsigned int)LCCR0);
>
>         FDADR0 = fbi->fdadr0;
>         FDADR1 = fbi->fdadr1;
>         LCCR0 |= LCCR0_ENB;
>
>         pr_debug("FDADR0 0x%08x\n", (unsigned int) FDADR0);
>         pr_debug("FDADR1 0x%08x\n", (unsigned int) FDADR1);
>         pr_debug("LCCR0 0x%08x\n", (unsigned int) LCCR0);
>         pr_debug("LCCR1 0x%08x\n", (unsigned int) LCCR1);
>         pr_debug("LCCR2 0x%08x\n", (unsigned int) LCCR2);
>         pr_debug("LCCR3 0x%08x\n", (unsigned int) LCCR3);
> }
>
> At boot time, I get the following output from that code:
>
> [    9.780000] pxafb: Enabling LCD controller
> [    9.830000] fdadr0 0xa3d00fe0
> [    9.870000] fdadr1 0xa3d00fd0
> [    9.900000] reg_lccr0 0x003008f8
> [    9.940000] reg_lccr1 0x5727ff1f
> [    9.980000] reg_lccr2 0x1c010e57
> [   10.020000] reg_lccr3 0x04700002
> [   10.060000] 1.LCCR0 0x00000005
> [   10.090000] 2.LCCR0 0x003008f8
> [   10.130000] LCCR0 (0xf4000000) = 0x003008f8
> [   10.180000] FDADR0 0x000000d1
> [   10.210000] FDADR1 0x000000d1
> [   10.250000] LCCR0 0x000000d1
> [   10.280000] LCCR1 0x0000001f
> [   10.320000] LCCR2 0x000000d1
> [   10.350000] LCCR3 0x0000001f
>
> ATM, I only looked at LCCR0 and find this strange:
>
> - First (in "1.LCCR0..."), Bit 0 is set, meaning it's already enabled
> - Then (in "2.LCCR0..."), the value is set properly
> - It ends up with 0xd1 in LCCR0, which is complete crap
>
> Russell King suggested to disassemble the code, but as I get the same
> behaviour with two very different versions of gcc, I don't really
> believe that this is the problem. Eric Miao thought it might be the
> DMA controller that's not set up properly and overwrites my registers.
> As this is completely independent of my board setup, it should apply
> to _everybody_ using pxafb.
>

Just wanted to note that the problem is solved now. In the
board support from the manufacturer, they had the memory
of the DM9000 ethernet controller needlessly mapped, and 
used the address space of the LCD controller for that...

Thanks for all your help,

Hans

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/