tech-x11 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: xorg for alpha

Hash: SHA1


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.


I don't think Xorg's alpha-specific PCI support code works right on

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

Version: GnuPG v1.4.7 (Darwin)


Home | Main Index | Thread Index | Old Index