PCI API (was : Add support for DEC/Intel 21150 PCI-PCI bridge)
strauman at slac.stanford.edu
Wed Mar 2 21:12:39 UTC 2005
Kate Feng wrote:
>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 ?
1) changes existing, fully sufficient API.
2) your proposal conflicts with anything existing outside of RTEMS
(e.g., pci-bios, bsd, linux) which
makes porting a nightmare
3) unnecessarily exposes details about your specific hardware that are
better hidden by abstraction
4) just look at the name: you named the new parameter 'pci number'
when it really is 'pci bus number'
- however, this parameter already exists.
OTOH you have not yet come up with a single argument in favor of this
API change besides not having to perform a few tiny changes to your code.
>> > 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.
Nonsense. If the user prefers to use a particular bus segment, e.g.,
because it features
a higher bandwidth she has to use the HW-manual to locate a proper slot
and stick the
card in there. What bus number is assigned by the firmware and system
usually doesn't matter.
If it does in a particular case [e.g., because two identical cards are
on different bus segments
and the application software needs to distinguish them] then you need to
know about your
HW topology anyways. Having the explicit hostbridge number doesn't
greatly help you -
it's easy to imagine a situation where two identical cards are somewhere
of the same hostbridge (aka PCI #) --> as long as you document the order
the peer bridges are traversed, the user can always track a
bus/dev/fn-tuple to a
>> 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
If they want to know details about the system they can look at the
HW-manual. The whole
point of an operating system is abstraction from the HW.
>> > 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.
So is the existing one. IMHO and with all due respect - this proposed
API change is not acceptable.
I think I repeatedly made my point and I'll shut up now...
More information about the users