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

[Kate Feng]

"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