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

[Till Straumann]

I strongly object to the proposition that RTEMS should make the
presence of PCI peer hostbridges explicit in the API.

The introduction of this 'new API' breaks anything that is written for PCI
such as generic support routines or drivers which use the standard
bus/dev/fnc - tuple. All of those would now need the new 'peer-number'
parameter. Look at a complex system like Linux which can support machines
with a much more complicated architecture than the MVME5500. Nonetheless,
all linux drivers can locate a device by the standard bus/dev/fnc-tuple.

The statement that this API 'provides backwards compatibility...' is wrong
(it simply maps the traditional calls to the first peer which means that
drivers still need to be rewritten if the device happens to sit on 
another bus)

T.

Kate Feng wrote:

>"Joel Sherrill " wrote:
>
>  
>
>>Kate is on vacation but I have asked her to try to eliminate the BSP
>>specific pci.h in the MVME5500.  The long term goal is that
>><rtems/pci.h> should completely define the PCI API.
>>    
>>
>
>Yes, I can provide you a portable pci.h and move (instead of
>eliminating) the BSP specific stuff to a different file.
>
>  
>
>>Till suggested that the use of pci0_* and pci1_ constants and functions
>>was an indication that the bus number parameter should have been
>>used,  Using it would eliminate a lot.  Then the PCI[01]_ stuff in that
>>pci.h can be eliminated.
>>
>>    
>>
>
>I am not sure if there is a need to change the PCI API on the mvme5500.
>My existing BSP does provide backward compatibillty with the previous
>PPC shared functions (e.g. pci_read_config_byte ).   It is implemented
>in pci.c.  That is to say one can port any previous PCI driver to MVME5500
>without any change regarding the PCI function calls.  This is why  the BSP
>painlessly ports  the VME driver written by Till Starumann.
>
>
>In light of the PMCspan module, I  feel that one should not hide
>or eliminate the fact that the mvme5500 has two loca PCIs.
>In fact, the  provided PCIx_read_config_XXX() facilitates
>the PCI device driver development and dynamic test/debugging
>via cexp.
>
>
>Till straumann wrote :
>
>  
>
>>E.g.,
>>
>>struct {
>>   volatile unsigned char * config_addr; *data_addr;
>>   pci_config_access_functions access;
>>} BSP_pci_config_access[MAX_PEERS]; /* filled by BSP */
>>
>>/* generic code */
>>int n_subordinates[MAX_PEERS];
>>/* filled by generic init code when counting bus numbers */
>>
>>pci_read_config_byte(unchar bus, unchar dev, unchar func, unchar offset)
>>{
>>int peer;
>>if ( bus>= ucMaxPCIBus)
>>    return -1;
>>for (peer=0; peer_subordinates[peer] < bus; peer++)
>>   bus -= peer_subordinates[peer];
>>return
>>BSP_pci_config_access[peer].read_config_byte(peer,bus,dev,func,offset);
>>}
>>
>>    
>>
>
>The ucMaxPCIBus is the value retuned from the BSP  initilaization.
>This means the BSP will have to setup an array to keep track of the
>bus number on the devices found on PCI1 (e.g. 1GHZ  and application
>related PMC modules) depending on the number of buses (PMCspan
>and the number of PMC devices) presented on the PCI0.
>The proposed method complicated the dynamic
>debug/test via cexp depending on the system PCI bus configurations.
>
>
>Joel, I hope your welcome back surprise agrees with me.
>
>
>P.S.  you probably know by now,  the DEC21150 is unrelated to
>DEC21140.
>
>
>Regards,
>Kate
>
>
>
>  
>