[PATCH] pxafb: Add support for other palette formats

[PATCH] pxafb: Add support for other palette formats

[Hans-Jürgen Koch]

This patch adds support for the other three palette formats possible with 
the PXA LCD controller. This is required on boards where an LCD is connected
with all its 18 bits. With this patch, it's possible to use an 8-bit mode
with 18-bit palette entries. This used to be possible in 2.4 kernels but
disappeared in 2.6. With current kernels, you can only get wrong colours 
out of an LCD connected this way.

Users can choose the palette format by doing something like this
in their board definition:

static struct pxafb_mach_info my_fb_info = {
	[...]
	.lccr3		= LCCR3_OutEnH | LCCR3_PixFlEdg | LCCR3_PDFOR_3,
	.lccr4		= LCCR4_PAL_FOR_2,
	[...]
};

I plan to send complete board support for my device soon, it will rely
on this patch.

Thanks,
Hans

Signed-off-by: Hans J. Koch <hjk@linutronix.de>

Index: linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h
===================================================================
--- linux-2.6.22-rc.orig/include/asm-arm/arch-pxa/pxa-regs.h	2007-06-29 17:45:00.000000000 +0200
+++ linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h	2007-07-03 15:46:20.000000000 +0200
@@ -1843,6 +1843,7 @@
 #define LCCR1		__REG(0x44000004)  /* LCD Controller Control Register 1 */
 #define LCCR2		__REG(0x44000008)  /* LCD Controller Control Register 2 */
 #define LCCR3		__REG(0x4400000C)  /* LCD Controller Control Register 3 */
+#define LCCR4		__REG(0x44000010)  /* LCD Controller Control Register 3 */
 #define DFBR0		__REG(0x44000020)  /* DMA Channel 0 Frame Branch Register */
 #define DFBR1		__REG(0x44000024)  /* DMA Channel 1 Frame Branch Register */
 #define LCSR		__REG(0x44000038)  /* LCD Controller Status Register */
@@ -1856,6 +1857,16 @@
 #define LCCR3_8BPP (3 << 24)
 #define LCCR3_16BPP (4 << 24)
 
+#define LCCR3_PDFOR_0 (0 << 30)
+#define LCCR3_PDFOR_1 (1 << 30)
+#define LCCR3_PDFOR_2 (2 << 30)
+#define LCCR3_PDFOR_3 (3 << 30)
+
+#define LCCR4_PAL_FOR_0 (0 << 15)
+#define LCCR4_PAL_FOR_1 (1 << 15)
+#define LCCR4_PAL_FOR_2 (2 << 15)
+#define LCCR4_PAL_FOR_MASK (3 << 15)
+
 #define FDADR0		__REG(0x44000200)  /* DMA Channel 0 Frame Descriptor Address Register */
 #define FSADR0		__REG(0x44000204)  /* DMA Channel 0 Frame Source Address Register */
 #define FIDR0		__REG(0x44000208)  /* DMA Channel 0 Frame ID Register */
Index: linux-2.6.22-rc/drivers/video/pxafb.c
===================================================================
--- linux-2.6.22-rc.orig/drivers/video/pxafb.c	2007-06-29 17:44:59.000000000 +0200
+++ linux-2.6.22-rc/drivers/video/pxafb.c	2007-07-03 15:46:41.000000000 +0200
@@ -106,20 +106,38 @@
 		       u_int trans, struct fb_info *info)
 {
 	struct pxafb_info *fbi = (struct pxafb_info *)info;
-	u_int val, ret = 1;
+	u_int val;
 
-	if (regno < fbi->palette_size) {
-		if (fbi->fb.var.grayscale) {
-			val = ((blue >> 8) & 0x00ff);
-		} else {
-			val  = ((red   >>  0) & 0xf800);
-			val |= ((green >>  5) & 0x07e0);
-			val |= ((blue  >> 11) & 0x001f);
-		}
+	if (regno >= fbi->palette_size)
+		return 1;
+
+	if (fbi->fb.var.grayscale) {
+		fbi->palette_cpu[regno] = ((blue >> 8) & 0x00ff);
+		return 0;
+	}
+
+	switch (fbi->lccr4 & LCCR4_PAL_FOR_MASK) {
+	case LCCR4_PAL_FOR_0:
+		val  = ((red   >>  0) & 0xf800);
+		val |= ((green >>  5) & 0x07e0);
+		val |= ((blue  >> 11) & 0x001f);
 		fbi->palette_cpu[regno] = val;
-		ret = 0;
+		break;
+	case LCCR4_PAL_FOR_1:
+		val  = ((red   << 8) & 0x00f80000);
+		val |= ((green >> 0) & 0x0000fc00);
+		val |= ((blue  >> 8) & 0x000000f8);
+		((u32*)(fbi->palette_cpu))[regno] = val;
+		break;
+	case LCCR4_PAL_FOR_2:
+		val  = ((red   << 8) & 0x00fc0000);
+		val |= ((green >> 0) & 0x0000fc00);
+		val |= ((blue  >> 8) & 0x000000fc);
+		((u32*)(fbi->palette_cpu))[regno] = val;
+		break;
 	}
-	return ret;
+
+	return 0;
 }
 
 static int
@@ -361,7 +379,10 @@
 	else
 		fbi->palette_size = var->bits_per_pixel == 1 ? 4 : 1 << var->bits_per_pixel;
 
-	palette_mem_size = fbi->palette_size * sizeof(u16);
+	if ((fbi->lccr4 & LCCR4_PAL_FOR_MASK) == LCCR4_PAL_FOR_0)
+		palette_mem_size = fbi->palette_size * sizeof(u16);
+	else
+		palette_mem_size = fbi->palette_size * sizeof(u32);
 
 	pr_debug("pxafb: palette_mem_size = 0x%08lx\n", palette_mem_size);
 
@@ -676,7 +697,13 @@
 
 	fbi->dmadesc_palette_cpu->fsadr = fbi->palette_dma;
 	fbi->dmadesc_palette_cpu->fidr  = 0;
-	fbi->dmadesc_palette_cpu->ldcmd = (fbi->palette_size * 2) | LDCMD_PAL;
+	if ((fbi->lccr4 & LCCR4_PAL_FOR_MASK) == LCCR4_PAL_FOR_0)
+		fbi->dmadesc_palette_cpu->ldcmd = fbi->palette_size *
+							sizeof(u16);
+	else
+		fbi->dmadesc_palette_cpu->ldcmd = fbi->palette_size *
+							sizeof(u32);
+	fbi->dmadesc_palette_cpu->ldcmd |= LDCMD_PAL;
 
 	if (var->bits_per_pixel == 16) {
 		/* palette shouldn't be loaded in true-color mode */
@@ -715,6 +742,8 @@
 	fbi->reg_lccr1 = new_regs.lccr1;
 	fbi->reg_lccr2 = new_regs.lccr2;
 	fbi->reg_lccr3 = new_regs.lccr3;
+	fbi->reg_lccr4 = LCCR4 & (~LCCR4_PAL_FOR_MASK);
+	fbi->reg_lccr4 |= (fbi->lccr4 & LCCR4_PAL_FOR_MASK);
 	set_hsync_time(fbi, pcd);
 	local_irq_restore(flags);
 
@@ -821,6 +850,7 @@
 	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);
+	pr_debug("LCCR4 0x%08x\n", (unsigned int) LCCR4);
 }
 
 static void pxafb_disable_controller(struct pxafb_info *fbi)
