pc386 PCI question

[gregory.menke at gsfc.nasa.gov]

Till Straumann writes:
 > gregory.menke at gsfc.nasa.gov wrote:
 > > Joel Sherrill writes:
 > >  > 
 > >  > This was sent directly to me and the return address
 > >  > appeared to be hidden.  First, I don't know what network
 > >  > device driver is being used.  Second, this is an
 > >  > apparent inconsistency in the i386/shared code.  The
 > >  > file pci/pcibios.c is referencing those symbols
 > >  > (BusCountPCI and BSP_pciFindDevice) and I do not know
 > >  > where (or if) they are supposed to be.  I would appreciate
 > >  > some insite from someone out there so this can really be
 > >  > resolved.
 > >  > 
 > >  > --joel
 > > 
 > 
 > BSP_pciFindDevice() was introduced by PR432.
 > 
 > Note that libbsp/i386/shared/pcibios.c *already*
 > ships pcib_find_by_devid() which, I suppose, provides
 > the desired functionality.

I think I recall considering using it, but thought that
BSP_pciFindDevice() had more appropriate semantics.  Something like
that anyway...


 > What's really needed is not a second implementation
 > but a unified API (as has been noted previously).

Absolutely right.

 
 > All that's needed is a willing person to take on the job ;-)
 > 
 > It would make sense to adopt an API defined by an OS where
 > most drivers are expected to be ported from.
 > 
 > -- Till

We really need it badly.  I think there is some potential that we
might be able to work on it soon, theres work on a coldfire w/ cpci
backplane going on- if it comes to fruition, then there will be a 3rd
architecture needing PCI support and we'll have to face the issue.

Personally I'd like to see the PowerPC pci api become "standard" in
RTEMS.  It seems fairly complete, sort of conformant with Linux and
already has a device-driver like arrangment so different PCI chipsets
can be supported.  The i386 pci functions would then be implemented on
top of it for backwards compatibility.

Is there any consensus on what the PCI API should look like?

Gregm