pc386 PCI question

[Joel Sherrill]

gregory.menke at gsfc.nasa.gov wrote:

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

I have not looked at the *BSD one but since we recommend that driver
code be ported from there and not GNU/Linux due to license issues,
it would seem logical that if we were going to adopt one, it would be
that one.

With that said, I would be extremely happy just to see this happen:

(1) This bug fixed by someone who knows better than me. :)
(2) The multiple PCI APIs unified with a trend toward some
     standard one.
(3) More wholesale adoption of the adopted API with possible
     transition to their implementation if possible.


> Gregm
>