PCI API (was : Add support for DEC/Intel 21150 PCI-PCI bridge)
feng1 at bnl.gov
Wed Mar 2 19:29:35 UTC 2005
gregory.menke at gsfc.nasa.gov wrote:
> Kate Feng writes:
> > 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
> The only way I can see this working would be to add a "pci #" to all
> the pci functions, in addition to the bus, slot and function numbers.
> I don't think its the right approach.
Can you explain further why it's not a right approach ? What is wrong
with it besides adding the "pci #" to existing driver ?
> > 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.
> All this is highly idiosyncratic to the hardware you're working with.
> It might make sense there, but it doesn't on other machines.
The bandwith I mentioned was just an example I used to remind that
programmers and users should be able to easily check out the system
design and performance on each PCI. This is another benefit of
adding the PCI number to the PCI API
> > I thoguht pre assigning eight buses on each PCI is enough. There should be
> > no need to set it to be 16. Right ?
> No, each pci bus tree should consume whatever number of busses it
> needs, 8, 99, 200, whatever.
Let's forget about the alternative. Adding the PCI number to the
PCI API would be a easy and straight forward soultion to consume any
number of buses.
More information about the users