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

[Kate Feng]

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
drivers.
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
as one
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
> >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,

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.


Regards,
Kate