New PCI API

[Till Straumann]

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:
>
>>
>> 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.
>
> Victor
>
>