New PCI API

[gregory.menke at gsfc.nasa.gov]

Victor V. Vengerov writes:
 > Till Straumann wrote:
 > 
 > >
 > > Traditionally, the BSP simply provided macros
 > >
 > > PCI_MEM_BASE, PCI_IO_BASE, PCI_DRAM_OFFSET
 > > etc.
 > >
 > > This approach is not good enough when multiple
 > > 'PCI hoses' are involved.
 > >
 > > 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);
 > >
 > In some hardware, PCI bus is not mapped to memory at all - although 
 > indirect access is possible (e.g. write address to ADDR register, read 
 > from DATA register). (Simplest example is x86 PC :-) : I/O space is not 
 > memory-mapped and accessible through special instructions, but I have 
 > seen much more extravagant PCI bridges). Implementing of PCI API may be 
 > a good point to introduce primitives similar to Linux read{b,w,l}, 
 > write{b,w,l}, in{b,w,l}, out{b,w,l}, which accept address on PCI 
 > memory/IO space (in RTEMS case, hose number may be their argument as 
 > well). Ideally, it should be inlined. Drivers should avoid direct device 
 > memory/IO accesses. On traditional systems, these primitives are mapped 
 > to memory access, but arbitrary PCI bridges can be supported.

RTEMS more or less follows the Linux convention at least on the PPC
bsp's, however the base address of the operation must be computed- the
old macros were adding the fixed offset necessary to move the
transaction into pci memory space.  The new functions do the same, but
allow the user to select which of several regions will provide the
base address.

Have a look at the network board device drivers to see how its been
done historically on RTEMS.

Gregm