[PATCH] [2.5.21] CyberPro 32bit support and other fixes

[PATCH] [2.5.21] CyberPro 32bit support and other fixes

[Denis Oliver Kropp]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

Hi,

this patch adds 32 bit support to cyber2000fb which is useful
if you have a video layer in the background (CyberPro 5xxx) with
per pixel alpha blending enabled.

This patch also includes a fix for the text palette for modes
with more than 8 bit.

Applies against Linux 2.5.21.

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH

[-- Attachment #2: linux-2.5.21-cyber32bit.diff --]
[-- Type: text/plain, Size: 5556 bytes --]

diff -uraN linux-2.5.21/CREDITS linux-2.5.21-cyber32bit/CREDITS
--- linux-2.5.21/CREDITS	Thu Jun 13 08:31:27 2002
+++ linux-2.5.21-cyber32bit/CREDITS	Thu Jun 13 09:43:01 2002
@@ -1677,6 +1677,7 @@
 N: Denis O. Kropp
 E: dok@directfb.org
 D: NeoMagic framebuffer driver
+D: CyberPro 32 bit support, fixes
 S: Badensche Str. 46
 S: 10715 Berlin
 S: Germany
diff -uraN linux-2.5.21/drivers/video/Config.in linux-2.5.21-cyber32bit/drivers/video/Config.in
--- linux-2.5.21/drivers/video/Config.in	Thu Jun 13 08:31:34 2002
+++ linux-2.5.21-cyber32bit/drivers/video/Config.in	Thu Jun 13 09:29:43 2002
@@ -348,7 +348,7 @@
 	   "$CONFIG_FB_RIVA" = "y" -o "$CONFIG_FB_ATY128" = "y" -o \
 	   "$CONFIG_FB_SIS" = "y" -o "$CONFIG_FB_SGIVW" = "y" -o \
 	   "$CONFIG_FB_RADEON" = "y" -o "$CONFIG_FB_PVR2" = "y" -o \
-	   "$CONFIG_FB_PM3" = "y" ]; then
+	   "$CONFIG_FB_PM3" = "y" -o "$CONFIG_FB_CYBER2000" = "y" ]; then
 	 define_tristate CONFIG_FBCON_CFB32 y
       else
 	 if [ "$CONFIG_FB_ATARI" = "m" -o "$CONFIG_FB_ATY" = "m" -o \
@@ -359,7 +359,7 @@
 	      "$CONFIG_FB_RIVA" = "m" -o "$CONFIG_FB_ATY128" = "m" -o \
 	      "$CONFIG_FB_PM3" = "m" -o "$CONFIG_FB_RADEON" = "m" -o \
 	      "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_SIS" = "m" -o \
-	      "$CONFIG_FB_PVR2" = "m" ]; then
+	      "$CONFIG_FB_PVR2" = "m" -o "$CONFIG_FB_CYBER2000" = "m" ]; then
 	    define_tristate CONFIG_FBCON_CFB32 m
 	 fi
       fi
diff -uraN linux-2.5.21/drivers/video/cyber2000fb.c linux-2.5.21-cyber32bit/drivers/video/cyber2000fb.c
--- linux-2.5.21/drivers/video/cyber2000fb.c	Thu Jun 13 08:31:34 2002
+++ linux-2.5.21-cyber32bit/drivers/video/cyber2000fb.c	Thu Jun 13 09:47:00 2002
@@ -6,11 +6,14 @@
  *  MIPS and 50xx clock support
  *  Copyright (C) 2001 Bradley D. LaRonde <brad@ltc.com>
  *
+ *  32 bit support, text color fixes for modes != 8 bit
+ *  Copyright (C) 2002 Denis Oliver Kropp <dok@directfb.org>
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  *
- * Integraphics CyberPro 2000, 2010 and 5000 frame buffer device
+ * Intergraphics CyberPro 2000, 2010 and 5000 frame buffer device
  *
  * Based on cyberfb.c.
  *
@@ -49,6 +52,7 @@
 #include <video/fbcon-cfb8.h>
 #include <video/fbcon-cfb16.h>
 #include <video/fbcon-cfb24.h>
