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

[Kate Feng]

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.


Regards,
Kate