Re: xorg for alpha

[Michael <macallan%NetBSD.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Jan 14, 2009, at 6:53 AM, Manuel Bouyer wrote:

> On Tue, Jan 13, 2009 at 11:59:35PM -0500, Michael wrote:
> > > (II) memory base = 0xa7a486b7525203d
> > >
> > > Any idea still welcome ...
> >
> > (II) memory base = 0x2074657366666f20
> > (II) memory base = 0x2074657366666f20
> >
> > These look bogus too.
>
> Yes
>
> > I don't think Xorg's alpha-specific PCI support code works right on
> > NetBSD
>
> It looks a lot like what we had in your XFree86 tree; and this one  
> works
> at last on a PWS500 (I couldn't test xorg on a PWS500 yet; I have to  
> find
> a battery to make it work again). The same XFree86 has issues on  
> XP1000,
> so it may be a Tsunami-specific issue.

I have no idea why X[Free86|org] goes through all that hassle on alpha  
but I never had one so what do I know ;)

> > - I think you should do as sparc64 and the powerpc ports do -
> > use netbsdPci.c / ppc_video.c and mmap PCI resources through /dev/
> > ttyE0 at offset == bus address. Much less hassle.
>
> How does it work with multiple VGA adapters ?

It doesn't, at least until...
- - we create /dev/ttyF*, /dev/ttyG* etc. for multiple wsdisplay instances
- - X learns to probe through all of them
neither is very difficult actually, when I have a few days off work  
I'll probably just write the X part.
Simply treat every wsdisplay instance as its own PCI domain so X won't  
try to muck with our BARs, use the PCI config space ioctl()s on the  
wsdisplay's file handle so we would only see the graphics chip - that  
would probably simplify a few thing in the Xserver and to top it off  
it would be completely MI.

> Also, alpha support graphic adapters which are not VGA (like the TGA  
> for example)

Same goes for macppc and sparc64 - we don't even use vga at pci. Ever.
All this requires is some code in <whatever>_mmap() to allow mmap()ing  
PCI resources as their bus addresses and optionally map PCI IO space.  
All PCI framebuffer drivers we use on macppc or sparc64 do just that.  
Adding it to TGA is trivial.

> > If you need PIO access define PCI_MAGIC_IO_RANGE to something never  
> > used by PCI memory resources, the necessary voodoo is already in  
> > place in vga_pci.c.
> > This of course assumes that alpha, like sparc and powerpc, accesses
> > PCI IO space through some special memory range.
>
> I'm not sure if it does or not. inx/outx are defined, but I've looked
> closely at what they're doing in userland.

On macppc they're memory writes with a barrier, on sparc64 we don't  
need the barrier.

> > If that's not the case please ignore the bit about  
> > PCI_MAGIC_IO_RANGE.
> > For mga you won't need PIO anyway.
>
> thanks !

Years ago I wrote a hack to let xfree86 access generic, otherwise  
unsupported PCI graphics controllers through a slightly abused /dev/ 
fb* ( the last remnant of that is in machfb ) - I had an U10 running  
XFree86 with four heads, the onboard Rage Pro, a Creator3D, a  
Millennium I and a Millennium II ( both with PC firmware so X had to  
do all the legwork ) - it didn't support PCI IO space at all yet the  
Matrox cards just worked fine, with some minor endiannes-related  
glitches As far as I know the only non-x86 firmware you can get for  
these cards is Apple-specific, so the driver writers probably used  
#ifdef __powerpc__ all over the place.

If you use VGA text mode you may want to allow X to use the vgahw  
module which does need PCI IO space access in order to mess with the  
resp. vga registers.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBSW4mWspnzkX8Yg2nAQIpMggAkvqyOMVaVY3xtjqFVR7YgBAlH/RZ0VH/
81u+FU++ZTcsbvIlRLgvaun0blzBF6MvvyXwvKvR1CBph7vNbhNE/HrlxVprXQB3
N9LfaNKt2pQ4dci2tXu5Co7Gwhio4YvHVYcHGzBe+WusSV7/f6yKANuswN/2sbzQ
zr8WbC/iwBo5SoSqyVgt+8u0XXhlSzeXEaXpIOLkOj/RrUyBzSnCHuJfDmO9QkPu
oYBQ1kmC4g+uHDrEd50kDV/PgWfkJW68KMddbkgD0HzYx1vmylT9BDOrHIrjOgDb
eX9T4wH1KkvGkCHz9EKD5QDHfnck6nPgwsfcj9lgq4olvEnbbEV/LA==
=9JGQ
-----END PGP SIGNATURE-----