PCI rework

[Mark Kettenis]

> From: Jesse Barnes <jbarnes at virtuousgeek.org>
> Date: Sun, 30 Apr 2006 16:22:30 -0700
> 
> On Sunday, April 30, 2006 12:52 pm, Mark Kettenis wrote:
> > I'm talking specifically about pci_device_map_region() and
> > pci_device_unmap_region().  These interfaces are clearly there
> > because the Linux sysfs provides these "regions" as files which you
> > can open and then mmap.  Other operating systems don't support this
> > view, and there's a good reason not to do it: Many PCI devices put
> > mappable memory addresses in config space outside the standard PCI
> > BARs.
> 
> You mean for ISA legacy port space?  Yes, that's another area that needs 
> addressing (I mentioned it in the early threads about libpciaccess), 
> but beyond that I'm not sure what you mean?

Well, io port space is certainly the stuff with the most quirks.  Lots
of PCI stuff abuses the "unused" high bits of an IO BAR to store other
stuff.

But no, I've seen a few PCI devices that have "normal" memory BAR's in
nonstandard locations, i.e. at offset 0xe0 or 0xf0 in PCI config
space.  The libpciaccess interface can only deal with the standard
BARs at offsets 0x10 through 0x28.

Anothor major flaw in the libpciaccess interface is that it doesn't
allow the caller to specify a size for the mapping.  This is
important, since a video driver might want to map only part of a
region.

> > 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.
> 
> In my experience that's the wrong interface.  Reading PCI config space 
> isn't enough to tell you what or where memory should be mapped.  Only 
> the OS knows enough to actually map things correctly, e.g. in the case 
> of PCI bridges of various types (host->pci, pci->pci, etc.).  Hiding 
> this knowledge behind a library (ideally one that talks to the OS) is 
> the only way to go.

If the firmware properly initialized things, PCI config does give you
enough information.  X should only be looking at the PCI config space
for the graphics card.  It certainly shouldn't need to walk PCI
bridges and assigning memory addresses.

> > > Note that the prototype is different in that it takes a full pci
> > > info structure rather than just a tag.  This gives arch specific
> > > implementations more flexibility and eases porting.
> >
> > But a PCITAG is already opaque; there's no reason why you could
> > extend it to include the additional information you might need.
> 
> It's true that arch implementations could use PCITAG as some sort of 
> mapping key, but passing a whole structure makes things easier since 
> you can just have an arch specific void * containing an arch specific 
> structure.

Ah, but you could make PCITAG a structure, and include that void *.

> > > I disagree with this, the xf86Pci interface is pretty screwy:
> > >   o X does things with PCI devices it has no business doing (e.g.
> > >     remapping BARs)
> >
> > Remapping as in writing different addresses into them?  X might need
> > to do that if the firmware doesn't properly initialize them.  I've
> > seen many, many buggy firmware implementations (ok they're mostly
> > BIOSes) that don't do this properly.
> 
> X shouldn't be working around buggy BIOSes.  If this knowledge belongs 
> anywhere, it's in the OS (or at the very least some sort of fairly 
> centralized library).

You're probably right.  But you releaze that this means dropping
support for operating systems that don't fix things up right.  There's
no way X can fix things up for you.  The same thing goes for new
hardware that the OS doesn't know how to fix up yet.

> > >   o the distinction between mapping domain and regular PCI memory
> > > is arbitrary and should be removed
> >
> > I'm not quite sure what is actually meant by a "domain".  I'm
> > presuming it's similar to what the ACPI specification calls a
> > "segment": a completely seperate PCI bus hierarchy.  Yes, the way the
> > current interface handles that is awkward, but it should be easy to
> > fix this if you add the domain to the PCITAG.
> 
> I'm talking about xf86MapDomainMemory vs. xf86MapPciMem, but it sounds 
> like we agree that it's a silly distinction.  PCI domains (or segments 
> in ACPI as you mention) need to be dealt with on a high level.

Something that should really be abstracted away by the OS.

> > There are not many applications that need a PCI abstraction layer.
> > Apart from X and some debugging tools to look at PCI config space I
> > can't really think of any applications that need them.
> 
> Well, they're out there.  I don't really like the idea of userspace 
> drivers in general, but for certain devices a userspace driver is the 
> path of least resistance.  And there are quite a few of them out there, 
> mostly used for special purpose applications.

Is there any hope these applications will adopt this new libpciaccess
library and actually contribute back to it?  If not, thinking about
libpciaccess as a third party library that the Xorg project doesn't
have to maintain is just wishful thinking.

> > The debugging 
> > tools used on Linux, pciutils, already come with their own
> > abstraction layer.  So libpciaccess was basically developed just for
> > X, and is unlikely to be used for any other software packages.  I
> > really don't see your point, especially since adapting them requires
> > changes to almost all X drivers, even those that don't abuse the
> > current PCI abstraction layer.
> 
> Yeah, it's a shame that Ian had to write his own, but pciutils doesn't 
> have a license suitable for many projects...

Yup I'm part of such a project ;-).

Mark