PCI rework

[Mark Kettenis]

> From: Jesse Barnes <jbarnes at virtuousgeek.org>
> Date: Sun, 30 Apr 2006 11:06:50 -0700
> 
> On Sunday, April 30, 2006 5:22 am, Mark Kettenis wrote:
> > Matthieu Herb, asked me to have a look at libpciaccess some time ago.
> > My conclusion then was that it is too tightly bound to Linux.  It
> > takes the Linux sysfs pci access interface as a model instead of the
> > actual pci hardware.  I especially feel the support to map memory
> > associated with the PCI BAR's does not belong in the library.  It is
> > not impossible to implement the libpciaccess backend for other
> > operating systems, but it would be rather awkward.
> 
> X already assumes it can mmap memory BARs, do you think it needs to 
> change too?  It seems to me that the interface provided by libpciaccess 
> is fairly flexible, easy to use, and easily ported to new platforms (it 
> should be, it's based on the Linux internal PCI interfaces which have 
> prooven highly portable).  Do you have other examples where you think 
> Linux specific implementation details have crept into the interface?

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

> > Looking at your patch I see that changes to the drivers are mostly
> > changes like:
> >
> > -    *pucByte = pciReadByte(pMga->PciTag,ulOffset);
> > +    pci_device_cfg_read_u8( pMga->PciInfo, pucByte, ulOffset );
> >
> > So basically this is just replacing the current interfaces with the
> > equivalent libpciaccess interfaces.  Why not keep the current current
> > interfaces and reimplement them to use libpciaccess in the
> > Linux-specific Xorg code?
> 
> 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.

> > I really don't see any major flaws in the 
> > current xf86Pci.h interfaces, but I agree that some of the
> > implementation could use some cleanup.
> 
> 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.

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

>   o the PCI device discovery code needed by drivers is unnecessarily
>     complex

I'm not so sure about that.  Some amount of complexity will be needed
to deal with badly designed or buggy hardware and firmware.  Most of
these issues will be specific to particular PCI hardware.  Shoving
those into the domain of a seperate library, or the further down into
the operating system isn't a solution.

>   o ROM mapping is hard to port and buggy in some cases

By its very nature ROM's are unportable.  I really can't see how
libpciaccess would alleviate that situation.  The X hardware drivers
really should try to avoid depending on ROMs.

> libpciaccess directly addresses some of the above problems and makes the 
> others much easier to fix.  And its fundamental direction is correct as 
> well:  X should *not* have a big PCI abstraction layer of its own, it 
> should use the underlying OS via an external library for PCI related 
> operations.

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

Mark