Messages in this thread | | | Date | Fri, 18 Jun 2004 17:08:03 -0400 | From | Jeff Garzik <> | Subject | Re: DMA API issues |
| |
Ian Molton wrote: > Hi. > > This may have come up previously but I havent seen it, so... > > My colleagues and I are encountering a number of difficulties with the > DMA API, to which a generic solution is required (or risk multiple > architectures, busses, and devices going their own way...) > > Here is an example system that illustrates these problems: > > 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.
Unfortunately, I tend to think that you should not be using the DMA API for this, since it's not host RAM.
There are loads of devices with on-board SRAM/DRAM/... you really have to manage your own resources at that point.
I know that sucks, WRT driver re-use. Maybe you can wrap it inside the OHCI driver, ohci_dma_alloc_xxx() etc. For the normal case, the wrapper resolves directly to the DMA API. For the embedded case, the wrapper does SRAM-specific stuff.
You _might_ convince the kernel DMA gurus that this could be done by creating a driver-specific bus, and pointing struct device to that internal bus, but that seems like an awful lot of work as opposed to the wrappers.
Jeff
- 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/
| |