Messages in this thread | | | Date | Fri, 18 Jun 2004 14:33:18 -0400 | From | Jamey Hicks <> | Subject | Re: DMA API issues |
| |
Matt Porter wrote:
>On Fri, Jun 18, 2004 at 05:59:02PM +0100, Ian Molton wrote: > > >>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. > > > 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.
We do need a memory allocator for the pool of SRAM. If we're not going to have to build customized versions of the OHCI driver, we need that pool hooked into the dma_pool and dma_alloc_coherent interfaces. We could do that with a platform specific implementation of dma_alloc_coherent, but a pointer to dma_{alloc,free} from struct device seems like a cleaner solution. We also will need bounce buffers, as you described, but there is already a good start towards that support in 2.6. The other thing that might be needed is passing device to page_to_dma so that device specific dma addresses can be constructed.
Deepak Saxena wrote a pretty good summary as part if the discussion about this issue on the linux-arm-kernel mailing list:
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-June/022796.html
I think I'm looking for something like the PARISC hppa_dma_ops but more generic: http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-June/022813.html
Jamey Hicks
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |