Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
Tom Rini wrote:
On Mon, Dec 03, 2001 at 02:16:04PM +0100, Geert Uytterhoeven wrote:
On Sun, 2 Dec 2001, Martin Costabel wrote:
Paul Mackerras wrote:
Martin Costabel writes:
[]
So please try `cmode 1' instead of `cmode 16'.
These bits of code are always different still I think. Valkyriefb for
example parses 'cmode:{8,15,16}' and does CMODE_8 or CMODE_16. I
_think_ the userland tools did both 0/1/2 and 8/15/16/32 (24?).
I'll be happy to let my 6400 play the guinea pig, but I have to excuse
him until next week; I'm not at home right now.
--
Martin
Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
On Sun, 2 Dec 2001, Martin Costabel wrote:
Paul Mackerras wrote:
Martin Costabel writes:
For the valkyriefb driver on my Pmac 6400, I can confirm from a first
short test that it still works. This is with your patch applied to
today's 2.4.17-pre1-ben0 kernel.
Do you still have macos on the 6400? If so can you confirm whether,
Yes, I still have MacOS 8.6. No 9.x, though.
if you set the screen resolution and colour depth in macos, that the
value you have set in macos is the default that linux will use?
I did some tests with the 2 useful modes of the 6400: 1024x768x8bit at
72Hz (vmode 15, cmode 8) and 800x600x16bit at 60Hz (vmode 10, cmode 16).
The results, with or without Tom's patch, were the same as they always
were:
The vmode of MacOS is used by the Linux console; the cmode 16 is not
recognized, so instead of vmode 10 16 one always gets vmode 10 8 as
default. The log says
kernel: Monitor sense value = 0x62b, 6using video mode 10 and color
mode 0
video/macmodes.h:
| #define CMODE_8 0 /* 8 bits/pixel */
| #define CMODE_161 /* 16 (actually 15) bits/pixel */
| #define CMODE_322 /* 32 (actually 24) bits/pixel */
So please try `cmode 1' instead of `cmode 16'.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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
Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
Martin Costabel writes: For the valkyriefb driver on my Pmac 6400, I can confirm from a first short test that it still works. This is with your patch applied to today's 2.4.17-pre1-ben0 kernel. Do you still have macos on the 6400? If so can you confirm whether, if you set the screen resolution and colour depth in macos, that the value you have set in macos is the default that linux will use? The nvram locations that the video drivers look in for the default resolution and depth, 0x140f and 0x1410, were locations that I found empirically on a 7500 with a control display, and IIRC they also seemed to work with the platinum and probably the valkyrie as well. But from about when Apple started to use the ATI chips it seems that macos changed the way it stored the way it stores the defaults, and certainly now it is driver-dependent. Therefore unless someone can reverse-engineer how the macos ATI driver stores its defaults, I don't think there is any point having the nvram stuff in the atyfb driver, and it probably isn't doing any good in the matrox or imstt drivers either. Paul.
Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
On Fri, Dec 28, 2001 at 12:28:02PM +0100, Benjamin Herrenschmidt wrote: I _think_ the right solution is to hide the NVRAM vmode/cmode stuff in macmodes.c, so all drivers will automagically use it for the default video mode. The same with MAC monitor sense information, just pass it to mac_find_mode(). So mac_find_mode() should do this: - if default mode specified, try that - if MAC monitor sense specified, try that - if NVRAM, try that - fall back to default mode database walking No, the NVRAM stuff is driver dependant unfortunately. It's almost common among drivers for old stuffs like control, chips, etc..., but that is not the case for recent MacOS drivers. Apple no longer defines a single mode table, each video driver is now responsible to have it's own mecanism for that and for storing whatever proprety for saving the mode to nvram. In fact; the old nvram location is a hack that won't work in all cases as it's not in xpram any more, it's part of the device tree extension part of the nvram (persistent properties added to selected nodes of the device-tree). Wasn't there a tool to fiddle and store the vmode/cmode stuff into NVRAM tho which would probably work with all of the other cards? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/
Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
Paul Mackerras wrote: Martin Costabel writes: For the valkyriefb driver on my Pmac 6400, I can confirm from a first short test that it still works. This is with your patch applied to today's 2.4.17-pre1-ben0 kernel. Do you still have macos on the 6400? If so can you confirm whether, Yes, I still have MacOS 8.6. No 9.x, though. if you set the screen resolution and colour depth in macos, that the value you have set in macos is the default that linux will use? I did some tests with the 2 useful modes of the 6400: 1024x768x8bit at 72Hz (vmode 15, cmode 8) and 800x600x16bit at 60Hz (vmode 10, cmode 16). The results, with or without Tom's patch, were the same as they always were: The vmode of MacOS is used by the Linux console; the cmode 16 is not recognized, so instead of vmode 10 16 one always gets vmode 10 8 as default. The log says kernel: Monitor sense value = 0x62b, 6using video mode 10 and color mode 0 I think I never saw this differently. For 16bit color, I always had to either put video=valkyriefb:vmode:10,cmode:16 into the kernel args or say vmode 10 16 at the console (and then startx -- -depth 15 to get the right colors in X; -depth 16 gives weird colors). P.S. Rebooting into MacOS (first time for almost a year) seems to have cured the crashes I had yesterday, too. Weird. -- Martin
Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
Martin Costabel writes: I did some tests with the 2 useful modes of the 6400: 1024x768x8bit at 72Hz (vmode 15, cmode 8) and 800x600x16bit at 60Hz (vmode 10, cmode 16). The results, with or without Tom's patch, were the same as they always were: The vmode of MacOS is used by the Linux console; the cmode 16 is not recognized, so instead of vmode 10 16 one always gets vmode 10 8 as default. The log says kernel: Monitor sense value = 0x62b, 6using video mode 10 and color mode 0 Ben H has just pointed out to me that macos stores some extra device-tree properties in nvram, and uses that to store the default resolution and depth. For the control display, it uses a gprf property, 8 bytes long, and in fact the 2nd and 3rd bytes are what we are looking at. Unfortunately OF doesn't add the nvram properties to the device tree, but Ben seems to think we can add code to do that in the kernel. So it would be very interesting to see a dump of nvram on your machine with the screen set to the different resolution/depth settings in macos. Also, if you have the DisplayNameRegistry app under macos, open it and look at the properties on the valkyrie and see if there is one with a little chip icon (looks like a 6-legged insect to me but apparently it is supposed to be a chip :). Paul.
Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
Tom Rini wrote: Hello all. The following patches make slight changes to the vmode/cmode logic on a few fb drivers. Now everone consistantly only tries to get these modes from nvram if CONFIG_NVRAM is defined (otherwise a compile-time error on everyone but atyfb). On imsttfb I made the logic only executed on CONFIG_ALL_PPC, and removed USE_NV_MODES (which shouldn't be needed now). However, I have none of this hardware, and I remember some of these drivers being very touchy. So could people with this hardware apply the patch and let me know if it works still? For the valkyriefb driver on my Pmac 6400, I can confirm from a first short test that it still works. This is with your patch applied to today's 2.4.17-pre1-ben0 kernel. I am not testing it very extensively, because this kernel crashes on me as soon as pppd is started. Yesterday's 2.4.16-ben0 crashed when running ping. Even on my iBook, the 2.4.16 gave me an illegal lseek when trying to run ping (the 2.4.17-pre1 seems to work OK on the iBook). Since the 6400 is serving as an adsl router, I prefer to go back to the stable 2.4.0-pmac kernel from last January. -- Martin
Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
On Tue, 27 Nov 2001, Tom Rini wrote:
Hello all. The following patches make slight changes to the vmode/cmode
logic on a few fb drivers. Now everone consistantly only tries to get
these modes from nvram if CONFIG_NVRAM is defined (otherwise a
compile-time error on everyone but atyfb). On imsttfb I made the logic
only executed on CONFIG_ALL_PPC, and removed USE_NV_MODES (which
shouldn't be needed now). However, I have none of this hardware, and I
remember some of these drivers being very touchy. So could people with
this hardware apply the patch and let me know if it works still?
I _think_ the right solution is to hide the NVRAM vmode/cmode stuff in
macmodes.c, so all drivers will automagically use it for the default video
mode.
The same with MAC monitor sense information, just pass it to mac_find_mode().
So mac_find_mode() should do this:
- if default mode specified, try that
- if MAC monitor sense specified, try that
- if NVRAM, try that
- fall back to default mode database walking
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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
Re: [PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
I _think_ the right solution is to hide the NVRAM vmode/cmode stuff in macmodes.c, so all drivers will automagically use it for the default video mode. The same with MAC monitor sense information, just pass it to mac_find_mode(). So mac_find_mode() should do this: - if default mode specified, try that - if MAC monitor sense specified, try that - if NVRAM, try that - fall back to default mode database walking No, the NVRAM stuff is driver dependant unfortunately. It's almost common among drivers for old stuffs like control, chips, etc..., but that is not the case for recent MacOS drivers. Apple no longer defines a single mode table, each video driver is now responsible to have it's own mecanism for that and for storing whatever proprety for saving the mode to nvram. In fact; the old nvram location is a hack that won't work in all cases as it's not in xpram any more, it's part of the device tree extension part of the nvram (persistent properties added to selected nodes of the device-tree). Ben.
[PATCH] Minor changes to control/imstt/platinum/valkyrie/atyfb
Hello all. The following patches make slight changes to the vmode/cmode
logic on a few fb drivers. Now everone consistantly only tries to get
these modes from nvram if CONFIG_NVRAM is defined (otherwise a
compile-time error on everyone but atyfb). On imsttfb I made the logic
only executed on CONFIG_ALL_PPC, and removed USE_NV_MODES (which
shouldn't be needed now). However, I have none of this hardware, and I
remember some of these drivers being very touchy. So could people with
this hardware apply the patch and let me know if it works still?
Maintainers, does this look right?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
= drivers/video/controlfb.c 1.9 vs edited =
--- 1.9/drivers/video/controlfb.c Fri Nov 16 02:58:17 2001
+++ edited/drivers/video/controlfb.cMon Nov 26 22:52:28 2001
@@ -621,14 +621,10 @@
full = p-total_vram == 0x40;
+#ifdef CONFIG_NVRAM
/* Try to pick a video mode out of NVRAM if we have one. */
- if (default_cmode == CMODE_NVRAM){
+ if (default_cmode == CMODE_NVRAM)
cmode = nvram_read_byte(NV_CMODE);
- if(cmode CMODE_8 || cmode CMODE_32)
- cmode = CMODE_8;
- } else
- cmode=default_cmode;
-
if (default_vmode == VMODE_NVRAM) {
vmode = nvram_read_byte(NV_VMODE);
if (vmode 1 || vmode VMODE_MAX ||
@@ -639,15 +635,16 @@
if (control_mac_modes[vmode - 1].m[full] cmode)
vmode = VMODE_640_480_60;
}
- } else {
- vmode=default_vmode;
- if (control_mac_modes[vmode - 1].m[full] cmode) {
- if (cmode CMODE_8)
- cmode--;
- else
- vmode = VMODE_640_480_60;
- }
}
+#endif
+
+ /* If we didn't get something from NVRAM, pick a
+* sane default.
+*/
+ if (vmode = 0 || vmode VMODE_MAX)
+ vmode = VMODE_640_480_67;
+ if (cmode CMODE_8 || cmode CMODE_32)
+ cmode = CMODE_8;
if (mac_vmode_to_var(vmode, cmode, var) 0) {
/* This shouldn't happen! */
= drivers/video/imsttfb.c 1.11 vs edited =
--- 1.11/drivers/video/imsttfb.cFri Nov 16 02:58:18 2001
+++ edited/drivers/video/imsttfb.c Mon Nov 26 22:52:11 2001
@@ -371,7 +371,6 @@
TVP = 1
};
-#define USE_NV_MODES 1
#define INIT_BPP 8
#define INIT_XRES 640
#define INIT_YRES 480
@@ -384,7 +383,8 @@
static char curblink __initdata = 1;
static char noaccel __initdata = 0;
#if defined(CONFIG_PPC)
-static signed char init_vmode __initdata = -1, init_cmode __initdata = -1;
+static signed char init_vmode __initdata = VMODE_NVRAM;
+static signed char init_cmode __initdata = CMODE_NVRAM;
#endif
static struct imstt_regvals tvp_reg_init_2 = {
@@ -1804,20 +1804,25 @@
}
}
-#if USE_NV_MODES defined(CONFIG_PPC)
+#ifdef CONFIG_ALL_PPC
{
int vmode = init_vmode, cmode = init_cmode;
- if (vmode == -1) {
+#ifdef CONFIG_NVRAM
+ /* Attempt to read vmode/cmode from NVRAM */
+ if (vmode == VMODE_NVRAM)
vmode = nvram_read_byte(NV_VMODE);
- if (vmode = 0 || vmode VMODE_MAX)
- vmode = VMODE_640_480_67;
- }
- if (cmode == -1) {
+ if (cmode == CMODE_NVRAM)
cmode = nvram_read_byte(NV_CMODE);
- if (cmode CMODE_8 || cmode CMODE_32)
- cmode = CMODE_8;
- }
+#endif
+ /* If we didn't get something from NVRAM, pick a
+* sane default.
+*/
+ if (vmode = 0 || vmode VMODE_MAX)
+ vmode = VMODE_640_480_67;
+ if (cmode CMODE_8 || cmode CMODE_32)
+ cmode = CMODE_8;
+
if (mac_vmode_to_var(vmode, cmode, p-disp.var)) {
p-disp.var.xres = p-disp.var.xres_virtual = INIT_XRES;
p-disp.var.yres = p-disp.var.yres_virtual = INIT_YRES;
= drivers/video/platinumfb.c 1.5 vs edited =
--- 1.5/drivers/video/platinumfb.c Fri Nov 16 13:45:57 2001
+++ edited/drivers/video/platinumfb.c Tue Nov 27 07:53:20 2001
@@ -558,19 +558,20 @@
sense = read_platinum_sense(info);
printk(KERN_INFO Monitor sense value = 0x%x, , sense);
+#ifdef CONFIG_NVRAM
if (default_vmode == VMODE_NVRAM) {
default_vmode = nvram_read_byte(NV_VMODE);
if (default_vmode = 0 || default_vmode VMODE_MAX ||
!platinum_reg_init[default_vmode-1])
default_vmode = VMODE_CHOOSE;
}
-
