[Xorg] Re: Xserver device I/O on Linux

Jesse Barnes jbarnes at sgi.com
Fri Jun 25 10:00:56 PDT 2004


On Tuesday, May 4, 2004 1:30 pm, 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.

ia64 doesn't, by default, build with PCI domain support.  It defines 
INCLUDE_XF86_NO_DOMAIN which causes it to use /dev/mem for things.  I'd like 
to change that.

> 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 you removed the INCLUDE_XF86_NO_DOMAIN define?

> 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.

Here's a patch that might illustrate some of what I'm trying to do.  There are 
several issues at play here:

  o Linux/ia64 kernel PCI domain support (I still need to do this properly,
    the attached patch is funky because PCIIOC_CONTROLLER isn't implemented
    in my kernel)
  o bus addr != host addr on some ia64 platforms, so X on ia64 needs to have
    pciBusAddrToHostAddr implemented, this should be easy with
    the /proc/bus/pci API
  o ia64Pci.c roots around in /dev/mem, which can cause MCAs on machines that
    don't have the addresses it's looking for, so some other mechanism for
    discovering which PCI bridge is present would be desirable
  o legacy port access isn't handled gracefully on some platforms, it causes
    master aborts.  I've got a patch to the Linux/ia64 kernel which will
    recover from this condition and send offending apps a SIGBUS when this
    occurs, which seems to be working well enough for X to boot cards up

So does anyone own hw/xorg/os-support in the new tree?  If not, Shrijeet and I 
would be willing to help out...

Thanks,
Jesse






More information about the xorg mailing list