Good points, you bring up. I fully agree.
We already have in_le32, out_be32, &friends but they certainly assume memory-mapped I/O or at least a common I/O scheme for all busses (covers PCI IO access on x86).
Downside of a generic approach is that it's a complex design task...
T.
Victor V. Vengerov wrote:
Till Straumann wrote:
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.
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);
Victor