+#include <video/fbcon-cfb32.h>
 
 /*
  * Define this if you don't want RGB565, but RGB555 for 16bpp displays.
@@ -247,6 +251,11 @@
 		cyber2000fb_writeb(dst, CO_REG_X_PHASE, cfb);
 		bgx = ((u32 *)display->dispsw_data)[bgx];
 		break;
+
+	case 32:
+		bgx = ((u32 *)display->dispsw_data)[bgx];
+		cyber2000fb_writel(dst, CO_REG_DEST_PTR, cfb);
+		break;
 	}
 
 	cyber2000fb_writel(bgx, CO_REG_FOREGROUND, cfb);
@@ -312,12 +321,15 @@
 	struct cfb_info *cfb = (struct cfb_info *)info;
 	struct fb_var_screeninfo *var = &cfb->display->var;
 
+	u_int alpha = transp ^ 0xFFFF;
+
 	if (regno >= NR_PALETTE)
 		return 1;
 
 	red   >>= 8;
 	green >>= 8;
 	blue  >>= 8;
+	alpha >>= 8;
 
 	cfb->palette[regno].red   = red;
 	cfb->palette[regno].green = green;
@@ -355,7 +367,9 @@
 
 			if (regno < 16)
 				((u16 *)cfb->fb.pseudo_palette)[regno] =
-					regno | regno << 5 | regno << 11;
+					((red   << 8) & 0xf800) |
+					((green << 3) & 0x07e0) |
+					((blue  >> 3));
 			break;
 		}
 #endif
@@ -367,7 +381,9 @@
 		}
 		if (regno < 16)
 			((u16 *)cfb->fb.pseudo_palette)[regno] =
-				regno | regno << 5 | regno << 10;
+				((red   << 7) & 0x7c00) |
+				((green << 2) & 0x03e0) |
+				((blue  >> 3));
 		break;
 
 #endif
@@ -381,7 +397,20 @@
 
 		if (regno < 16)
 			((u32 *)cfb->fb.pseudo_palette)[regno] =
-				regno | regno << 8 | regno << 16;
+				(red << 16) | (green << 8) | blue;
+		break;
+#endif
+
+#ifdef FBCON_HAS_CFB32
+	case 32:
+		cyber2000fb_writeb(regno, 0x3c8, cfb);
+		cyber2000fb_writeb(red,   0x3c9, cfb);
+		cyber2000fb_writeb(green, 0x3c9, cfb);
+		cyber2000fb_writeb(blue,  0x3c9, cfb);
+
+		if (regno < 16)
+			((u32 *)cfb->fb.pseudo_palette)[regno] =
+				(alpha << 24) | (red << 16) | (green << 8) | blue;
 		break;
 #endif
 
@@ -776,6 +805,14 @@
 		hw->palette_ctrl	|= 0x10;
 		break;
 #endif
+#ifdef FBCON_HAS_CFB32
+	case 32:/* TRUECOLOUR, 16m */
+		hw->pixformat		= PIXFORMAT_32BPP;
+		hw->extseqmisc		= EXT_SEQ_MISC_32;
+		hw->pitch		= hw->width >> 1;
+		hw->palette_ctrl	|= 0x10;
+		break;
+#endif
 	default:
 		return -EINVAL;
 	}
@@ -909,6 +946,23 @@
 		cfb->dispsw		= &fbcon_cfb24;
 		display->dispsw_data	= cfb->fb.pseudo_palette;
 		display->next_line	= var->xres_virtual * 3;
+		break;
+#endif
+#ifdef FBCON_HAS_CFB32
+	case 32:/* TRUECOLOUR, 16m */
+		var->transp.offset	= 24;
+		var->transp.length	= 8;
+		var->red.offset		= 16;
+		var->red.length		= 8;
+		var->green.offset	= 8;
+		var->green.length	= 8;
+		var->blue.offset	= 0;
+		var->blue.length	= 8;
+
+		cfb->fb.fix.visual	= FB_VISUAL_TRUECOLOR;
+		cfb->dispsw		= &fbcon_cfb32;
+		display->dispsw_data	= cfb->fb.pseudo_palette;
+		display->next_line	= var->xres_virtual * 4;
 		break;
 #endif
 	default:/* in theory this should never happen */
