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

["Hans-Jürgen Koch" <hjk@linutronix.de>]

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/