Hi Haavard, On 10/24/07, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > This patch corrects what I hope are invalid assumptions about the DMA > engine layer: Not only Intel(R) hardware can do DMA, and DMA can be > used for other things than memcpy and RAID offloading. > > At the same time, make the DMA Engine menu visible again on AVR32. I'm > currently working on a driver for a DMA controller that can do > mem-to-mem transfers (which is supported by the framework) as well as > device-to-mem and mem-to-device transfers (not currently supported.) > > Signed-off-by: Haavard Skinnemoen <[EMAIL PROTECTED]> > --- > Don't get me wrong; I think Intel deserves lots of respect for > creating this framework. But this is also why I got a bit disappointed > when I discovered that it seems to be less generic than I initially > hoped. >
Patches welcome :-) > DMA controllers, which may support plain memcpy acceleration in > addition to more traditional "slave DMA", are very common in SoC > devices, and I think Linux needs a common framework for it. The > existing DMA Engine framework seems to come pretty close already, but > I think it needs more input from the embedded crowd before it can be > completely usable on a large number of embedded systems. > Part of the problem of supporting slave/device DMA along side generic memcpy/xor/memset acceleration is that it adds a number of caveats and restrictions to the interface. One idea is to create another client layer, similar to async_tx, that can handle the architecture specific address, bus, and device pairing restrictions. In other words make device-dma a superset of the generic offload capabilities and move it to its own channel management layer. > I'm not going to suggest any changes to the actual framework for > 2.6.24, but I think the _intention_ of the framework needs to be > clarified. > Should this patch wait until the framework has been extended? Otherwise, Acked-by: Dan Williams <[EMAIL PROTECTED]> > Haavard > Regards, Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
