New PCI API

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Tue Jul 12 19:31:05 UTC 2005


Till Straumann writes:
 > A while ago there was a discussion about how
 > BSPs with more than one PCI bus attached to
 > the host bridge should be handled (i.e., there
 > is no 'root' bridge combining the two busses).
 > 
 > I believe we agreed upon letting the BSP hide
 > this architecture and taking care of chosing the
 > right 'hose' based on the bus#.
 > 

I think this is the right idea.


 > 
 > Therefore, I'd propose to deprecate those macros
 > and require BSPs to provide routines e.g.,
 > 
 >    /* return pci busx memory space as seen from CPU */ 
 > void *pci_mem_base(int busx);
 >    /* return pci busx IO space as seen from CPU */
 > void *pci_io_base(int busx);
 >    /* board memory as seen from PCI busx */
 > void *pci_ram_base(int busx);
 > 

Just for clarity, does this mean drivers using the deprecated macro's
should assume bus 0?

I think there may need to be some additional bus selection semantics
for those cases when hardware is dispersed on the several busses-
particularly for the lan board drivers.  Maybe an additional field
added to 'struct rtems_bsdnet_ifconfig' perhaps?

Gregm




More information about the users mailing list