Messages in this thread | | | Date | Fri, 18 Jun 2004 11:07:21 -0700 | From | Matt Porter <> | Subject | Re: DMA API issues |
| |
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.
-Matt - 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/
| |