On Fri, Apr 23, 2021 at 10:51 PM Vinod Koul <vkoul@xxxxxxxxxx> wrote: > > On 23-04-21, 15:51, Lars-Peter Clausen wrote: > > On 4/23/21 3:24 PM, Vinod Koul wrote: > > > On 23-04-21, 11:17, Lars-Peter Clausen wrote: > > > > It seems to me what we are missing from the DMAengine API is the equivalent > > > > of device_prep_dma_memcpy() that is able to take SG lists. There is already > > > > a memset_sg, it should be possible to add something similar for memcpy. > > > You mean something like dmaengine_prep_dma_sg() which was removed? > > > > > Ah, that's why I could have sworn we already had this! > > Even at that time we had the premise that we can bring the API back if > we had users. I think many have asked for it, but I havent seen a patch > with user yet :) Right. Back then we had also discussed bringing the dma_sg API but the idea was dropped as we didn't had a xilinx/any consumer client driver for it in the mainline kernel. I think it's the same state now. > > > > static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_sg( > > > struct dma_chan *chan, > > > struct scatterlist *dst_sg, unsigned int dst_nents, > > > struct scatterlist *src_sg, unsigned int src_nents, > > > unsigned long flags) > > > > > > The problem with this API is that it would work only when src_sg and > > > dst_sg is of similar nature, if not then how should one go about > > > copying...should we fill without a care for dst_sg being different than > > > src_sg as long as total data to be copied has enough space in dst... > > At least for the CDMA the only requirement is that both buffers have the > > same total size. > > I will merge if with a user but semantics need to be absolutely clear on > what is allowed and not, do I hear a volunteer ? > -- > ~Vinod
