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

[Till Straumann]

gregory.menke at gsfc.nasa.gov wrote:

>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?
>
Just a clarification: we're talking about 'peer hostbridges' here. Kate 
proposes to introduce
the hostbridge number (and not the PCI bus number) as an explicit 
parameter/part of the API
so you would need as many copies as the board has peer hostbridges.

OTOH, I suggested to collapse the individual ranges of sub-busses behind 
peer hostbridges
into one single range in order to make the presence of peers transparent 
to the API.

E.g., if a given board has 2 peer hostbridges and a given PCI 
configuration (i.e., native
devices + PMC cards and extensions etc)  results in the first hostbridge 
having 8 sub-busses
and the second one 5 then I would collapse the two bus trees into one 
ranging from
bus #0..12. Only the configuration access routines (which are a  BSP 
dependent piece)
would know that bus #0..7 actually reside at the first hostbridge and 
8..12 -> bus #0..4
at the second one.

T.

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