From: Hendricks, Kevin <hidden> Date: 2000-10-12 14:30:17
Hi Kostas,
If the main clock rate is different, as long as
quoted
you can find out what it is, reading and calculating the timings from
those register settings really should work generically, shouldn't it?
The reference frequency isn't the same in all cards, your patch assumes that
/* Assume REF clock is 2950 (in units of 10khz) */
/* and that all pllclk must be between 125 Mhz and 250Mhz */
Yes, that is what I was referring to above. That info is generally available in the card docs. Ben has a whole set of ref clock rates for all the ati cards shipped under mac or clones. I also have that info and could easily look up the card id to set it for macs in general.
/* 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. */
You can actually use info on the pllclk constraints to rule out the 14.32Mhz cases from the other two cases and then you are left with only 2 to try.
A lookup table would certainly do the trick if the user did not want to simply use trial and error. Anything would be better than the complete hard coded values set in the XF 4.0 source.
Perhaps a better idea is allow the REF clock rate to be passed as a parameter in the XF86Config file (much like the video memory parameter and bus ids passed now) for people to have control over if need be. This value would then only be used if the bios test failed and then in place of the hardcoded values so that my pll register probing routine would be actually work. A desperate user could then try each of the 3 values until he/she saw something they liked on the screen.
Most of the ppc r128 cards have a reference frequency of 29.50MHz so the
code works but i heard that some of the new ones have different reference
freq.
Yes, there is one new card (of the r128 variety) on Ben's list that does not use the 2950 ref clock value.
Since he has a bios on a ppc card it would be interesting to see the results of some "bios present?" tests to help determine if a bios is really there or not. The current test sometimes passes on macs without a bios (possibly OF rom?) and garbage values are returned.
Kevin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
A lookup table would certainly do the trick if the user did not want to
simply use trial and error. Anything would be better than the complete
hard coded values set in the XF 4.0 source.
Perhaps a better idea is allow the REF clock rate to be passed as a
parameter in the XF86Config file (much like the video memory parameter and
bus ids passed now) for people to have control over if need be. This
value would then only be used if the bios test failed and then in place of
the hardcoded values so that my pll register probing routine would be
actually work. A desperate user could then try each of the 3 values until
he/she saw something they liked on the screen.
I prefer to use a lookup table before the config option, most users will
have no idea how to play with the options. I wonder if someone can damage
his card with a bad reference freq setup...
quoted
Most of the ppc r128 cards have a reference frequency of 29.50MHz so the
code works but i heard that some of the new ones have different reference
freq.
Yes, there is one new card (of the r128 variety) on Ben's list that does
not use the 2950 ref clock value.
The new r128 code needs to read extra values from the rom for the flatpanel
setup as well (Michel knows more about this) which we will have to find a
solution too.
Since he has a bios on a ppc card it would be interesting to see the
results of some "bios present?" tests to help determine if a bios is
really there or not. The current test sometimes passes on macs without a
bios (possibly OF rom?) and garbage values are returned.
The current test only checks if a rom is present not if a bios or OF segment
is there, it needs to be fixed to check that its really reading from a
bios rom and not from something else (OF).
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-10-12 17:22:05
Kostas Gewrgiou wrote:
On Wed, 11 Oct 2000, Josh Huber wrote:
quoted
On Wed, Oct 11, 2000 at 08:43:28PM +0200, Michel D?nzer wrote:
quoted
quoted
Does aty128fb work on the second card? If yes, try Option "UseFBDev".
The secondary card is a PC card, so it's not initialized by OF, but I
think the r128 fb driver does a proper initialization of the card, so
that shouldn't be the problem.
Kevin Hendricks patches from Ani's tree will fix the memory/clock values
for OF cards only, the patch breaks the calculations for the x86 cards
(thats the reason why its not in the xfree cvs),
But there is an #ifdef _powerpc_ so it can't break x86 machines?
On Thu, 12 Oct 2000, Hendricks, Kevin wrote:
The new r128 code needs to read extra values from the rom for the flatpanel
setup as well (Michel knows more about this) which we will have to find a
solution too.
And it will be hard. Rumour has it that the correct values are in MacOS and
only Apple knows how to do it right, not even ATI. The default values work
more or less on my Pismo, but there is always the danger of damaging the
panel.
Note that the FP code is only needed for stretching modes with a lower
resolution than the panel's, just disabling it altogether works fine for the
full resolution.
quoted
Since he has a bios on a ppc card it would be interesting to see the
results of some "bios present?" tests to help determine if a bios is
really there or not. The current test sometimes passes on macs without a
bios (possibly OF rom?) and garbage values are returned.
The current test only checks if a rom is present not if a bios or OF segment
is there, it needs to be fixed to check that its really reading from a
bios rom and not from something else (OF).
So this code from the current X CVS:
R128ReadBIOS(0x0000, info->VBIOS, R128_VBIOS_SIZE);
if (info->VBIOS[0] != 0x55 || info->VBIOS[1] != 0xaa) {
xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
"Video BIOS not detected in PCI space!\n");
only checks if there is a ROM, not if it's a BIOS?
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Thu, 12 Oct 2000, Michel [iso-8859-1] Dδnzer wrote:
Kostas Gewrgiou wrote:
quoted
Kevin Hendricks patches from Ani's tree will fix the memory/clock values
for OF cards only, the patch breaks the calculations for the x86 cards
(thats the reason why its not in the xfree cvs),
But there is an #ifdef _powerpc_ so it can't break x86 machines?
Yes but it *does* break x86 cards used in ppc machines.
(linux/ppc isn't the only ppc os supported in xfree and they won't
be happy if we break things for them)
quoted
The new r128 code needs to read extra values from the rom for the flatpanel
setup as well (Michel knows more about this) which we will have to find a
solution too.
And it will be hard. Rumour has it that the correct values are in MacOS and
only Apple knows how to do it right, not even ATI. The default values work
more or less on my Pismo, but there is always the danger of damaging the
panel.
Damn thats not good :(
Note that the FP code is only needed for stretching modes with a lower
resolution than the panel's, just disabling it altogether works fine for the
full resolution.
quoted
The current test only checks if a rom is present not if a bios or OF segment
is there, it needs to be fixed to check that its really reading from a
bios rom and not from something else (OF).
So this code from the current X CVS:
R128ReadBIOS(0x0000, info->VBIOS, R128_VBIOS_SIZE);
if (info->VBIOS[0] != 0x55 || info->VBIOS[1] != 0xaa) {
xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
"Video BIOS not detected in PCI space!\n");
only checks if there is a ROM, not if it's a BIOS?
Right, from the pci spec the table is something like this
Offset Length Value Description
0h 1 55h ROM Signature, byte 1
1h 1 AAh ROM Signature, byte 2
...
18h-19h 2 xx Pointer to PCI Data Structure
PCI Data Structure
Offset Length Description
...
14 1 Code Type
..
Code Type is 0 for bios and 1 for OF
So you'll have to add one more test to check for BIOS/OF
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel D�nzer <hidden> Date: 2000-10-12 21:25:33
Kostas Gewrgiou wrote:
On Thu, 12 Oct 2000, Michel [iso-8859-1] Dänzer wrote:
quoted
Kostas Gewrgiou wrote:
quoted
Kevin Hendricks patches from Ani's tree will fix the memory/clock values
for OF cards only, the patch breaks the calculations for the x86 cards
(thats the reason why its not in the xfree cvs),
But there is an #ifdef _powerpc_ so it can't break x86 machines?
Yes but it *does* break x86 cards used in ppc machines.
(linux/ppc isn't the only ppc os supported in xfree and they won't
be happy if we break things for them)
And the int10 or whatever code works for them?
quoted
quoted
The current test only checks if a rom is present not if a bios or OF
segment is there, it needs to be fixed to check that its really reading
from a bios rom and not from something else (OF).
So this code from the current X CVS:
R128ReadBIOS(0x0000, info->VBIOS, R128_VBIOS_SIZE);
if (info->VBIOS[0] != 0x55 || info->VBIOS[1] != 0xaa) {
xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
"Video BIOS not detected in PCI space!\n");
only checks if there is a ROM, not if it's a BIOS?
Right, from the pci spec the table is something like this
Offset Length Value Description
0h 1 55h ROM Signature, byte 1
1h 1 AAh ROM Signature, byte 2
...
18h-19h 2 xx Pointer to PCI Data Structure
PCI Data Structure
Offset Length Description
...
14 1 Code Type
..
Code Type is 0 for bios and 1 for OF
So you'll have to add one more test to check for BIOS/OF
And then set info->VBIOS = NULL for OF and change the #ifdef _powerpc_ to if
(!info->VBIOS) or similar?
I have my last exam for this year tomorrow and leave for two weeks of vacation
on Saturday, so I wish good luck to any takers :)
Michel
--
Earthling Michel Dänzer (MrCooper) \ CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \ member of XFree86 and The DRI Project
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Thu, 12 Oct 2000, Michel [iso-8859-1] Dδnzer wrote:
Kostas Gewrgiou wrote:
quoted
On Thu, 12 Oct 2000, Michel [iso-8859-1] Dδnzer wrote:
quoted
But there is an #ifdef _powerpc_ so it can't break x86 machines?
Yes but it *does* break x86 cards used in ppc machines.
(linux/ppc isn't the only ppc os supported in xfree and they won't
be happy if we break things for them)
And the int10 or whatever code works for them?
ISA IO/MEM works for them so yes int10/vgahw should be fine there, i think
that linux/ppc is the only platform with this broken (with the new syscalls
we its simple to get it working for machines with one iobase and a working
ISA memory)
And then set info->VBIOS = NULL for OF and change the #ifdef _powerpc_ to if
(!info->VBIOS) or similar?
Right something along this lines will do, you probably need to change the
R128_BIOS16/32 macros to do byteswapping as well since the fields in the rom
are in little endian format.
I have my last exam for this year tomorrow and leave for two weeks of vacation
on Saturday, so I wish good luck to any takers :)
Good luck in your exam, i'll try to write something over the weekend if i
can find some free time.
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Thu, 12 Oct 2000, Michel [iso-8859-1] Dänzer wrote:
quoted
So this code from the current X CVS:
R128ReadBIOS(0x0000, info->VBIOS, R128_VBIOS_SIZE);
if (info->VBIOS[0] != 0x55 || info->VBIOS[1] != 0xaa) {
xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
"Video BIOS not detected in PCI space!\n");
only checks if there is a ROM, not if it's a BIOS?
Right, from the pci spec the table is something like this
Offset Length Value Description
0h 1 55h ROM Signature, byte 1
1h 1 AAh ROM Signature, byte 2
...
18h-19h 2 xx Pointer to PCI Data Structure
PCI Data Structure
Offset Length Description
...
14 1 Code Type
..
Code Type is 0 for bios and 1 for OF
So you'll have to add one more test to check for BIOS/OF
IIRC, it's also possible to have one ROM that contains both x86 BIOS and
F-Code Open Firmware stuff. It may require compression to achieve this due to
the limited size to the ROM. I think I saw this on the Firmworks website, an
eon ago.
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
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/