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

[Till Straumann]

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 ?
>
Again:
 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 
revolutionary
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 
downstream
of the same hostbridge (aka PCI #) --> as long as you document the order 
in which
the peer bridges are traversed, the user can always track a 
bus/dev/fn-tuple to a
unique device.

>>  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...

Regards
-- Till

>
>
>Regards,
>Kate
>
>
>
>  
>