[PATCH] matroxfb as a module (PPC)

[PATCH] matroxfb as a module (PPC)

[Tom Rini]

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

Hello all.  I've recently been playing with modules on my PPC system, and
noticed that matroxfb doesn't work as a module, because of mac_vmode_to_par.
But, after looking at other drivers which did work (aty and aty128) I noticed
matroxfb was doing something it didn't need to be doing.
First, the code should never get compiled, if this is a module, and even then
the code only needs to be compiled on ALL_PPC (which is Pmac/PReP/CHRP).
Second, it's only valid to call the default_{vmode,cmode} code on a PMAC 
(tested on a pmac, and ran it by one of the IBM guys who agrees it shouldn't
break anything, but he's still working on making the machine boot to start
with. :))
Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
Finally, the VMODE_CHOOSE stuff is 0'ed out in atyfb with a comment about this
not actually working, so I removed it.

Comments?

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

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

===== drivers/video/matrox/matroxfb_base.c 1.13 vs edited =====
--- 1.13/drivers/video/matrox/matroxfb_base.c	Fri Dec 15 14:12:43 2000
+++ edited/drivers/video/matrox/matroxfb_base.c	Sun Dec 31 10:39:11 2000
@@ -1842,33 +1842,33 @@
 	}
 
 	/* FIXME: Where to move this?! */
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_ALL_PPC)
 #if defined(CONFIG_FB_COMPAT_XPMAC)
 	strcpy(ACCESS_FBINFO(matrox_name), "MTRX,");	/* OpenFirmware naming convension */
 	strncat(ACCESS_FBINFO(matrox_name), b->name, 26);
 	if (!console_fb_info)
 		console_fb_info = &ACCESS_FBINFO(fbcon);
 #endif
-	if ((xres <= 640) && (yres <= 480)) {
+#ifndef MODULE
+	if (_machine == _MACH_Pmac) {
 		struct fb_var_screeninfo var;
-		if (default_vmode == VMODE_NVRAM) {
-			default_vmode = nvram_read_byte(NV_VMODE);
-			if (default_vmode <= 0 || default_vmode > VMODE_MAX)
-				default_vmode = VMODE_CHOOSE;
-		}
 		if (default_vmode <= 0 || default_vmode > VMODE_MAX)
 			default_vmode = VMODE_640_480_60;
+#ifdef CONFIG_NVRAM
 		if (default_cmode == CMODE_NVRAM)
 			default_cmode = nvram_read_byte(NV_CMODE);
+#endif
 		if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
 			default_cmode = CMODE_8;
 		if (!mac_vmode_to_var(default_vmode, default_cmode, &var)) {
 			var.accel_flags = vesafb_defined.accel_flags;
 			var.xoffset = var.yoffset = 0;
-			vesafb_defined = var; /* Note: mac_vmode_to_var() doesnot set all parameters */
+			/* Note: mac_vmode_to_var() does not set all parameters */
+			vesafb_defined = var;
 		}
 	}
-#endif /* CONFIG_PPC */
+#endif /* !MODULE */
+#endif /* CONFIG_ALL_PPC */
 	vesafb_defined.xres_virtual = vesafb_defined.xres;
 	if (nopan) {
 		vesafb_defined.yres_virtual = vesafb_defined.yres;

Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)

[Geert Uytterhoeven]

On Wed, 3 Jan 2001, Tom Rini wrote:
> Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.

I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so
it will work automagically for all drivers on PowerMac.

I'd also like to remove the `vmode' and `cmode' `video=' arguments, in favor of
the archictecture-neutral `<xres>x<yres>[-<bpp>][@<refresh>]' and
`<name>[-<bpp>][@<refresh>]' arguments (which already work on mac, BTW).
You can already use `mac<vmode>' instead of `vmode:<vmode>'.

IMHO, the less PowerMac-specific code in _each_ driver, the better.

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] matroxfb as a module (PPC)

[Tom Rini]

On Wed, Jan 03, 2001 at 06:44:59PM +0100, Geert Uytterhoeven wrote:
> On Wed, 3 Jan 2001, Tom Rini wrote:
> > Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
> 
> I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so
> it will work automagically for all drivers on PowerMac.
> 
> I'd also like to remove the `vmode' and `cmode' `video=' arguments, in favor of
> the archictecture-neutral `<xres>x<yres>[-<bpp>][@<refresh>]' and
> `<name>[-<bpp>][@<refresh>]' arguments (which already work on mac, BTW).

Quite wonderfully, almost.  My monitor (ViewSonic G810) claims it can do
1280x1024@90, but when i boot with that on my x86 box, it comes up at 87.5
or so (and shifted to the left ~1 penguin).  But anyways..

> You can already use `mac<vmode>' instead of `vmode:<vmode>'.

Ah, is this documented anywhere?  I'm sure it'd make some peoples life
easier.

> IMHO, the less PowerMac-specific code in _each_ driver, the better.

I agree this sounds good.  I just think it's too late to do it now. :)

The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late
now to remove it) but documented as obsolete, and removed in 2.5.

-- 
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] matroxfb as a module (PPC)

[Geert Uytterhoeven]

On Wed, 3 Jan 2001, Tom Rini wrote:
> On Wed, Jan 03, 2001 at 06:44:59PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 3 Jan 2001, Tom Rini wrote:
> > > Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
> > 
> > I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so
> > it will work automagically for all drivers on PowerMac.
> > 
> > I'd also like to remove the `vmode' and `cmode' `video=' arguments, in favor of
> > the archictecture-neutral `<xres>x<yres>[-<bpp>][@<refresh>]' and
> > `<name>[-<bpp>][@<refresh>]' arguments (which already work on mac, BTW).
> 
> Quite wonderfully, almost.  My monitor (ViewSonic G810) claims it can do
> 1280x1024@90, but when i boot with that on my x86 box, it comes up at 87.5
> or so (and shifted to the left ~1 penguin).  But anyways..
> 
> > You can already use `mac<vmode>' instead of `vmode:<vmode>'.
> 
> Ah, is this documented anywhere?  I'm sure it'd make some peoples life
> easier.

It's not documented, but read macmodes.c and modedb.c. The Mac modes have names
`mac1' to `mac20', so they can be specified using the `<name>[-<bpp>]' syntax.

> > IMHO, the less PowerMac-specific code in _each_ driver, the better.
> 
> I agree this sounds good.  I just think it's too late to do it now. :)
> 
> The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late
> now to remove it) but documented as obsolete, and removed in 2.5.

Yep, too late for 2.4.0.

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/