diff -uraN linux-2.5.21/drivers/video/cyber2000fb.h linux-2.5.21-cyber32bit/drivers/video/cyber2000fb.h
--- linux-2.5.21/drivers/video/cyber2000fb.h	Fri Jun  7 15:17:22 2002
+++ linux-2.5.21-cyber32bit/drivers/video/cyber2000fb.h	Thu Jun 13 09:35:23 2002
@@ -39,6 +39,7 @@
 #define PIXFORMAT_8BPP		0
 #define PIXFORMAT_16BPP		1
 #define PIXFORMAT_24BPP		2
+#define PIXFORMAT_32BPP		3
 
 #define EXT_CRT_IRQ		0x12
 #define EXT_CRT_IRQ_ENABLE		0x01

Re: [PATCH] [2.5.21] CyberPro 32bit support and other fixes

[Russell King]

On Thu, Jun 13, 2002 at 10:32:43AM +0200, Denis Oliver Kropp wrote:
> - * Integraphics CyberPro 2000, 2010 and 5000 frame buffer device
> + * Intergraphics CyberPro 2000, 2010 and 5000 frame buffer device

This isn't actually a spelling mistake.  The chips I have are quite
clearly marked "Integraphics" not "Intergraphics".

> @@ -355,7 +367,9 @@
>  
>  			if (regno < 16)
>  				((u16 *)cfb->fb.pseudo_palette)[regno] =
> -					regno | regno << 5 | regno << 11;
> +					((red   << 8) & 0xf800) |
> +					((green << 3) & 0x07e0) |
> +					((blue  >> 3));
>  			break;
>  		}
>  #endif

This seems wrong.  We're setting up the DAC palette to map pixel color
component 'regno' to 'read', 'green' and 'blue' respectively.

This means that the pseudopalette should be a 1:1 mapping of desired
colour value (ie, the 16 VGA colors) to the DAC palette entries -
the pseudopalette contains the pixel values to insert into the frame
buffer for each of the 16 VGA colors.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] [2.5.21] CyberPro 32bit support and other fixes

[Denis Oliver Kropp]

Quoting Russell King (rmk@arm.linux.org.uk):
> On Thu, Jun 13, 2002 at 10:32:43AM +0200, Denis Oliver Kropp wrote:
> > - * Integraphics CyberPro 2000, 2010 and 5000 frame buffer device
> > + * Intergraphics CyberPro 2000, 2010 and 5000 frame buffer device
> 
> This isn't actually a spelling mistake.  The chips I have are quite
> clearly marked "Integraphics" not "Intergraphics".

Ok, I'm sorry for that, seemed obvious.

> > @@ -355,7 +367,9 @@
> >  
> >  			if (regno < 16)
> >  				((u16 *)cfb->fb.pseudo_palette)[regno] =
> > -					regno | regno << 5 | regno << 11;
> > +					((red   << 8) & 0xf800) |
> > +					((green << 3) & 0x07e0) |
> > +					((blue  >> 3));
> >  			break;
> >  		}
> >  #endif
> 
> This seems wrong.  We're setting up the DAC palette to map pixel color
> component 'regno' to 'read', 'green' and 'blue' respectively.
> 
> This means that the pseudopalette should be a 1:1 mapping of desired
> colour value (ie, the 16 VGA colors) to the DAC palette entries -
> the pseudopalette contains the pixel values to insert into the frame
> buffer for each of the 16 VGA colors.

The palette is being bypassed anyway by setting bit 4 in palette_ctrl.
Besides that I tested the rgb modes on a CyberPro 5000 with and without
this fix. The text was dark gray (as expected) in 16bit and hardly
visible in 24bit.

Why is the pseudo palette used anyway? There's no speed benefit and
applications running in true/direct color would look wrong.

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH

Re: [PATCH] [2.5.21] CyberPro 32bit support and other fixes

[James Simmons]

> Why is the pseudo palette used anyway?

