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

[gregory.menke at gsfc.nasa.gov]

Till Straumann writes:
 > gregory.menke at gsfc.nasa.gov wrote:
 > 
 > >Till Straumann writes:

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

This is the right way to go in my opinion.

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

But if the bus numbers are set up properly than it simply doesn't
matter.  In general its bad form to hardcode bus numbers- or in fact
assume anything at all about how they are assigned within the tree.
Similar to how its a bad idea to hardcode slots and interrupt vectors.
If the goal is to find hardware located someplace on the bus tree,
then some variation of the "find device" functions can recurse the
tree and find it by vendor and product id.  Client software then
treats the bus number as an opaque value, just like it does with slot.

Gregm



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