[PULL] bus cleanup, darwin hw/xfree86, build regression fixes

[Mark Kettenis]

> From: Jeremy Huddleston <jeremyhu at apple.com>
> Date: Fri, 23 Sep 2011 20:21:54 -0700
> 
> On Sep 23, 2011, at 16:22, Jeremy Huddleston wrote:
> 
> > I'm also testing it on tifa32-linux tinderbox:
> > http://tinderbox.x.org/builds/2011-09-23-0007
> 
> A few failures in various video drivers ... but they should be
> simple enough to address (a quick check looks like #include
> <pciaccess.h> will probably take care of some of the issues)
> ... wouldn't it be great if the drivers were in the tree so this
> could all be addressed together... /duck
>
> I'll start working though the various drivers next week and leave it
> to you if you want to merge this before that is all done.  Waiting a
> bit longer will also give others (Mark) time to review.

It's more than a few drivers.  And as far as I can tell that massive
breakage is due to two things:

1. The removal of domainIOBase from struct _ScrnInfoRec.

2. The removal of the IOADDRESS type from xf86Pci.h.

Only a few drivers actually use domainIOBase, but among those are
xf86-video-vesa and xf86-video-vmware drivers, which are pretty
important ones.  The others are xf86-video-ark, xf86-video-sis and
xf86-video-tdfx.  These drivers are fairly easy to "fix" by replacing
domainIOBase by 0.  That will of course break the usage of these
drivers on systems with multiple PCI domains.  That can only be fixed
by proper conversion of these drivers to use the appropriate
libpciaccess interfaces instead of assuming legacy space is mapped and
doing in/out directly.  None of these drivers matter to me for
OpenBSD/sparc64, which is the only architecture with multiple PCI
domains that we run on.  But Linux people might care, for example for
POWER systems.  Remember that multiple domain support was one of the
reasons for deveoping libpciaccess in the first place!

IOADDRESS is used massively throughout the drivers.  I really don't
see why it needs to be removed.  Leaving the typedef in xf86Pci.h will
save you/us a lot of work.  At that point you might as well drop the
changesto remove IOADDRESS usage in the int10 module.

Still only a partial review; looking into the changes to the
interfaces that map video memory now.