On Mon, Sep 27, 2010 at 05:23:34PM +0200, Linus Walleij wrote: > 2010/9/25 Ira W. Snyder <i...@ovro.caltech.edu>: > > > This adds support for scatterlist to scatterlist DMA transfers. > > This is a good idea, we have a local function to do this in DMA40 already, > stedma40_memcpy_sg(). >
I think that having two devices that want to implement this functionality as part of the DMAEngine API is a good argument for making it available as part of the core API. I think it would be good to add this to struct dma_device, and add a capability (DMA_SG?) for it as well. I have looked at the stedma40_memcpy_sg() function, and I think we would want to extend it slightly for the generic API. Is there any good reason to prohibit scatterlists with different numbers of elements? For example: src scatterlist: 10 elements, each with 4K length (40K total) dst scatterlist: 40 elements, each with 1K length (40K total) The total length of both scatterlists is equal, but the number of scatterlist entries is different. The freescale DMA controller can handle this just fine. I'm proposing this function signature: struct dma_async_tx_descriptor * dma_memcpy_sg(struct dma_chan *chan, struct scatterlist *dst_sg, unsigned int dst_nents, struct scatterlist *src_sg, unsigned int src_nents, unsigned long flags); > > This is > > currently hidden behind a configuration option, which will allow drivers > > which need this functionality to select it individually. > > Why? Isn't it better to add this as a new capability flag > if you don't want to announce it? Or is the intent to save > memory footprint? > Dan wanted this, probably for memory footprint. If >1 driver is using it, I would rather have it as part of struct dma_device along with a capability. Thanks for the feedback, Ira _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev