[PATCH] clgenfb on PPC

[PATCH] clgenfb on PPC

[Tom Rini]

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

Hey all.  While going through the 2.4 tree and removing dead CONFIG_xxx's for
PPC stuff, I noticed clgenfb still had CONFIG_PREP stuff (which may have
partily explained why it no longer worked here).  I've attached a patch, that
with another patch to fix some PCI issues on certain machines, gives me a
working (so far, can't test heavily yet tho) framebuffer on my powerstack.

Comments?

Also, rivafb needs something similar to this, but since no PReP boxes I know
of anyways ship with something rivafb controlls, it's probably easier to just
remove the bits inside CONFIG_PREP

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

[-- Attachment #2: clgenfb.patch --]
[-- Type: text/plain, Size: 6239 bytes --]

# This is a BitKeeper generated patch for the following project:
# Project Name: 
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.393.1.12 -> 1.393.1.13
#	drivers/video/clgenfb.c	1.19    -> 1.20   
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 00/12/27	trini@entropy.crashing.org	1.393.1.13
# Fix up clgenfb.
# --------------------------------------------
#
diff -Nru a/drivers/video/clgenfb.c b/drivers/video/clgenfb.c
--- a/drivers/video/clgenfb.c	Tue Jan  2 09:42:09 2001
+++ b/drivers/video/clgenfb.c	Tue Jan  2 09:42:09 2001
@@ -56,6 +56,12 @@
 #ifdef CONFIG_AMIGA
 #include <asm/amigahw.h>
 #endif
+#ifdef CONFIG_ALL_PPC
+#include <asm/processor.h>
+#define isPReP (_machine == _MACH_prep)
+#else
+#define isPReP 0
+#endif
 
 #include <video/fbcon.h>
 #include <video/fbcon-mfb.h>
@@ -876,15 +882,15 @@
 	case 16:
 		_par->line_length = _par->var.xres_virtual * 2;
 		_par->visual = FB_VISUAL_DIRECTCOLOR;
-#ifdef CONFIG_PREP
-		_par->var.red.offset = 2;
-		_par->var.green.offset = -3;
-		_par->var.blue.offset = 8;
-#else
-		_par->var.red.offset = 10;
-		_par->var.green.offset = 5;
-		_par->var.blue.offset = 0;
-#endif
+		if(isPReP) {
+			_par->var.red.offset = 2;
+			_par->var.green.offset = -3;
+			_par->var.blue.offset = 8;
+		} else {
+			_par->var.red.offset = 10;
+			_par->var.green.offset = 5;
+			_par->var.blue.offset = 0;
+		}
 		_par->var.red.length = 5;
 		_par->var.green.length = 5;
 		_par->var.blue.length = 5;
@@ -893,15 +899,15 @@
 	case 24:
 		_par->line_length = _par->var.xres_virtual * 3;
 		_par->visual = FB_VISUAL_DIRECTCOLOR;
-#ifdef CONFIG_PREP
-		_par->var.red.offset = 8;
-		_par->var.green.offset = 16;
-		_par->var.blue.offset = 24;
-#else
-		_par->var.red.offset = 16;
-		_par->var.green.offset = 8;
-		_par->var.blue.offset = 0;
-#endif
+		if(isPReP) {
+			_par->var.red.offset = 8;
+			_par->var.green.offset = 16;
+			_par->var.blue.offset = 24;
+		} else {
+			_par->var.red.offset = 16;
+			_par->var.green.offset = 8;
+			_par->var.blue.offset = 0;
+		}
 		_par->var.red.length = 8;
 		_par->var.green.length = 8;
 		_par->var.blue.length = 8;
@@ -910,15 +916,15 @@
 	case 32:
 		_par->line_length = _par->var.xres_virtual * 4;
 		_par->visual = FB_VISUAL_DIRECTCOLOR;
-#ifdef CONFIG_PREP
-		_par->var.red.offset = 8;
-		_par->var.green.offset = 16;
-		_par->var.blue.offset = 24;
-#else
-		_par->var.red.offset = 16;
-		_par->var.green.offset = 8;
-		_par->var.blue.offset = 0;
-#endif
+		if(isPReP) {
+			_par->var.red.offset = 8;
+			_par->var.green.offset = 16;
+			_par->var.blue.offset = 24;
+		} else {
+			_par->var.red.offset = 16;
+			_par->var.green.offset = 8;
+			_par->var.blue.offset = 0;
+		}
 		_par->var.red.length = 8;
 		_par->var.green.length = 8;
 		_par->var.blue.length = 8;
@@ -1680,18 +1686,18 @@
 #ifdef FBCON_HAS_CFB16
 	case 16:
 		assert (regno < 16);
-#ifdef CONFIG_PREP
-		fb_info->fbcon_cmap.cfb16[regno] =
-		    ((red & 0xf800) >> 9) |
-		    ((green & 0xf800) >> 14) |
-		    ((green & 0xf800) << 2) |
-		    ((blue & 0xf800) >> 3);
-#else
-		fb_info->fbcon_cmap.cfb16[regno] =
-		    ((red & 0xf800) >> 1) |
-		    ((green & 0xf800) >> 6) |
-		    ((blue & 0xf800) >> 11);
-#endif
+		if(isPReP) {
+			fb_info->fbcon_cmap.cfb16[regno] =
+			    ((red & 0xf800) >> 9) |
+			    ((green & 0xf800) >> 14) |
+			    ((green & 0xf800) << 2) |
+			    ((blue & 0xf800) >> 3);
+		} else {
+			fb_info->fbcon_cmap.cfb16[regno] =
+			    ((red & 0xf800) >> 1) |
+			    ((green & 0xf800) >> 6) |
+			    ((blue & 0xf800) >> 11);
+		}
 #endif /* FBCON_HAS_CFB16 */
 
 #ifdef FBCON_HAS_CFB24
@@ -1707,17 +1713,17 @@
 #ifdef FBCON_HAS_CFB32
 	case 32:
 		assert (regno < 16);
-#ifdef CONFIG_PREP
-		fb_info->fbcon_cmap.cfb32[regno] =
-		    ((red & 0xff00)) |
-		    ((green & 0xff00) << 8) |
-		    ((blue & 0xff00) << 16);
-#else
-		fb_info->fbcon_cmap.cfb32[regno] =
-		    ((red & 0xff00) << 8) |
-		    ((green & 0xff00)) |
-		    ((blue & 0xff00) >> 8);
-#endif
+		if(isPReP) {
+			fb_info->fbcon_cmap.cfb32[regno] =
+			    ((red & 0xff00)) |
+			    ((green & 0xff00) << 8) |
+			    ((blue & 0xff00) << 16);
+		} else {
+			fb_info->fbcon_cmap.cfb32[regno] =
+			    ((red & 0xff00) << 8) |
+			    ((green & 0xff00)) |
+			    ((blue & 0xff00) >> 8);
+		}
 		break;
 #endif /* FBCON_HAS_CFB32 */
 	default:
@@ -2374,7 +2380,7 @@
 
 
 
-#ifdef CONFIG_PREP
+#ifdef CONFIG_ALL_PPC
 #define PREP_VIDEO_BASE ((volatile unsigned long) 0xC0000000)
 #define PREP_IO_BASE    ((volatile unsigned char *) 0x80000000)
 static void __init get_prep_addrs (unsigned long *display, unsigned long *registers)
@@ -2387,7 +2393,7 @@
 	DPRINTK ("EXIT\n");
 }
 
-#endif				/* CONFIG_PREP */
+#endif				/* CONFIG_ALL_PPC */
 
 
 
@@ -2510,26 +2516,24 @@
 
 	info->pdev = pdev;
 
-#ifdef CONFIG_PREP
-	/* Xbh does this, though 0 seems to be the init value */
-	pcibios_write_config_dword (0, pdev->devfn, PCI_BASE_ADDRESS_0, 0x00000000);
-#endif
+	if(isPReP) {
+		/* Xbh does this, though 0 seems to be the init value */
+		pcibios_write_config_dword (0, pdev->devfn, PCI_BASE_ADDRESS_0,
+			0x00000000);
 
-#ifdef CONFIG_PREP
-	get_prep_addrs (&board_addr, &info->fbregs_phys);
-#else				/* CONFIG_PREP */
-	DPRINTK ("Attempt to get PCI info for Cirrus Graphics Card\n");
-	get_pci_addrs (pdev, &board_addr, &info->fbregs_phys);
-#endif				/* CONFIG_PREP */
+		get_prep_addrs (&board_addr, &info->fbregs_phys);
+	} else {
+		DPRINTK ("Attempt to get PCI info for Cirrus Graphics Card\n");
+		get_pci_addrs (pdev, &board_addr, &info->fbregs_phys);
+	}
 
 	DPRINTK ("Board address: 0x%lx, register address: 0x%lx\n", board_addr, info->fbregs_phys);
 
-#ifdef CONFIG_PREP
-	/* PReP dies if we ioremap the IO registers, but it works w/out... */
-	info->regs = (char *) info->fbregs_phys;
-#else
-	info->regs = 0;		/* FIXME: this forces VGA.  alternatives? */
-#endif
+	if(isPReP) {
+		/* PReP dies if we ioremap the IO registers, but it works w/out... */
+		info->regs = (char *) info->fbregs_phys;
+	} else
+		info->regs = 0;		/* FIXME: this forces VGA.  alternatives? */
 
 	if (*btype == BT_GD5480) {
 		board_size = 32 * MB_;

Re: [linux-fbdev] [PATCH] clgenfb on PPC

[Geert Uytterhoeven]

On Tue, 2 Jan 2001, Tom Rini wrote:
> Hey all.  While going through the 2.4 tree and removing dead CONFIG_xxx's for
> PPC stuff, I noticed clgenfb still had CONFIG_PREP stuff (which may have
> partily explained why it no longer worked here).  I've attached a patch, that
> with another patch to fix some PCI issues on certain machines, gives me a
> working (so far, can't test heavily yet tho) framebuffer on my powerstack.
> 
> Comments?

To me it looks like most of them depend on `big endian', not on `PReP'.

BTW, doesn't the Cirrus Logic graphics chip have a big endian aperture? I don't
like things like green.offset = -3, since it will probably break some
applications (did you run X?).

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-fbdev] [PATCH] clgenfb on PPC

[Tom Rini]

On Wed, Jan 03, 2001 at 01:50:46PM +0100, Geert Uytterhoeven wrote:
> On Tue, 2 Jan 2001, Tom Rini wrote:
> > Hey all.  While going through the 2.4 tree and removing dead CONFIG_xxx's for
> > PPC stuff, I noticed clgenfb still had CONFIG_PREP stuff (which may have
> > partily explained why it no longer worked here).  I've attached a patch, that
> > with another patch to fix some PCI issues on certain machines, gives me a
> > working (so far, can't test heavily yet tho) framebuffer on my powerstack.
> > 
> > Comments?
> 
> To me it looks like most of them depend on `big endian', not on `PReP'.

Well, I was trying to base things off the prior logic.

> BTW, doesn't the Cirrus Logic graphics chip have a big endian aperture? I 
> don't like things like green.offset = -3, since it will probably break some
> applications (did you run X?).

Nope, I still need to NFS root the machine to try.  I'm also wondering tho
if on ppc anything other than Xbh (the Xserver writtten for these machines)
will even work.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-fbdev] [PATCH] clgenfb on PPC

[Tom Rini]

On Wed, Jan 03, 2001 at 01:50:46PM +0100, Geert Uytterhoeven wrote:
> On Tue, 2 Jan 2001, Tom Rini wrote:
> > Hey all.  While going through the 2.4 tree and removing dead CONFIG_xxx's for
> > PPC stuff, I noticed clgenfb still had CONFIG_PREP stuff (which may have
> > partily explained why it no longer worked here).  I've attached a patch, that
> > with another patch to fix some PCI issues on certain machines, gives me a
> > working (so far, can't test heavily yet tho) framebuffer on my powerstack.
> > 
> > Comments?
> 
> To me it looks like most of them depend on `big endian', not on `PReP'.

Possibly...  I don't have or know anyone with the MacPicasso video card,
which is the only other card which may have this. :)

> BTW, doesn't the Cirrus Logic graphics chip have a big endian aperture? I 
> don't like things like green.offset = -3, since it will probably break some
> applications (did you run X?).

I finally got the machine up w/ an nfsroot, and played around a bit.  w/o the
patch (ie isPReP always 0) I don't get a console, but a few lines of pixels in
a row, and random pixels here and there.  Since the original logic was for
PReP only, I'm inclined to think that keeping it at just _machine == _MACH_prep
is the safest way to go, for the moment.

BTW, with or w/o the patch, XF4 (fbdev) wouldn't quite work right.  The logs 
didn't indicate anything wrong, but the monitor went black, like X was 
starting, but never did. (ShadowFB on / off)

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/