PCI API (was : Add support for DEC/Intel 21150 PCI-PCI bridge)
feng1 at bnl.gov
Wed Mar 2 15:33:01 UTC 2005
Till Straumann wrote:
> 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.
Pre assigning a range of bus number was what I had in mind as an alternative
if one does insist not to change the PCI API of the previous written drivers.
I never meant to hardcode the PCI bus number or to write 255 copies of
I meant that the BSP_pciFindDevice() should return the PCI number as well in
additional to the bus number, device number and function number to reflect the
hardware architecture. It would be less confusing that the PCI number is used
of the paramerts in pci_write_config_xxx() and pci_read_config_xxx().
After all, each of the PCI0 and PCI1 have 66 MHZ of PCI bandwidth for the PCI
devices. Bypassing the PCI number, one would have to keep remembering
bus number 0 .. 7 share 66 MHZ bandwidth, and bus number 8..15 share
another 66 MHZ bandwidth. This might not be a big deal anyway if it is
really painful to modify the previous written drivers.
I thoguht pre assigning eight buses on each PCI is enough. There should be
no need to set it to be 16. Right ?
See more below.
> > > 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
> Sure - but unless the peer hostbridge hardware has some magic to handle
> 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,
My magic tale is another concept. The original proposal would limit the
future applications of hot changing the PCI system configuration leaving other
part of PCI devices (e.g. 1 GHZ networrk) intact while the system
is still running.
More information about the users