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:

 > > > 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 guess I need to make sure I understand what you're talking about-
instead of a single interface to a single pci bus tree hanging off the
local processor bus, there is more than one tree, each entirely
separate from the others.  By which I mean, there is no single pci
bridge unifying access to all the sub-trees.

If thats so, than I still agree with your proposal for the config
access routines to "route" transactions to the correct bridge by
virtue of well-defined ranges of bus numbers.  The pci setup routines
would assign bus numbers (and address spaces) normally starting with
the first tree, continuing to increment them as the config pass moves
on to the subsequent trees.  The busses themselves don't care about
the specific bus numbers, as long as the ranges are set up properly.
So what you end up with are some number of trees, each still disjoint
from the other, but each one implementing a readily identifiable range
of busses.

But I think the transaction routing is possibly more complex than
busses, memory I/O also has to be directed to the correct root bridge-
unless the root bridges can claim the transactions by themselves.  I
get the impression you all aren't concerned about this point, so I
assume the hardware handles that part OK.

Gregm