PCI rework

[Mark Kettenis]

> Date: Tue, 02 May 2006 13:34:32 -0700
> From: Ian Romanick <idr at us.ibm.com>
> 
> > If there is a 1:1 mapping from region ID's to BARs then yes, of course
> > this can be done.  How does the mapping work if there are 64-bit Base
> > Adress registers, possibly intermixed with 32-bit Base Address
> > registers?  The "region" in the interface name is a bit strange, but
> > admittedly the PCI standard doesn't really suggest a better name.
> > Perhaps pci_device_map_bar() expresses the intent a bit better.
> 
> If a device has a 64-bit BAR, a 32-bit BAR, and another 32-bit BAR,
> these will be elements 0, 1, and 2 in the regions array in the
> pci_device structure.  This seemed like the most logical way for the
> library to advertise this to the app.

And what happens if a BAR is unimplemented, but the BARs before it and
after it are there?  Are elements skipped, or just left out?  As far
as I can tell, the Linux sysfs interface isn't fully specified.  This
is one of the reasons why I think basing the interface of libpciaccess
on a particular incarnation of the Linux pci bus access interface is a
bad idea.  This is why I think basing the interface on the actual
hardware standard is better.  And I think the existing X interface
comes pretty close.

> >>>there's a good reason not to do it: Many PCI devices put mappable
> >>>memory addresses in config space outside the standard PCI BARs.  What
> >>>you really need is an interface to read from PCI config space and an
> >>>interface to map physicall addresses on the pci bus into memory.  Some
> >>>standard helper functions to decode the standard BARs is certainly
> >>>desirable.
> >>
> >>Excluding legacy VGA memory, can you name any?
> > 
> > I've no experience with graphics hardware.  But the VIA VT8237
> > southbridge has Watchdog Timer memory base at offset 0xe8.  The Intel
> > ICH7 sothbridge as a gpio base address register at offset 0x48.  Looks
> > like the Winbond W89C840F Fast Ethernet adapter has a bootrom at the
> > address specified by offset 0x28.
> 
> That's just genius. :(

Welcome to the real world, where hardware vendors routinely break the
standards.

> However, doesn't the kernel have quirks (or whatever they're called)
> to correctly advertise this to user-mode?

How should it do that.  Providing an additional memory region?  How
are those regions supposed to be numbered?  Can your libpciaccess
interface deal with them?  The current X interface can, because all it
takes is the (physical) address on the pci bus and the size of the
region to be mapped.

Mark