Messages in this thread | | | Date | Wed, 24 Oct 2007 08:55:58 -0700 | From | "Dan Williams" <> | Subject | Re: [PATCH] DMA: Correct invalid assumptions in the Kconfig text |
| |
Hi Haavard,
On 10/24/07, Haavard Skinnemoen <hskinnemoen@atmel.com> 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 <hskinnemoen@atmel.com> > --- > 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 <dan.j.williams@intel.com>
> Haavard >
Regards, Dan - 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/
| |