@@ -1090,10 +1120,13 @@
 		 * dma_writecombine_mmap)
 		 */
 		fbi->fb.fix.smem_start = fbi->screen_dma;
-
 		fbi->palette_size = fbi->fb.var.bits_per_pixel == 8 ? 256 : 16;
 
-		palette_mem_size = fbi->palette_size * sizeof(u16);
+		if ((fbi->lccr4 & LCCR4_PAL_FOR_MASK) == LCCR4_PAL_FOR_0)
+			palette_mem_size = fbi->palette_size * sizeof(u16);
+		else
+			palette_mem_size = fbi->palette_size * sizeof(u32);
+
 		pr_debug("pxafb: palette_mem_size = 0x%08lx\n", palette_mem_size);
 
 		fbi->palette_cpu = (u16 *)(fbi->map_cpu + PAGE_SIZE - palette_mem_size);
@@ -1150,6 +1183,7 @@
 
 	fbi->lccr0			= inf->lccr0;
 	fbi->lccr3			= inf->lccr3;
+	fbi->lccr4			= inf->lccr4;
 	fbi->state			= C_STARTUP;
 	fbi->task_state			= (u_char)-1;
 
Index: linux-2.6.22-rc/drivers/video/pxafb.h
===================================================================
--- linux-2.6.22-rc.orig/drivers/video/pxafb.h	2007-04-26 05:08:32.000000000 +0200
+++ linux-2.6.22-rc/drivers/video/pxafb.h	2007-07-03 15:46:20.000000000 +0200
@@ -70,6 +70,7 @@
 
 	u_int			lccr0;
 	u_int			lccr3;
+	u_int			lccr4;
 	u_int			cmap_inverse:1,
 				cmap_static:1,
 				unused:30;
@@ -78,6 +79,7 @@
 	u_int			reg_lccr1;
 	u_int			reg_lccr2;
 	u_int			reg_lccr3;
+	u_int			reg_lccr4;
 
 	unsigned long	hsync_time;
 
Index: linux-2.6.22-rc/include/asm-arm/arch-pxa/pxafb.h
===================================================================
--- linux-2.6.22-rc.orig/include/asm-arm/arch-pxa/pxafb.h	2007-04-26 05:08:32.000000000 +0200
+++ linux-2.6.22-rc/include/asm-arm/arch-pxa/pxafb.h	2007-07-03 15:46:20.000000000 +0200
@@ -70,7 +70,12 @@
 	 *      LCCR3_HSP, LCCR3_VSP, LCCR0_Pcd(x), LCCR3_Bpp
 	 */
 	u_int		lccr3;
-
+	/* The following should be defined in LCCR4
+	 *	LCCR4_PAL_FOR_0 or LCCR4_PAL_FOR_1 or LCCR4_PAL_FOR_2
+	 *
+	 * All other bits in LCCR4 should be left alone.
+	 */
+	u_int		lccr4;
 	void (*pxafb_backlight_power)(int);
 	void (*pxafb_lcd_power)(int, struct fb_var_screeninfo *);
 

-------------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[Paulo Marques]

Hans-Jürgen Koch wrote:
> This patch adds support for the other three palette formats possible with 
> the PXA LCD controller. This is required on boards where an LCD is connected
> with all its 18 bits. With this patch, it's possible to use an 8-bit mode
> with 18-bit palette entries.

I've been working on getting the non-palletized 18bpp modes working and 
had a preliminar patch that just didn't support packed mode yet (using 
24 bits per pixel).

We can either apply this patch as is and I'll just merge my work later, 
or I can try to merge both patches and send a single patch upstream. 
Either way is fine by me.

For what is worth, this patch seems ok to me as is:

Acked-by: Paulo Marques <pmarques@grupopie.com>

-- 
Paulo Marques - www.grupopie.com

"Very funny Scotty. Now beam up my clothes."

-------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[Hans-Jürgen Koch]

Am Dienstag 03 Juli 2007 16:46 schrieb Paulo Marques:
> Hans-Jürgen Koch wrote:
> > This patch adds support for the other three palette formats possible with 
> > the PXA LCD controller. This is required on boards where an LCD is connected
> > with all its 18 bits. With this patch, it's possible to use an 8-bit mode
> > with 18-bit palette entries.
> 
> I've been working on getting the non-palletized 18bpp modes working and 
> had a preliminar patch that just didn't support packed mode yet (using 
> 24 bits per pixel).

Can userspace applications work with such a weired format?
If yes, I'm looking forward to your patch.

> 
> We can either apply this patch as is and I'll just merge my work later, 
> or I can try to merge both patches and send a single patch upstream. 
> Either way is fine by me.

It's probably cleaner to merge two small patches than a big one.

> 
> For what is worth, this patch seems ok to me as is:
> 
> Acked-by: Paulo Marques <pmarques@grupopie.com>
> 

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: [PATCH] pxafb: Add support for other palette formats

[Paulo Marques]

Hans-Jürgen Koch wrote:
> Am Dienstag 03 Juli 2007 16:46 schrieb Paulo Marques:
>> [...]
>> I've been working on getting the non-palletized 18bpp modes working and 
>> had a preliminar patch that just didn't support packed mode yet (using 
>> 24 bits per pixel).
> 
> Can userspace applications work with such a weired format?
> If yes, I'm looking forward to your patch.

It is not really that weird: rgb is packed 6 bits per component into 18 
bits. Those 18 bits will then occupy the lower bits of a 24 bit value or 
a 32 bit value depending on using packed or unpacked mode.

I'm doing this for the OpenEZX project to handle some motorola phones 
that have 18bpp support.

Motorola uses this mode in their software, so I suppose Qt already 
supports it.

Nevertheless, it seems a really big waste to have such a colorful 
display and then just use a palletized frame-buffer :P

So, if there are some userspace applications not supporting this mode, 
we should address them, but the support has to be in the kernel first... :(

>> We can either apply this patch as is and I'll just merge my work later, 
>> or I can try to merge both patches and send a single patch upstream. 
>> Either way is fine by me.
> 
> It's probably cleaner to merge two small patches than a big one.

Ok. It is also less stressful for me, too ;)

-- 
Paulo Marques - www.grupopie.com

"All I ask is a chance to prove that money can't make me happy."

