Re: Xserver device I/O on Linux

On Tuesday, May 4, 2004 10:30 am, John Dennis wrote:
> Both xfree86 and xorg on which it is based has code for using
> /proc/bus/pci on linux, in fact when building for ia64 this is exactly
> what happens so I'm a bit confused as to why you're having an issue with
> ia64. 

Well, I'm not having trouble with discovery (well, aside from the fact that 
the ia64 XF86SCANPCI_WRAPPER routine reads non-existent memory on sn2, 
causing a machine check), it just looked like things could be simplified a 
bit, but then I'm new to the X code, and I'm still figuring out how things 
are coded, so maybe that's just the style.

> We've been building and shipping X for ia64 for a while using this 
> code base. One change we recently made was to always use the linux
> version of the pci routines on all architectures, it had been the case
> that on x86 the pci code was accessing pci config space via the IO ports
> and soon this won't be supported (pci express does not support it and
> there are issues with concurrency on mp machines). This was a trival one
> line change to an ifdef to use the linux code.

So all the config space accesses are done via read/write on /proc/bus/pci now?  
That sounds good.

> I'm not sure what you mean by port I/O and mapping not being provided in
> a way the server expects could you elaborate? A lot of these issues have
> been addressed. But you're certainly right, port I/O on non-x86
> architectures has been a nasty area.

The current ia64 implementation of port I/O uses the glibc in/out routines, 
which aren't portable to platforms like sn2, where we need to mmap the legacy 
space for a given device and do loads and stores to it.  One reason we want 
to do this is that there are multiple legacy I/O spaces, one per bus, on sn2.  
Also, our platform doesn't support the architected legacy I/O model that ia64 
requires.  On ppc, I think the in/out routines are limited to doing legacy 
I/O on a single bus, which is obviously a problem if you want to start up 
more than one card.  I was hoping that we could somehow address these needs 
with a unified Linux in/out architecture in the X server.

As for mapping, I'm not sure yet, I'm still reading through the domain support 
stuff, but it looks like mapVidMem will be a problem for me too if it tries 
to map /dev/mem (so maybe I just need domain support?).

I think this would mean getting rid of the code that uses /dev/mem, and 
relying exclusively on the /proc/bus/pci API to do all mappings.  Would 
adding a PCIIOC_MMAP_IS_LEGACY ioctl to the /proc/bus/pci API be sufficient?

Thanks,
Jesse