Its a fast way for the console to grab the proper console index color to
draw to the framebuffer. Otherwise we have to regenerate the color all the
time. Plus it is always endian code for us :-)

> There's no speed benefit and
> applications running in true/direct color would look wrong.

For userland no but for the kernel we do have a benifiet.

Re: [PATCH] [2.5.21] CyberPro 32bit support and other fixes

[Denis Oliver Kropp]

Quoting James Simmons (jsimmons@transvirtual.com):
> 
> > Why is the pseudo palette used anyway?
> 
> Its a fast way for the console to grab the proper console index color to
> draw to the framebuffer. Otherwise we have to regenerate the color all the
> time. Plus it is always endian code for us :-)

I didn't mean the array of colors for the console, but the usage of
the hardware palette for modes != 8 bit.

> > There's no speed benefit and
> > applications running in true/direct color would look wrong.
> 
> For userland no but for the kernel we do have a benifiet.

There's no speed benefit if you write "index|index|index" into the
framebuffer instead of "red|green|blue".

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH

Re: [PATCH] [2.5.21] CyberPro 32bit support and other fixes

[Russell King]

On Sat, Jun 15, 2002 at 12:55:47PM +0200, Denis Oliver Kropp wrote:
> > > There's no speed benefit and
> > > applications running in true/direct color would look wrong.
> > 
> > For userland no but for the kernel we do have a benifiet.
> 
> There's no speed benefit if you write "index|index|index" into the
> framebuffer instead of "red|green|blue".

You're actually asking the wrong question.  "Why is there such a thing as
directcolor" would be a better question.  After all, if there's no "speed
benefit" when why do manufacturers bother implementing it?

Could it be because it allows colours to be dynamically allocated?  Given
a "good enough" allocator which looks over your complete colour usage, you
could probably make better use of the available colours than truecolor
allows.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [PATCH] [2.5.21] CyberPro 32bit support and other fixes

[Denis Oliver Kropp]

Quoting Russell King (rmk@arm.linux.org.uk):
> On Sat, Jun 15, 2002 at 12:55:47PM +0200, Denis Oliver Kropp wrote:
> > > > There's no speed benefit and
> > > > applications running in true/direct color would look wrong.
> > > 
> > > For userland no but for the kernel we do have a benifiet.
> > 
> > There's no speed benefit if you write "index|index|index" into the
> > framebuffer instead of "red|green|blue".
> 
> You're actually asking the wrong question.  "Why is there such a thing as
> directcolor" would be a better question.  After all, if there's no "speed
> benefit" when why do manufacturers bother implementing it?
> 
> Could it be because it allows colours to be dynamically allocated?  Given
> a "good enough" allocator which looks over your complete colour usage, you
> could probably make better use of the available colours than truecolor
> allows.

I don't think that the text console with 16 different colors needs more
precision than 5 bits per color channel (speaking of RGB555).

However, using directcolor to have a gamma ramp in user space applications
seems quite useful.

Drivers should support both direct- and truecolor for all bit depths with
default to truecolor, otherwise applications would always have to setup
the palette.

Anyway, the current version of the cyber2000 driver reports directcolor
while programming the hardware for truecolor. I can do another patch
that keeps the directcolor feature along with the other fixes.

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH

Re: [PATCH] [2.5.21] CyberPro 32bit support and other fixes

[Geert Uytterhoeven]

On Sat, 15 Jun 2002, Denis Oliver Kropp wrote:
> Quoting James Simmons (jsimmons@transvirtual.com):
> > 
> > > Why is the pseudo palette used anyway?
> > 
> > Its a fast way for the console to grab the proper console index color to
> > draw to the framebuffer. Otherwise we have to regenerate the color all the
> > time. Plus it is always endian code for us :-)
> 
> I didn't mean the array of colors for the console, but the usage of
> the hardware palette for modes != 8 bit.
> 
> > > There's no speed benefit and
> > > applications running in true/direct color would look wrong.
> > 
> > For userland no but for the kernel we do have a benifiet.
> 
> There's no speed benefit if you write "index|index|index" into the
> framebuffer instead of "red|green|blue".

But it does allow to change the console palette without the need to redraw the
screen, just like for VGA text mode.

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