On Mon, Sep 27, 2010 at 10:23 AM, Ira W. Snyder <i...@ovro.caltech.edu> wrote: > 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,
Yes, I did not see a reason to increment the size of dmaengine.o for everyone if only one out-of-tree user of the function existed. > I would rather have it as part of struct dma_device along with a > capability. I think having this as a dma_device method makes sense now that more than one driver would implement it, and let's drivers see the entirety of the transaction in one call. -- Dan _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