-------------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[Lothar Wassmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

Hi,

> Can userspace applications work with such a weired format?
> If yes, I'm looking forward to your patch.
> 
At least framebuffer consoles don't work with that. So you should
add a configuration option that allows enabling the strange PXA pixel
formats only when CONFIG_FRAMEBUFFER_CONSOLE is not set.

BTW: PXA255 doesn't have an LCCR4 register.


Lothar Wassmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra���e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch���ftsf���hrer: Matthias Kaussen, Rolf Rosenstein
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________


[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [PATCH] pxafb: Add support for other palette formats

[Geert Uytterhoeven]

On Tue, 3 Jul 2007, Lothar Wassmann wrote:
> > Can userspace applications work with such a weired format?
> > If yes, I'm looking forward to your patch.
> > 
> At least framebuffer consoles don't work with that. So you should
> add a configuration option that allows enabling the strange PXA pixel
> formats only when CONFIG_FRAMEBUFFER_CONSOLE is not set.

Of course framebuffer consoles handle that!

Just make sure to implement proper fb_ops.fb_{fillrect,copyarea,imageblit}().

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-------------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[Antonino A. Daplas]

On Tue, 2007-07-03 at 17:58 +0200, Geert Uytterhoeven wrote:
> On Tue, 3 Jul 2007, Lothar Wassmann wrote:
> > > Can userspace applications work with such a weired format?
> > > If yes, I'm looking forward to your patch.
> > > 
> > At least framebuffer consoles don't work with that. So you should
> > add a configuration option that allows enabling the strange PXA pixel
> > formats only when CONFIG_FRAMEBUFFER_CONSOLE is not set.
> 
> Of course framebuffer consoles handle that!
> 
> Just make sure to implement proper fb_ops.fb_{fillrect,copyarea,imageblit}().

As long as it is in packed-pixel format, the generic drawing libraries
should be able to handle that.  Make sure that info->pseudo_palette[] is
correctly filled.

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/

Re: [PATCH] pxafb: Add support for other palette formats

[Antonino A. Daplas]

On Thu, 2007-07-12 at 15:56 +0800, Antonino A. Daplas wrote:
> On Tue, 2007-07-03 at 17:58 +0200, Geert Uytterhoeven wrote:
> > On Tue, 3 Jul 2007, Lothar Wassmann wrote:
> > > > Can userspace applications work with such a weired format?
> > > > If yes, I'm looking forward to your patch.
> > > > 
> > > At least framebuffer consoles don't work with that. So you should
> > > add a configuration option that allows enabling the strange PXA pixel
> > > formats only when CONFIG_FRAMEBUFFER_CONSOLE is not set.
> > 
> > Of course framebuffer consoles handle that!
> > 
> > Just make sure to implement proper fb_ops.fb_{fillrect,copyarea,imageblit}().
> 
> As long as it is in packed-pixel format, the generic drawing libraries
> should be able to handle that.  Make sure that info->pseudo_palette[] is
> correctly filled.

My mistake, copyarea and fillrect won't be able to handle that, but
imageblit should.

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/

Re: [PATCH] pxafb: Add support for other palette formats

[Paulo Marques]

Lothar Wassmann wrote:
> Hi,
> 
>> Can userspace applications work with such a weired format?
>> If yes, I'm looking forward to your patch.
>>
> At least framebuffer consoles don't work with that. So you should
> add a configuration option that allows enabling the strange PXA pixel
> formats only when CONFIG_FRAMEBUFFER_CONSOLE is not set.

Or maybe teach fbcon to use 18bpp modes?

> BTW: PXA255 doesn't have an LCCR4 register.

If we make sure that we don't touch LCCR4 registers unless the platform 
driver asks for 18bpp we should be in the clear, no?

However, the current patch does write to LCCR4 without checking this, 
but this should be a no-op if there is no register there, AFAICS.

I'll try to handle it more correctly in my next patch, anyway.

-- 
Paulo Marques - www.grupopie.com

"You're just jealous because the voices only talk to me."

-------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[Hans-Jürgen Koch]

Am Dienstag 03 Juli 2007 18:03 schrieb Paulo Marques:
> Lothar Wassmann wrote:
> > Hi,
> > 
> >> Can userspace applications work with such a weired format?
> >> If yes, I'm looking forward to your patch.
> >>
> > At least framebuffer consoles don't work with that. So you should
> > add a configuration option that allows enabling the strange PXA pixel
> > formats only when CONFIG_FRAMEBUFFER_CONSOLE is not set.
> 
> Or maybe teach fbcon to use 18bpp modes?

This would only make sense if this is a common format that other
chips use, too.

> 
> > BTW: PXA255 doesn't have an LCCR4 register.
> 
> If we make sure that we don't touch LCCR4 registers unless the platform 
> driver asks for 18bpp we should be in the clear, no?
> 
> However, the current patch does write to LCCR4 without checking this, 
> but this should be a no-op if there is no register there, AFAICS.

Arrg, no, you can't do this. Even if it works on your current PXA255
revision, writing to a nonexistent register is certainly not something
we should do in a proper driver.

> 
> I'll try to handle it more correctly in my next patch, anyway.
>

So will I. I'll update my patch.

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: [PATCH] pxafb: Add support for other palette formats

[Paulo Marques]

Hans-Jürgen Koch wrote:
> Am Dienstag 03 Juli 2007 18:03 schrieb Paulo Marques:
>> [...]
>> Or maybe teach fbcon to use 18bpp modes?
> 
> This would only make sense if this is a common format that other
> chips use, too.

I don't see this as a good reason not to implement 18bpp support in 
fbcon. "Just PXA270 18bpp devices" can be a lot of devices out there.

Anyway, can fbcon work with 18bpp palette mode? If it does, then this 
should be enough for most users of 18bpp pxafb users: have a console 
with a palette mode and then switch to non-palette mode and run whatever 
windowing system supports 18bpp.

I guess that even if it doesn't support 18bpp palette mode now, it 
shouldn't be that hard to implement (nor should it cause that much bloat 
to fbcon).

>>> BTW: PXA255 doesn't have an LCCR4 register.
>> If we make sure that we don't touch LCCR4 registers unless the platform 
>> driver asks for 18bpp we should be in the clear, no?
>>
>> However, the current patch does write to LCCR4 without checking this, 
>> but this should be a no-op if there is no register there, AFAICS.
> 
> Arrg, no, you can't do this. Even if it works on your current PXA255
> revision, writing to a nonexistent register is certainly not something
> we should do in a proper driver.

Yes, I wasn't proposing that this be kept (that would be waaay too 
ugly), only pointing out that it shouldn't crash existing setups.

>> I'll try to handle it more correctly in my next patch, anyway.
> 
> So will I. I'll update my patch.

Ok.

-- 
Paulo Marques - www.grupopie.com

"God is real, unless declared integer."

-------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[Hans-Jürgen Koch]

Am Dienstag 03 Juli 2007 19:21 schrieb Paulo Marques:
> Hans-Jürgen Koch wrote:
> > Am Dienstag 03 Juli 2007 18:03 schrieb Paulo Marques:
> >> [...]
> >> Or maybe teach fbcon to use 18bpp modes?
> > 
> > This would only make sense if this is a common format that other
> > chips use, too.
> 
> I don't see this as a good reason not to implement 18bpp support in 
> fbcon. "Just PXA270 18bpp devices" can be a lot of devices out there.

