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

[Till Straumann]

gregory.menke at gsfc.nasa.gov wrote:

>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.
>
Sure - but unless the peer hostbridge hardware has some magic to handle 
peers
you have to handle this in software. Maybe the MVME5500 does not have 
this magic
(don't have the discovery docs), i.e., the peer bridges each have their own
individual 'space' of b/d/f-tuples. In this case, we must handle peer 
bridges in software,
e.g., with the scheme I proposed (init code polls all peer bridges for 
the number of
sub-busses behind them and collapses them into a single range. Config access
routines then determine from the unified bus number to which hostbridge the
access needs to be made).

I don't see a way around this - do you?

T.

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