On Fri, Jun 18, 2004 at 05:59:02PM +0100, Ian Molton wrote:Your analysis of what is needed is correct. However, we would prefer to fit this into the DMA API in a generic way, rather than having a specialized API that is not acceptable upstream. I'm more concerned with finding the best way to address this problem than with whether this is a 2.6 or 2.7 issue.
I have a System On Chip device which, among other functions, contains an
OHCI controller and 32K of SRAM.
heres the catch:- The OHCI controller has a different address space than
the host bus, and worse, can *only* DMA data from its internal SRAM.
The architecture is not broken, merely unusual.
This causes the following problems:
1) The DMA API provides no methods to set up a mapping between the host
memory map and the devices view of the space
example:
the OHCI controller above would see its 32K of SRAM as
mapped from 0x10000 - 0x1ffff and not 0xXXX10000 - 0xXXX1ffff
which is the address the CPU sees.
2) The DMA API assumes the device can access SDRAM
example:
the OHCI controller base is mapped at 0x10000000 on my platform.
this is NOT is SDRAM, its in IO space.
Can't you just implement an arch-specific allocator for your 32KB
SRAM, then implement the DMA API streaming and dma_alloc/free APIs
on top of that? Since this architecture is obviously not designed
for performance, it doesn't seem to be a big deal to have the streaming
APIs copy to/from the kmalloced (or whatever) buffer to/from the SRAM
allocated memory and then have those APIs return the proper dma_addr_t
for the embedded OHCI's address space view of the SRAM. Same thing
goes for implementing dma_alloc/free (used by dma_pool*). I don't
have the knowledge of USB subsystem buffer usage to know how quickly
that little 32KB of SRAM is going to run out. But at a DMA API level,
this seems doable, albeit with the greater possibility of negative
retvals from these calls.