I guess most hardware developers will connect their LCD with only
16-bit, use RGB565, and are happy with that. It's a pity that this
requires a physically different wiring of the LCD.

> 
> Anyway, can fbcon work with 18bpp palette mode? If it does, then this 
> should be enough for most users of 18bpp pxafb users: have a console 
> with a palette mode and then switch to non-palette mode and run whatever 
> windowing system supports 18bpp.

I need to run gtk-directfb, and I'd be surprised if libcairo could handle
that...

> 
> I guess that even if it doesn't support 18bpp palette mode now, it 
> shouldn't be that hard to implement (nor should it cause that much bloat 
> to fbcon).

fbcon is not the big problem. But there's a lot of userspace stuff out there
where they create graphics in their own buffers and blit it into the 
framebuffer when ready. Most of them are definitely not prepared to support
this format.

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: [PATCH] pxafb: Add support for other palette formats

[Paulo Marques]

Hans-Jürgen Koch wrote:
> Am Dienstag 03 Juli 2007 19:21 schrieb Paulo Marques:
>> [...]
>> I don't see this as a good reason not to implement 18bpp support in 
>> fbcon. "Just PXA270 18bpp devices" can be a lot of devices out there.
> 
> I guess most hardware developers will connect their LCD with only
> 16-bit, use RGB565, and are happy with that. It's a pity that this
> requires a physically different wiring of the LCD.

Yes, this is not an option for me or all the OpenEZX users/developers 
with 18bpp phones :(

>> Anyway, can fbcon work with 18bpp palette mode? If it does, then this 
>> should be enough for most users of 18bpp pxafb users: have a console 
>> with a palette mode and then switch to non-palette mode and run whatever 
>> windowing system supports 18bpp.
> 
> I need to run gtk-directfb, and I'd be surprised if libcairo could handle
> that...

I wouldn't be so surprised... at least the documentation of DirectFB has 
this:

   DFBSurfacePixelFormat:
      ....
      DSPF_RGB18 ->  6 bit RGB (3 byte/ red 6@16, green 6@6, blue 6@0)
      ....

I assume the "red 6@16" is a typo for "red 6@12", since the "3 byte / 
green 6@6 and blue 6@0" match exactly the 18bpp packed format. Even 
more, the "DSPF_ARGB6666" format is described as having "alpha 6@18" and 
"red 6@16" which is of course impossible. It only makes sense as "red 6@12".

So maybe this is supposed to work with DirectFB...

>> I guess that even if it doesn't support 18bpp palette mode now, it 
>> shouldn't be that hard to implement (nor should it cause that much bloat 
>> to fbcon).
> 
> fbcon is not the big problem. But there's a lot of userspace stuff out there
> where they create graphics in their own buffers and blit it into the 
> framebuffer when ready. Most of them are definitely not prepared to support
> this format.

If we can't provide a 18bpp pxafb kernel driver, then there is *no* 
userspace stuff that will be able to work.

At least "some userspace" will be better than "no userspace". And we can 
always use the power of open-source to bring 18bpp support to those apps 
that don't support it currently ;)

-- 
Paulo Marques - www.grupopie.com

"The Computer made me do it."

