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