Initial version of PCI access library

[Benjamin Herrenschmidt]

> Hmm...the legacy I/O & memory access support currently in X is outside
> the PCI support, so I left it out.  I'd like to keep this as a generic
> PCI access library, so I'm inclined to keep it out.  I don't see any
> reason why it couldn't be put in a different layer.  Do many drivers
> still rely on legacy access?

It should be done by the PCI library I think with ways to deal with non
PCI systems. The reason is that on PCI based machines, legacy IOs and
memory are just ... PCI IO and memory cycles to low addresses, that get
then forwarded by an ISA bridge if any, or just decoded "as-is" by
stupid hard-decoding video chips.

That means that on machines with several PCI domains, you end up having
a "legacy" space per domain ! That has two consequences. The first one
is that legacy accesses need to have at least a PCI domain identifier,
better a PCI bus identifier attached to them. The other one is that the
VGA arbitration mecanism should be made aware of that since there may be
need to involve the domain controller into the arbitration (ia64
platforms ?)

Even drivers for "modern" cards _do_ use legacy IO accesses for
saving/restoring the VGA text mode on VT switches for example.

In fact, the situation is even worse than that in the IO space but I
don't think you really need to deal with that... due to total stupidity
of manufacturers, a lot of cards can only decode 16 bits of IO space,
and most x86 BIOSes can't do IO accesses above 16 bits. That has very
significant consequences for things like ... int10. If you try to
soft-boot a radeon card for example, running the BIOS on it within
x86emu, you'll notice that the BIOS actually reads the IO BAR of the
card using ... a 16 bits access ! It will then check the low 16 bits, if
they are 0 will arbitrarily shove 0xf000 in there (ugh) and will then
proceed to access card registers using inx/outx instructions on this 16
bits port number. I'll let you imagine how that will behave if your card
has been assigned IOs at, for example, 0x10000 ...  That is bad but it's
not something I think we should even try to deal with in the PCI
library, though we should probably try to do an abstracted PCI world in
int10 for more reliable soft-booting.