PCI rework

[Egbert Eich]

Mark Kettenis writes:
 > > 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.

There is nothing wrong per se with having special mapping functions
for pci devices. Some OS require them or support a special interface
that should be favored over the more generic /dev/mem mapping.
On other OSes we will just implement these functions as calls to
the generic mapping function.
The DDX contains some code that was specifically introduced for
Alphas and would not be required for other platforms - still we
went thru the little additional pain to deal with these interfaces
on other platforms.

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

PCItag has proven to be a nightmare. It is too small to contain
all the information that you would like to have.
It is not really opaque either.
Replacing it with a structure that can hold os/platform specific
information makes a lot of sense. platform specific things like 
the AXP specific mapping requirements can be dealt with a lot
easier without having to bug everybody else with their quirks.

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

Yeah, this is true for OSes that don't deal with that.
Therefore I would like to move this into a layer where it
can be utilized if the OS does not handle it.
However I would like to simplify things. The translation from
bus to host address space seems to be insane.

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

It is already. This unfortunately doesn't fix problems but increases
them.

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

I don't really understand what is meant by the statement about the
discovery code.

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

Linux has a kernel interface for this. It's the safest to handle this
inside the kernel if remapping of PCI devices is not feasable.
Moving the existing code to a layer which can be utilized by OS 
layers if no such kernel interface exists seems to be the best
solution.
 > 

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

The library will allow us to experiment with different driver models
- including such outside of X - without the need to rip the PCI code
out of X at a later time.

Generally to support a wide range of OSes with a range of different
capabilities it may not be possible to avoid to move more things into
an OS specific layer. To reduce the pain we should keep infrastructure
that is needed by some but not all OSes into a layer where it can
optionally be used.

Cheers,
	Egbert.