-------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[Lothar Wassmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

Hi,

> I assume the "red 6@16" is a typo for "red 6@12", since the "3 byte / 
> green 6@6 and blue 6@0" match exactly the 18bpp packed format. Even 
> 
Take a closer look at the actual pixel format of the PXA270.
The usual graphics packages AFAIK support either packed pixels
(i.e. 18 bit on screen => 18 bit in memory) or unpacked (i.e. 18/24
or whatever bits => 32 bit in memory).
The PXA supports either the unpacked pixel format (which is a waste of
memory especially on embedded systems) or a strange format which is
neither: 18bit on screen in 24bit in memory (IOW 4 pixels in 3
words in memory).


Lothar Wassmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra���e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch���ftsf���hrer: Matthias Kaussen, Rolf Rosenstein
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________


[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [PATCH] pxafb: Add support for other palette formats

[Paulo Marques]

Lothar Wassmann wrote:
> Hi,

Hi,

>> I assume the "red 6@16" is a typo for "red 6@12", since the "3 byte / 
>> green 6@6 and blue 6@0" match exactly the 18bpp packed format. Even 
>>
> Take a closer look at the actual pixel format of the PXA270.
> The usual graphics packages AFAIK support either packed pixels
> (i.e. 18 bit on screen => 18 bit in memory)

This mode would be quite insane: 16 pixels in 9 words?  :P

No, I don't think there are graphics packages out there supporting this 
mode.

> or unpacked (i.e. 18/24
> or whatever bits => 32 bit in memory).
> The PXA supports either the unpacked pixel format (which is a waste of
> memory especially on embedded systems) 

...but is very good for alignment. Access to any individual pixel is 
always aligned on a 4 byte boundary. So, I guess it depends on the 
application.

> or a strange format which is
> neither: 18bit on screen in 24bit in memory (IOW 4 pixels in 3
> words in memory).

Take a closer look at my post, specially at the "3 byte" part. The mode 
supported by DirectFB is really the packed mode of the PXA270: 18bit on 
screen in 24bit in memory.

-- 
Paulo Marques - www.grupopie.com

"All I ask is a chance to prove that money can't make me happy."

-------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[Lothar Wassmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Hi,

> should be enough for most users of 18bpp pxafb users: have a console 
> with a palette mode and then switch to non-palette mode and run whatever 
> windowing system supports 18bpp.
> 
For this to work the pxafb driver would need to support switching
video modes first (reallocating framebuffer memory when the size
changes) which is not the case currently.


Lothar Wassmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra���e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch���ftsf���hrer: Matthias Kaussen, Rolf Rosenstein
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________


[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [PATCH] pxafb: Add support for other palette formats

[Hans-Jürgen Koch]

Am Dienstag 03 Juli 2007 17:50 schrieb Lothar Wassmann:

> 
> BTW: PXA255 doesn't have an LCCR4 register.

In that case I should insert some #ifdef CONFIG_PXA27x to have the
new behaviour only on PXA270, right?

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: [PATCH] pxafb: Add support for other palette formats

[Lothar Wassmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

Hi,

> > BTW: PXA255 doesn't have an LCCR4 register.
> 
> In that case I should insert some #ifdef CONFIG_PXA27x to have the
> new behaviour only on PXA270, right?
>
This would be incompatible with the efforts to have the same kernel
binary running on PXA25x as well as PXA27x.

Either check the cpuid or as Paulo mentioned just check if the
platform has defined a value for LCCR4 and assume that the platform
code knows when to specify it and when not.


Lothar Wassmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra���e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch���ftsf���hrer: Matthias Kaussen, Rolf Rosenstein
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________


[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [PATCH] pxafb: Add support for other palette formats

[Hans-Jürgen Koch]

Am Dienstag 03 Juli 2007 19:14 schrieb Lothar Wassmann:
> Hi,
> 
> > > BTW: PXA255 doesn't have an LCCR4 register.
> > 
> > In that case I should insert some #ifdef CONFIG_PXA27x to have the
> > new behaviour only on PXA270, right?
> >
> This would be incompatible with the efforts to have the same kernel
> binary running on PXA25x as well as PXA27x.

OK, I see.

> 
> Either check the cpuid 

This is probably the right way to go if you actually want the binary
to run on both platforms.

> or as Paulo mentioned just check if the 
> platform has defined a value for LCCR4 and assume that the platform
> code knows when to specify it and when not.

Well, my patch adds this definition to pxa_regs.h. Anyway, this solution
also decides at compile time where the binary will run.

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: [PATCH] pxafb: Add support for other palette formats

[Antonino A. Daplas]

On Tue, 2007-07-03 at 17:03 +0200, Hans-Jürgen Koch wrote:
> Am Dienstag 03 Juli 2007 16:46 schrieb Paulo Marques:
> > Hans-Jürgen Koch wrote:

> > We can either apply this patch as is and I'll just merge my work later, 
> > or I can try to merge both patches and send a single patch upstream. 
> > Either way is fine by me.
> 
> It's probably cleaner to merge two small patches than a big one.
> 

What should I do with this? Should I push this to akpm, or should I wait
for a merge?

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: [PATCH] pxafb: Add support for other palette formats

[Hans-Jürgen Koch]

Am Freitag 13 Juli 2007 14:20 schrieb Antonino A. Daplas:
> On Tue, 2007-07-03 at 17:03 +0200, Hans-Jürgen Koch wrote:
> > Am Dienstag 03 Juli 2007 16:46 schrieb Paulo Marques:
> > > Hans-Jürgen Koch wrote:
> 
> > > We can either apply this patch as is and I'll just merge my work later, 
> > > or I can try to merge both patches and send a single patch upstream. 
> > > Either way is fine by me.
> > 
> > It's probably cleaner to merge two small patches than a big one.
> > 
> 
> What should I do with this? Should I push this to akpm, or should I wait
> for a merge?

My palette format patch is completely independent of Paulo's true-color work.
I'd be glad if you could push it.

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: [PATCH] pxafb: Add support for other palette formats

[Clemens Koller]

Hans-Jürgen Koch schrieb:
> Index: linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h
> ===================================================================
> --- linux-2.6.22-rc.orig/include/asm-arm/arch-pxa/pxa-regs.h	2007-06-29 17:45:00.000000000 +0200
> +++ linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h	2007-07-03 15:46:20.000000000 +0200
> @@ -1843,6 +1843,7 @@
>  #define LCCR1		__REG(0x44000004)  /* LCD Controller Control Register 1 */
>  #define LCCR2		__REG(0x44000008)  /* LCD Controller Control Register 2 */
>  #define LCCR3		__REG(0x4400000C)  /* LCD Controller Control Register 3 */
> +#define LCCR4		__REG(0x44000010)  /* LCD Controller Control Register 3 */

little typo...                                                                      ^^^^^

Regards,
-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19

-------------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[Hans-Jürgen Koch]

Am Dienstag 03 Juli 2007 21:01 schrieb Clemens Koller:
> Hans-Jürgen Koch schrieb:
> > Index: linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h
> > ===================================================================
> > --- linux-2.6.22-rc.orig/include/asm-arm/arch-pxa/pxa-regs.h	2007-06-29 17:45:00.000000000 +0200
> > +++ linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h	2007-07-03 15:46:20.000000000 +0200
> > @@ -1843,6 +1843,7 @@
> >  #define LCCR1		__REG(0x44000004)  /* LCD Controller Control Register 1 */
> >  #define LCCR2		__REG(0x44000008)  /* LCD Controller Control Register 2 */
> >  #define LCCR3		__REG(0x4400000C)  /* LCD Controller Control Register 3 */
> > +#define LCCR4		__REG(0x44000010)  /* LCD Controller Control Register 3 */
> 
> little typo...                                                                      ^^^^^

No, classical copy'n'paste error :-)

Thanks, fixed. Although I don't know yet if I'm allowed to define a 
PXA27x-only register in pxa-regs.h, any comments about that?

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: [PATCH] pxafb: Add support for other palette formats

[Hans-Jürgen Koch]

All right, next iteration.

Changes:
If cpuid says it's not a PXA27x, palette format is forced to 0 (which
is the old 16-bit RGB565 format), and the driver will not access LCCR4.

Signed-off-by: Hans J. Koch <hjk@linutronix.de>

Index: linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h
===================================================================
--- linux-2.6.22-rc.orig/include/asm-arm/arch-pxa/pxa-regs.h	2007-07-03 22:27:19.000000000 +0200
+++ linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h	2007-07-03 22:28:22.000000000 +0200
@@ -1843,6 +1843,7 @@
 #define LCCR1		__REG(0x44000004)  /* LCD Controller Control Register 1 */
 #define LCCR2		__REG(0x44000008)  /* LCD Controller Control Register 2 */
 #define LCCR3		__REG(0x4400000C)  /* LCD Controller Control Register 3 */
+#define LCCR4		__REG(0x44000010)  /* LCD Controller Control Register 4 */
 #define DFBR0		__REG(0x44000020)  /* DMA Channel 0 Frame Branch Register */
 #define DFBR1		__REG(0x44000024)  /* DMA Channel 1 Frame Branch Register */
 #define LCSR		__REG(0x44000038)  /* LCD Controller Status Register */
@@ -1856,6 +1857,16 @@
 #define LCCR3_8BPP (3 << 24)
 #define LCCR3_16BPP (4 << 24)
 
+#define LCCR3_PDFOR_0 (0 << 30)
+#define LCCR3_PDFOR_1 (1 << 30)
+#define LCCR3_PDFOR_2 (2 << 30)
+#define LCCR3_PDFOR_3 (3 << 30)
+
+#define LCCR4_PAL_FOR_0 (0 << 15)
+#define LCCR4_PAL_FOR_1 (1 << 15)
+#define LCCR4_PAL_FOR_2 (2 << 15)
+#define LCCR4_PAL_FOR_MASK (3 << 15)
+
 #define FDADR0		__REG(0x44000200)  /* DMA Channel 0 Frame Descriptor Address Register */
 #define FSADR0		__REG(0x44000204)  /* DMA Channel 0 Frame Source Address Register */
 #define FIDR0		__REG(0x44000208)  /* DMA Channel 0 Frame ID Register */
Index: linux-2.6.22-rc/drivers/video/pxafb.c
===================================================================
--- linux-2.6.22-rc.orig/drivers/video/pxafb.c	2007-07-03 22:27:19.000000000 +0200
+++ linux-2.6.22-rc/drivers/video/pxafb.c	2007-07-03 22:28:22.000000000 +0200
@@ -106,20 +106,38 @@
 		       u_int trans, struct fb_info *info)
 {
 	struct pxafb_info *fbi = (struct pxafb_info *)info;
-	u_int val, ret = 1;
+	u_int val;
 
-	if (regno < fbi->palette_size) {
-		if (fbi->fb.var.grayscale) {
-			val = ((blue >> 8) & 0x00ff);
-		} else {
-			val  = ((red   >>  0) & 0xf800);
-			val |= ((green >>  5) & 0x07e0);
-			val |= ((blue  >> 11) & 0x001f);
-		}
+	if (regno >= fbi->palette_size)
+		return 1;
+
+	if (fbi->fb.var.grayscale) {
+		fbi->palette_cpu[regno] = ((blue >> 8) & 0x00ff);
+		return 0;
+	}
+
+	switch (fbi->lccr4 & LCCR4_PAL_FOR_MASK) {
+	case LCCR4_PAL_FOR_0:
+		val  = ((red   >>  0) & 0xf800);
+		val |= ((green >>  5) & 0x07e0);
+		val |= ((blue  >> 11) & 0x001f);
 		fbi->palette_cpu[regno] = val;
-		ret = 0;
+		break;
+	case LCCR4_PAL_FOR_1:
+		val  = ((red   << 8) & 0x00f80000);
+		val |= ((green >> 0) & 0x0000fc00);
+		val |= ((blue  >> 8) & 0x000000f8);
+		((u32*)(fbi->palette_cpu))[regno] = val;
+		break;
+	case LCCR4_PAL_FOR_2:
+		val  = ((red   << 8) & 0x00fc0000);
+		val |= ((green >> 0) & 0x0000fc00);
+		val |= ((blue  >> 8) & 0x000000fc);
+		((u32*)(fbi->palette_cpu))[regno] = val;
+		break;
 	}
-	return ret;
+
+	return 0;
 }
 
 static int
@@ -361,7 +379,10 @@
 	else
 		fbi->palette_size = var->bits_per_pixel == 1 ? 4 : 1 << var->bits_per_pixel;
 
-	palette_mem_size = fbi->palette_size * sizeof(u16);
+	if ((fbi->lccr4 & LCCR4_PAL_FOR_MASK) == LCCR4_PAL_FOR_0)
+		palette_mem_size = fbi->palette_size * sizeof(u16);
+	else
+		palette_mem_size = fbi->palette_size * sizeof(u32);
 
 	pr_debug("pxafb: palette_mem_size = 0x%08lx\n", palette_mem_size);
 
@@ -676,7 +697,13 @@
 
 	fbi->dmadesc_palette_cpu->fsadr = fbi->palette_dma;
 	fbi->dmadesc_palette_cpu->fidr  = 0;
-	fbi->dmadesc_palette_cpu->ldcmd = (fbi->palette_size * 2) | LDCMD_PAL;
+	if ((fbi->lccr4 & LCCR4_PAL_FOR_MASK) == LCCR4_PAL_FOR_0)
+		fbi->dmadesc_palette_cpu->ldcmd = fbi->palette_size *
+							sizeof(u16);
+	else
+		fbi->dmadesc_palette_cpu->ldcmd = fbi->palette_size *
+							sizeof(u32);
+	fbi->dmadesc_palette_cpu->ldcmd |= LDCMD_PAL;
 
 	if (var->bits_per_pixel == 16) {
 		/* palette shouldn't be loaded in true-color mode */
@@ -715,6 +742,15 @@
 	fbi->reg_lccr1 = new_regs.lccr1;
 	fbi->reg_lccr2 = new_regs.lccr2;
 	fbi->reg_lccr3 = new_regs.lccr3;
+
+	if (((read_cpuid(CPUID_ID) >> 4) & 0x1f) == 0x11) {
+		/* PXA 27x only */
+		fbi->reg_lccr4 = LCCR4 & (~LCCR4_PAL_FOR_MASK);
+		fbi->reg_lccr4 |= (fbi->lccr4 & LCCR4_PAL_FOR_MASK);
+	}
+	else {
+		fbi->reg_lccr4 = 0;
+	}
 	set_hsync_time(fbi, pcd);
 	local_irq_restore(flags);
 
@@ -806,6 +842,8 @@
 	pxa_set_cken(CKEN_LCD, 1);
 
 	/* Sequence from 11.7.10 */
+	if (((read_cpuid(CPUID_ID) >> 4) & 0x1f) == 0x11)
+		LCCR4 = fbi->reg_lccr4; /* PXA 27x only */
 	LCCR3 = fbi->reg_lccr3;
 	LCCR2 = fbi->reg_lccr2;
 	LCCR1 = fbi->reg_lccr1;
@@ -1090,10 +1128,13 @@
 		 * dma_writecombine_mmap)
 		 */
 		fbi->fb.fix.smem_start = fbi->screen_dma;
-
 		fbi->palette_size = fbi->fb.var.bits_per_pixel == 8 ? 256 : 16;
 
-		palette_mem_size = fbi->palette_size * sizeof(u16);
+		if ((fbi->lccr4 & LCCR4_PAL_FOR_MASK) == LCCR4_PAL_FOR_0)
+			palette_mem_size = fbi->palette_size * sizeof(u16);
+		else
+			palette_mem_size = fbi->palette_size * sizeof(u32);
+
 		pr_debug("pxafb: palette_mem_size = 0x%08lx\n", palette_mem_size);
 
 		fbi->palette_cpu = (u16 *)(fbi->map_cpu + PAGE_SIZE - palette_mem_size);
@@ -1150,6 +1191,11 @@
 
 	fbi->lccr0			= inf->lccr0;
 	fbi->lccr3			= inf->lccr3;
+	if (((read_cpuid(CPUID_ID) >> 4) & 0x1f) == 0x11)
+		fbi->lccr4 = inf->lccr4; /* PXA27x only */
+	else
+		fbi->lccr4 = 0;
+
 	fbi->state			= C_STARTUP;
 	fbi->task_state			= (u_char)-1;
 
Index: linux-2.6.22-rc/drivers/video/pxafb.h
===================================================================
--- linux-2.6.22-rc.orig/drivers/video/pxafb.h	2007-07-03 22:27:19.000000000 +0200
+++ linux-2.6.22-rc/drivers/video/pxafb.h	2007-07-03 22:28:22.000000000 +0200
@@ -70,6 +70,7 @@
 
 	u_int			lccr0;
 	u_int			lccr3;
+	u_int			lccr4;
 	u_int			cmap_inverse:1,
 				cmap_static:1,
 				unused:30;
@@ -78,6 +79,7 @@
 	u_int			reg_lccr1;
 	u_int			reg_lccr2;
 	u_int			reg_lccr3;
+	u_int			reg_lccr4;
 
 	unsigned long	hsync_time;
 
Index: linux-2.6.22-rc/include/asm-arm/arch-pxa/pxafb.h
===================================================================
--- linux-2.6.22-rc.orig/include/asm-arm/arch-pxa/pxafb.h	2007-07-03 22:27:19.000000000 +0200
+++ linux-2.6.22-rc/include/asm-arm/arch-pxa/pxafb.h	2007-07-03 22:28:22.000000000 +0200
@@ -70,7 +70,12 @@
 	 *      LCCR3_HSP, LCCR3_VSP, LCCR0_Pcd(x), LCCR3_Bpp
 	 */
 	u_int		lccr3;
-
+	/* The following should be defined in LCCR4
+	 *	LCCR4_PAL_FOR_0 or LCCR4_PAL_FOR_1 or LCCR4_PAL_FOR_2
+	 *
+	 * All other bits in LCCR4 should be left alone.
+	 */
+	u_int		lccr4;
 	void (*pxafb_backlight_power)(int);
 	void (*pxafb_lcd_power)(int, struct fb_var_screeninfo *);
 



-------------------------------------------------------------------------
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: [PATCH] pxafb: Add support for other palette formats

[eric miao]

Hans-Jürgen Koch wrote:
> All right, next iteration.
> 
> Changes:
> If cpuid says it's not a PXA27x, palette format is forced to 0 (which
> is the old 16-bit RGB565 format), and the driver will not access LCCR4.
> 
> Signed-off-by: Hans J. Koch <hjk@linutronix.de>
> 
> Index: linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h
> ===================================================================
> --- linux-2.6.22-rc.orig/include/asm-arm/arch-pxa/pxa-regs.h	2007-07-03 22:27:19.000000000 +0200
> +++ linux-2.6.22-rc/include/asm-arm/arch-pxa/pxa-regs.h	2007-07-03 22:28:22.000000000 +0200
> @@ -1843,6 +1843,7 @@
>  #define LCCR1		__REG(0x44000004)  /* LCD Controller Control Register 1 */
>  #define LCCR2		__REG(0x44000008)  /* LCD Controller Control Register 2 */
>  #define LCCR3		__REG(0x4400000C)  /* LCD Controller Control Register 3 */
> +#define LCCR4		__REG(0x44000010)  /* LCD Controller Control Register 4 */
>  #define DFBR0		__REG(0x44000020)  /* DMA Channel 0 Frame Branch Register */
>  #define DFBR1		__REG(0x44000024)  /* DMA Channel 1 Frame Branch Register */
>  #define LCSR		__REG(0x44000038)  /* LCD Controller Status Register */
> @@ -1856,6 +1857,16 @@
>  #define LCCR3_8BPP (3 << 24)
>  #define LCCR3_16BPP (4 << 24)
>  
> +#define LCCR3_PDFOR_0 (0 << 30)
> +#define LCCR3_PDFOR_1 (1 << 30)
> +#define LCCR3_PDFOR_2 (2 << 30)
> +#define LCCR3_PDFOR_3 (3 << 30)
> +
> +#define LCCR4_PAL_FOR_0 (0 << 15)
> +#define LCCR4_PAL_FOR_1 (1 << 15)
> +#define LCCR4_PAL_FOR_2 (2 << 15)
> +#define LCCR4_PAL_FOR_MASK (3 << 15)
> +
>  #define FDADR0		__REG(0x44000200)  /* DMA Channel 0 Frame Descriptor Address Register */
>  #define FSADR0		__REG(0x44000204)  /* DMA Channel 0 Frame Source Address Register */
>  #define FIDR0		__REG(0x44000208)  /* DMA Channel 0 Frame ID Register */

I think we may better surround that PXA27x specific definitions using
the #ifdef..#endif stuff, to make sure that we are not accessing those
registers if only PXA25x is defined, compiler will catch this and give
an early warning, and another good thing of doing this is that we know
how to separate these definitions into different files, suppose one day
we are going to make this pxa-regs.h much cleaner :-)

> Index: linux-2.6.22-rc/drivers/video/pxafb.c
> ===================================================================
> --- linux-2.6.22-rc.orig/drivers/video/pxafb.c	2007-07-03 22:27:19.000000000 +0200
> +++ linux-2.6.22-rc/drivers/video/pxafb.c	2007-07-03 22:28:22.000000000 +0200
> @@ -106,20 +106,38 @@
>  		       u_int trans, struct fb_info *info)
>  {
>  	struct pxafb_info *fbi = (struct pxafb_info *)info;
> -	u_int val, ret = 1;
> +	u_int val;
>  
> -	if (regno < fbi->palette_size) {
> -		if (fbi->fb.var.grayscale) {
> -			val = ((blue >> 8) & 0x00ff);
> -		} else {
> -			val  = ((red   >>  0) & 0xf800);
> -			val |= ((green >>  5) & 0x07e0);
> -			val |= ((blue  >> 11) & 0x001f);
> -		}
> +	if (regno >= fbi->palette_size)
> +		return 1;
> +
> +	if (fbi->fb.var.grayscale) {
> +		fbi->palette_cpu[regno] = ((blue >> 8) & 0x00ff);
> +		return 0;
> +	}
> +
> +	switch (fbi->lccr4 & LCCR4_PAL_FOR_MASK) {
> +	case LCCR4_PAL_FOR_0:
> +		val  = ((red   >>  0) & 0xf800);
> +		val |= ((green >>  5) & 0x07e0);
> +		val |= ((blue  >> 11) & 0x001f);
>  		fbi->palette_cpu[regno] = val;
> -		ret = 0;
> +		break;
> +	case LCCR4_PAL_FOR_1:
> +		val  = ((red   << 8) & 0x00f80000);
> +		val |= ((green >> 0) & 0x0000fc00);
> +		val |= ((blue  >> 8) & 0x000000f8);
> +		((u32*)(fbi->palette_cpu))[regno] = val;
> +		break;
> +	case LCCR4_PAL_FOR_2:
> +		val  = ((red   << 8) & 0x00fc0000);
> +		val |= ((green >> 0) & 0x0000fc00);
> +		val |= ((blue  >> 8) & 0x000000fc);
> +		((u32*)(fbi->palette_cpu))[regno] = val;
> +		break;
>  	}
> -	return ret;
> +
> +	return 0;
>  }

Can we also set the transparency bit along with RGB? I'm not sure if any
weird applications will use the transparency bit in palette mode, but I
think it is already there and easy to add.

>  
>  static int
> @@ -361,7 +379,10 @@
>  	else
>  		fbi->palette_size = var->bits_per_pixel == 1 ? 4 : 1 << var->bits_per_pixel;
>  
> -	palette_mem_size = fbi->palette_size * sizeof(u16);
> +	if ((fbi->lccr4 & LCCR4_PAL_FOR_MASK) == LCCR4_PAL_FOR_0)
> +		palette_mem_size = fbi->palette_size * sizeof(u16);
> +	else
> +		palette_mem_size = fbi->palette_size * sizeof(u32);
>  
>  	pr_debug("pxafb: palette_mem_size = 0x%08lx\n", palette_mem_size);
>  
> @@ -676,7 +697,13 @@
>  
>  	fbi->dmadesc_palette_cpu->fsadr = fbi->palette_dma;
>  	fbi->dmadesc_palette_cpu->fidr  = 0;
> -	fbi->dmadesc_palette_cpu->ldcmd = (fbi->palette_size * 2) | LDCMD_PAL;
> +	if ((fbi->lccr4 & LCCR4_PAL_FOR_MASK) == LCCR4_PAL_FOR_0)
> +		fbi->dmadesc_palette_cpu->ldcmd = fbi->palette_size *
> +							sizeof(u16);
> +	else
> +		fbi->dmadesc_palette_cpu->ldcmd = fbi->palette_size *
> +							sizeof(u32);
> +	fbi->dmadesc_palette_cpu->ldcmd |= LDCMD_PAL;
>  
>  	if (var->bits_per_pixel == 16) {
>  		/* palette shouldn't be loaded in true-color mode */
> @@ -715,6 +742,15 @@
>  	fbi->reg_lccr1 = new_regs.lccr1;
>  	fbi->reg_lccr2 = new_regs.lccr2;
>  	fbi->reg_lccr3 = new_regs.lccr3;
> +
> +	if (((read_cpuid(CPUID_ID) >> 4) & 0x1f) == 0x11) {
> +		/* PXA 27x only */
> +		fbi->reg_lccr4 = LCCR4 & (~LCCR4_PAL_FOR_MASK);
> +		fbi->reg_lccr4 |= (fbi->lccr4 & LCCR4_PAL_FOR_MASK);
> +	}
> +	else {
> +		fbi->reg_lccr4 = 0;
> +	}

Russell has a couple of cpu_is_pxa25x() and cpu_is_pxa27x() macros ready
for use, it will be merged into the mainline soon.

>  	set_hsync_time(fbi, pcd);
>  	local_irq_restore(flags);
>  
> @@ -806,6 +842,8 @@
>  	pxa_set_cken(CKEN_LCD, 1);
>  
>  	/* Sequence from 11.7.10 */
> +	if (((read_cpuid(CPUID_ID) >> 4) & 0x1f) == 0x11)
> +		LCCR4 = fbi->reg_lccr4; /* PXA 27x only */
>  	LCCR3 = fbi->reg_lccr3;
>  	LCCR2 = fbi->reg_lccr2;
>  	LCCR1 = fbi->reg_lccr1;
> @@ -1090,10 +1128,13 @@
>  		 * dma_writecombine_mmap)
>  		 */
>  		fbi->fb.fix.smem_start = fbi->screen_dma;
> -
>  		fbi->palette_size = fbi->fb.var.bits_per_pixel == 8 ? 256 : 16;
>  
> -		palette_mem_size = fbi->palette_size * sizeof(u16);
> +		if ((fbi->lccr4 & LCCR4_PAL_FOR_MASK) == LCCR4_PAL_FOR_0)
> +			palette_mem_size = fbi->palette_size * sizeof(u16);
> +		else
> +			palette_mem_size = fbi->palette_size * sizeof(u32);
> +
>  		pr_debug("pxafb: palette_mem_size = 0x%08lx\n", palette_mem_size);
>  
>  		fbi->palette_cpu = (u16 *)(fbi->map_cpu + PAGE_SIZE - palette_mem_size);
> @@ -1150,6 +1191,11 @@
>  
>  	fbi->lccr0			= inf->lccr0;
>  	fbi->lccr3			= inf->lccr3;
> +	if (((read_cpuid(CPUID_ID) >> 4) & 0x1f) == 0x11)
> +		fbi->lccr4 = inf->lccr4; /* PXA27x only */
> +	else
> +		fbi->lccr4 = 0;
> +
>  	fbi->state			= C_STARTUP;
>  	fbi->task_state			= (u_char)-1;
>  
> Index: linux-2.6.22-rc/drivers/video/pxafb.h
> ===================================================================
> --- linux-2.6.22-rc.orig/drivers/video/pxafb.h	2007-07-03 22:27:19.000000000 +0200
> +++ linux-2.6.22-rc/drivers/video/pxafb.h	2007-07-03 22:28:22.000000000 +0200
> @@ -70,6 +70,7 @@
>  
>  	u_int			lccr0;
>  	u_int			lccr3;
> +	u_int			lccr4;
>  	u_int			cmap_inverse:1,
>  				cmap_static:1,
>  				unused:30;
> @@ -78,6 +79,7 @@
>  	u_int			reg_lccr1;
>  	u_int			reg_lccr2;
>  	u_int			reg_lccr3;
> +	u_int			reg_lccr4;
>  
>  	unsigned long	hsync_time;
>  
> Index: linux-2.6.22-rc/include/asm-arm/arch-pxa/pxafb.h
> ===================================================================
> --- linux-2.6.22-rc.orig/include/asm-arm/arch-pxa/pxafb.h	2007-07-03 22:27:19.000000000 +0200
> +++ linux-2.6.22-rc/include/asm-arm/arch-pxa/pxafb.h	2007-07-03 22:28:22.000000000 +0200
> @@ -70,7 +70,12 @@
>  	 *      LCCR3_HSP, LCCR3_VSP, LCCR0_Pcd(x), LCCR3_Bpp
>  	 */
>  	u_int		lccr3;
> -
> +	/* The following should be defined in LCCR4
> +	 *	LCCR4_PAL_FOR_0 or LCCR4_PAL_FOR_1 or LCCR4_PAL_FOR_2
> +	 *
> +	 * All other bits in LCCR4 should be left alone.
> +	 */
> +	u_int		lccr4;
>  	void (*pxafb_backlight_power)(int);
>  	void (*pxafb_lcd_power)(int, struct fb_var_screeninfo *);
>  

another thing I'm curious is there any specific reason that
LCCR4_PAL_FOR_3 format is not added in your patch?

- eric

> 
> 
> -------------------------------------------------------------------
> 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: [PATCH] pxafb: Add support for other palette formats

[Lothar Wassmann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

Hi,

> +#define LCCR4_PAL_FOR_0 (0 << 15)
> +#define LCCR4_PAL_FOR_1 (1 << 15)
> +#define LCCR4_PAL_FOR_2 (2 << 15)
> +#define LCCR4_PAL_FOR_MASK (3 << 15)
>
Just a minor nitpicking. I would prefer names which represent the
_meaning_ of the constants rather than duplicating their value in the
name, like:
#define LCCR4_PALFOR_16		(0 << 15) /* 16 palette, 16 bit output */
#define LCCR4_PALFOR_16_T	(1 << 15) /* 25 bit palette, 16 bit output +transp. */
#define LCCR4_PALFOR_18		(2 << 15) /* 25 bit palette, 18 bit output */
#define LCCR4_PALFOR_24		(3 << 15) /* 25 bit palette, 24 bit output */


Lothar Wassmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra���e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch���ftsf���hrer: Matthias Kaussen, Rolf Rosenstein
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________


[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel