PCI API (was : Add support for DEC/Intel 21150 PCI-PCI bridge)

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Tue Mar 1 19:31:27 UTC 2005


Till Straumann writes:
 > I strongly object to the proposition that RTEMS should make the
 > presence of PCI peer hostbridges explicit in the API.
 > 
 > The introduction of this 'new API' breaks anything that is written for PCI
 > such as generic support routines or drivers which use the standard
 > bus/dev/fnc - tuple. All of those would now need the new 'peer-number'
 > parameter. Look at a complex system like Linux which can support machines
 > with a much more complicated architecture than the MVME5500. Nonetheless,
 > all linux drivers can locate a device by the standard bus/dev/fnc-tuple.
 > 
 > The statement that this API 'provides backwards compatibility...' is wrong
 > (it simply maps the traditional calls to the first peer which means that
 > drivers still need to be rewritten if the device happens to sit on 
 > another bus)
 > 
 > T.

I'm with Till on this one.  I routinely use RTEMS on our mcp750's
which include up to 3 pci bridge hops to the target devices-
specifically I have a PMC dec21143 lan board which can go in the
mcp750's PMC carrier slot, or it can go on a pmc carrier board on the
backplane.  Any api that makes me use different functions to get to
the board in these different circumstances is fundamentally and
fatally broken as far as I'm concerned.  I can't see any good reason
for coding the bus # in the function prototype, thats what the bus
parameter is for.  If the desire is to bury the bus # someplace, do it
like linux does using macrology.

Hardcoding the bus # in the api doesn't help driver development and
debugging in any way.  I've written one driver and substantially
updated another, and facing this multiple api proposal would drive me
crazy.  And even if it was desirable for some reason, I'd still need
to see the proposal for how drivers are supposed to choose which api
functions they use.  And does this mean we would need 254 copies of
the api for all the possible busses?

If the problem is boot-time configuration of bridges so the bus
numbers are set up and address spaces arranged so things work, then
that should be solved by a boot-time algorithm similar to how the
motorola_shared bootloader does it.

I'm entirely in favor of a unified pci api, but I think it shouldn't
offer too much arbitrary strangeness.

Gregm




 > Kate Feng wrote:
 > 
 > >"Joel Sherrill " wrote:
 > >
 > >  
 > >
 > >>Kate is on vacation but I have asked her to try to eliminate the BSP
 > >>specific pci.h in the MVME5500.  The long term goal is that
 > >><rtems/pci.h> should completely define the PCI API.
 > >>    
 > >>
 > >
 > >Yes, I can provide you a portable pci.h and move (instead of
 > >eliminating) the BSP specific stuff to a different file.
 > >
 > >  
 > >
 > >>Till suggested that the use of pci0_* and pci1_ constants and functions
 > >>was an indication that the bus number parameter should have been
 > >>used,  Using it would eliminate a lot.  Then the PCI[01]_ stuff in that
 > >>pci.h can be eliminated.
 > >>
 > >>    
 > >>
 > >
 > >I am not sure if there is a need to change the PCI API on the mvme5500.
 > >My existing BSP does provide backward compatibillty with the previous
 > >PPC shared functions (e.g. pci_read_config_byte ).   It is implemented
 > >in pci.c.  That is to say one can port any previous PCI driver to MVME5500
 > >without any change regarding the PCI function calls.  This is why  the BSP
 > >painlessly ports  the VME driver written by Till Starumann.
 > >
 > >
 > >In light of the PMCspan module, I  feel that one should not hide
 > >or eliminate the fact that the mvme5500 has two loca PCIs.
 > >In fact, the  provided PCIx_read_config_XXX() facilitates
 > >the PCI device driver development and dynamic test/debugging
 > >via cexp.
 > >
 > >
 > >Till straumann wrote :
 > >
 > >  
 > >
 > >>E.g.,
 > >>
 > >>struct {
 > >>   volatile unsigned char * config_addr; *data_addr;
 > >>   pci_config_access_functions access;
 > >>} BSP_pci_config_access[MAX_PEERS]; /* filled by BSP */
 > >>
 > >>/* generic code */
 > >>int n_subordinates[MAX_PEERS];
 > >>/* filled by generic init code when counting bus numbers */
 > >>
 > >>pci_read_config_byte(unchar bus, unchar dev, unchar func, unchar offset)
 > >>{
 > >>int peer;
 > >>if ( bus>= ucMaxPCIBus)
 > >>    return -1;
 > >>for (peer=0; peer_subordinates[peer] < bus; peer++)
 > >>   bus -= peer_subordinates[peer];
 > >>return
 > >>BSP_pci_config_access[peer].read_config_byte(peer,bus,dev,func,offset);
 > >>}
 > >>
 > >>    
 > >>
 > >
 > >The ucMaxPCIBus is the value retuned from the BSP  initilaization.
 > >This means the BSP will have to setup an array to keep track of the
 > >bus number on the devices found on PCI1 (e.g. 1GHZ  and application
 > >related PMC modules) depending on the number of buses (PMCspan
 > >and the number of PMC devices) presented on the PCI0.
 > >The proposed method complicated the dynamic
 > >debug/test via cexp depending on the system PCI bus configurations.
 > >
 > >
 > >Joel, I hope your welcome back surprise agrees with me.
 > >
 > >
 > >P.S.  you probably know by now,  the DEC21150 is unrelated to
 > >DEC21140.
 > >
 > >
 > >Regards,




More information about the users mailing list