From: Michel Danzer <hidden> Date: 2000-03-15 09:44:54
--- Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> wrote:
quoted
quoted
Possibly; I've also seen the X server convert XFree mode lines into
fbdev timings, thereby overwriting the 565 with 000. Doesn't hurt for
16
quoted
quoted
bits, only for 32 bits.
Doesn't hurt for probing, but maybe for the ioctl?
The ioctl has been disabled long time ago.
I meant when you hadn't disabled it. It hung there at the time, right? Now a
hang in an ioctl is a kernel bug, or am I missing something?
I'll get back to poking around in there as soon as I can figure out how to
see the kernel messages (i.e. how to switch back to the text console fast
enough, or never let the X server switch to VT 7 in the first place).
A remote machine might be handy...
Now I can't get beyond xf86HandleColormaps(). Another ioctl that barfs on
me, perhaps.
Well possible, FBIOPUTCMAP in fbdevHWLoadPalette.
I don't understand the code there...
BTW I've just discovered that the fbdev driver sets the weight explicitly to
{0,0,0}... now I'm (really ;) confused.
I guess it all boils down to PCI messups.
How do you come to this conclusion? Why should it influence ioctls?
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-03-15 11:13:25
quoted
quoted
Doesn't hurt for probing, but maybe for the ioctl?
The ioctl has been disabled long time ago.
I meant when you hadn't disabled it. It hung there at the time, right? Now a
hang in an ioctl is a kernel bug, or am I missing something?
No, you're right :-)
quoted
I'll get back to poking around in there as soon as I can figure out how to
see the kernel messages (i.e. how to switch back to the text console fast
enough, or never let the X server switch to VT 7 in the first place).
A remote machine might be handy...
That's what I'm using already. But the kernel messages that otherwise
appear on the text screen won't get redirected to a remote machine.
Nothing ever ends up in the syslog, anyway. I guess the klogd/syslogd
combo is too slow in this case.
quoted
Now I can't get beyond xf86HandleColormaps(). Another ioctl that barfs on
me, perhaps.
Well possible, FBIOPUTCMAP in fbdevHWLoadPalette.
Probably. I'll have to trace all these ioctls as soon as I can keep the X
server from switching consoles.
I don't understand the code there...
The cmap only passes the pointers to the color values. fb_set_cmap does
get_user on those so it should be OK. Don't ask me why X sets each entry
separately though (on some braindead Mac video cards this means you have
to start setting the cmap from entry 0 until you hit the right one, each
time).
BTW I've just discovered that the fbdev driver sets the weight explicitly to
{0,0,0}... now I'm (really ;) confused.
So was I.
quoted
I guess it all boils down to PCI messups.
How do you come to this conclusion? Why should it influence ioctls?
Because these ioctls will, ultimately, write to the card again? If the X
server actually messes with the PCI bridges, the card might no longer be
mapped?
I admit that I understand next to nothing about PCI, or how the X server
uses PCI. Makes it a bit harder to spot the flaky code :-)
Anyway, the X server appears to complete screen init OK but I never
actually get to see the cross hatch pattern.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
How do you come to this conclusion? Why should it influence ioctls?
Because these ioctls will, ultimately, write to the card again? If the X
server actually messes with the PCI bridges, the card might no longer be
mapped?
I admit that I understand next to nothing about PCI, or how the X server
uses PCI. Makes it a bit harder to spot the flaky code :-)
Anyway, the X server appears to complete screen init OK but I never
actually get to see the cross hatch pattern.
The X server has played with the cards mappings, since it believed the
old ones were wrong. atyfb will still try to access the card in the old
location and thats what gives you the hard locks.
The question is why the X server doesn't like the old mappings ?
If you can send me the /var/log/XFree86.0.log and lspci output i'll
forward it in the xfree devel list and see what answers we can get from
there.
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Kevin Hendricks <hidden> Date: 2000-03-21 02:33:10
Hi Kostas,
With lots of help from Ben, we were able to figure out that the OF values used
to initialize the Rage128 and Rage128Pro cards are the same ones used by the
MacOS and that we can actually read the X_MPLL_REF_FB_DIV value, the XCLK_CNTL,
and PLL_REF_DIV values and calculate the proper XCLK. In a similar way you can
calculate the MCLK value too so you can get or calculate almost all of the same
info as is probed from the Bios under x86 machines.
This allows both machines with G3s, and G4 (even with the Rage 128 cards) to
work with the same aty128fb.c kernel driver without any table lookups.
The patch to add this to the aty128fb.c is attached. I have also used
similar code to replace the bios code probe for powerpc in the r128_driver.c for
xf400. The patch to do that is also attached.
These patches have been tested and work fine on my B+W G3 rev 2, my brand new
G4 with Rage128Pro card, and on Ben's older G4 with the non-pro card.
We still need to test this on a B+W G3 revision 1 just to be complete (but Ben
will do that soon).
Assuming they test out fine, Kostas would you see about getting the r128 patch
integrated into the next xf40X release while I see about getting Paul and/or
Anthony to integrate the aty128fb.c patch into both the stable and development
kernels.
Hopefully with these in place, new G4s will work as well as older G4s
and G3s.
Thanks!!!
Kevin
--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
From: Benjamin Herrenschmidt <hidden> Date: 2000-03-21 11:11:20
On Mon, Mar 20, 2000, Kevin Hendricks [off-list ref] wrote:
These patches have been tested and work fine on my B+W G3 rev 2, my brand new
G4 with Rage128Pro card, and on Ben's older G4 with the non-pro card.
We still need to test this on a B+W G3 revision 1 just to be complete
(but Ben
will do that soon).
Apparently, it works on all machines. I just tested on a B&W G3 rev. 1
and an iMac DV. It works also on the M3 (new r128 mobility in pismo).
However, I noticed that in all cases (or almost all cases), we have the
same XCLK as MacOS (and probably the same MCLK, I didn't verify), but we
obtain it using a lower divider. For example, on the B&W rev. 1, we have
0x1f for the ref. div, and I have 0x38 (instead of 0x3b used by MacOS).
I don't know if there's a real impact (less precise pixel clock ?). At
least, now it works on all machines, which was not the case previously.
My rsync tree contains the same kernel as Paul's latest stable tree with
a backport of 2.3.x current aty128fb with your changes (and other pismo
powerbook support stuffs). I didn't add Ani Joshi patches yet.
I'll post pre-compiled once I feel the pismo stuffs are clean enough (and
there's another problem with the latest aty128, sometimes, I've seen some
erase problems in console mode. Not very important, but...). I'll then
merge my stuffs in 2.2.x and 2.3.x bk trees.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Hi Kostas,
With lots of help from Ben, we were able to figure out that the OF values used
to initialize the Rage128 and Rage128Pro cards are the same ones used by the
MacOS and that we can actually read the X_MPLL_REF_FB_DIV value, the XCLK_CNTL,
and PLL_REF_DIV values and calculate the proper XCLK. In a similar way you can
calculate the MCLK value too so you can get or calculate almost all of the same
info as is probed from the Bios under x86 machines.
From the patches i see that the reference freq is still assumed to be
29.50Mhz
/* Assume REF clock is 2950 (in units of 10khz) */
/* and that all pllclk must be between 125 Mhz and 250Mhz */
pll->reference_freq = 2950;
pll->min_pll_freq = 12500;
pll->max_pll_freq = 25000;
From the comments in the xfree driver (and the ati docs) this isn't always
true:
/* These probably aren't going to work for
the card you are using. Specifically,
reference freq can be 29.50MHz,
28.63MHz, or 14.32MHz. YMMV. */
So we need to find a way to calculate the reference freq, without it
xfree/aty128fb still won't do the right thing :(
This allows both machines with G3s, and G4 (even with the Rage 128 cards) to
work with the same aty128fb.c kernel driver without any table lookups.
The patch to add this to the aty128fb.c is attached. I have also used
similar code to replace the bios code probe for powerpc in the r128_driver.c for
xf400. The patch to do that is also attached.
These patches have been tested and work fine on my B+W G3 rev 2, my brand new
G4 with Rage128Pro card, and on Ben's older G4 with the non-pro card.
We still need to test this on a B+W G3 revision 1 just to be complete (but Ben
will do that soon).
Assuming they test out fine, Kostas would you see about getting the r128 patch
integrated into the next xf40X release while I see about getting Paul and/or
Anthony to integrate the aty128fb.c patch into both the stable and development
kernels.
I'll be more than happy to get the patches in the xfree tree, even with
the reference_freq hardcoded its still an improvement.
#ifdef __powerpc__ for this it should be better to see if the card has
an OF or BIOS rom first since that will allow people to keep using cards
with bios roms under ppc (i wonder if anyone is doing this)
Any ideas on how we can check if a card has OF or BIOS roms ?
Hopefully with these in place, new G4s will work as well as older G4s
and G3s.
Thanks!!!
Kevin
From: Kevin B. Hendricks <hidden> Date: 2000-03-21 17:26:47
Hi,
From the patches i see that the reference freq is still assumed to be
29.50Mhz
/* Assume REF clock is 2950 (in units of 10khz) */
/* and that all pllclk must be between 125 Mhz and 250Mhz */
pll->reference_freq = 2950;
pll->min_pll_freq = 12500;
pll->max_pll_freq = 25000;
Yes, that's true. Luckily, all of the Mac's use Rage128 cards with 2950 AFAIK.
I will keep looking through the manual to see if I can figure out a way to
determine this without a bios.
From the comments in the xfree driver (and the ati docs) this isn't always
true:
/* These probably aren't going to work for
the card you are using. Specifically,
reference freq can be 29.50MHz,
28.63MHz, or 14.32MHz. YMMV. */
Yes I know.
I'll be more than happy to get the patches in the xfree tree, even with
the reference_freq hardcoded its still an improvement.
Jacl Howarth just report a 30% performance increase in some x11perf tests
on XF 4.0 with the new patch versus the old values! That makes me feel
better.
#ifdef __powerpc__ for this it should be better to see if the card has
an OF or BIOS rom first since that will allow people to keep using cards
with bios roms under ppc (i wonder if anyone is doing this)
Any ideas on how we can check if a card has OF or BIOS roms ?
Unforntunately, the current xf4 bios check does not work on some G3s and
G4's. Literally tmp[] comes back with the right values that leads you to
believe that the Bios is there but the values for ref, the max and min pll,
read from the "Bios" etc are truly garbage (i.e. xlck reads as 0). The
only reason it still worked was that none of the builtin modes fit the max
and min pll values so no modes were found so the r128_driver.c just
defaulted to the current fb mode which works.
I think a better check for a bios being present would detect the issue and
we code default to of values set in the pll registers next.
Thanks!
Kevin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From the patches i see that the reference freq is still assumed to be
29.50Mhz
/* Assume REF clock is 2950 (in units of 10khz) */
/* and that all pllclk must be between 125 Mhz and 250Mhz */
pll->reference_freq = 2950;
pll->min_pll_freq = 12500;
pll->max_pll_freq = 25000;
Yes, that's true. Luckily, all of the Mac's use Rage128 cards with 2950 AFAIK.
I will keep looking through the manual to see if I can figure out a way to
determine this without a bios.
If most Mac's use cards with 2950 then we should be fine for now, but for
the future we need to find a way to get this right.
quoted
From the comments in the xfree driver (and the ati docs) this isn't always
true:
/* These probably aren't going to work for
the card you are using. Specifically,
reference freq can be 29.50MHz,
28.63MHz, or 14.32MHz. YMMV. */
Yes I know.
quoted
I'll be more than happy to get the patches in the xfree tree, even with
the reference_freq hardcoded its still an improvement.
Jacl Howarth just report a 30% performance increase in some x11perf tests
on XF 4.0 with the new patch versus the old values! That makes me feel
better.
Wow thats something :)
quoted
#ifdef __powerpc__ for this it should be better to see if the card has
an OF or BIOS rom first since that will allow people to keep using cards
with bios roms under ppc (i wonder if anyone is doing this)
Any ideas on how we can check if a card has OF or BIOS roms ?
Unforntunately, the current xf4 bios check does not work on some G3s and
G4's. Literally tmp[] comes back with the right values that leads you to
believe that the Bios is there but the values for ref, the max and min pll,
read from the "Bios" etc are truly garbage (i.e. xlck reads as 0). The
only reason it still worked was that none of the builtin modes fit the max
and min pll values so no modes were found so the r128_driver.c just
defaulted to the current fb mode which works.
I think a better check for a bios being present would detect the issue and
we code default to of values set in the pll registers next.
The current code always assume that the ROM is a BIOS one, the 2 bytes
that it checks in the beggining are probably present in OF ati cards as
well so it thinks that everything is ok, we need to know if the card has
an OF rom or not (this is needed for other places in xfree as well the
int10 module will try to softboot OF cards also), i am sure there is a way
to find this i'll check the OF docs and see if i can find something.
From: Gabriel Paubert <hidden> Date: 2000-03-22 16:49:58
On Tue, 21 Mar 2000, Kostas Gewrgiou wrote:
The current code always assume that the ROM is a BIOS one, the 2 bytes
that it checks in the beggining are probably present in OF ati cards as
well so it thinks that everything is ok, we need to know if the card has
an OF rom or not (this is needed for other places in xfree as well the
int10 module will try to softboot OF cards also), i am sure there is a way
to find this i'll check the OF docs and see if i can find something.
All ROMS start AFAICT with 0x55,0xaa (or the other way around) followed by
a byte which gives the size of the ROM in 512 bytes blocks. On x86 the
entry point is at offset 0x03 and is always a jump (at least I have never
seen a board in whichit was not a jump), the opcode of which is 0xe9 or
0xeb. Could this be used as a test or as at least an heuristic ?
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Kevin Hendricks <hidden> Date: 2000-03-23 04:46:34
Hi Kostas,
I have set up my XF86Config file to allow mode switching (with valid mode info)
by hitting the Cntl-Alt-KeyPad- and Cntl-Alt-KeyPad+ keys. Unfortunately,
although the mode seems to switch the screen is very messed up. Luckily, if I
keep hitting the key combo I get back to a good resolution. I tracked this
back to fbdevxxxSwitchMode which uses a framebuffer ioctl (FBIOPUT_VSCREENINFO)
which in turn is handled in linux/drivers/video/fbmem.c and eventually calls
aty128fb.c set_var routine.
Something here is broken but I can't put my finger on what yet. Does using the
key combo to switch modes on the fly under R128 work for you on your x86
machine?
Also, I tried to test this under the XFree86 running fbdev as its driver. Each
time I tried this I ended up with a complete hard lockup (kernel went boom). I
tried connecting from other machines on my home network but I got no response
at all.
This used to work fine under xf 3.9.17. Have you tried this recently?
Thanks,
Kevin
--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/