On 02-07-21, 15:23, Adrian Larumbe wrote: > On 01.06.2021 15:59, radhey pandey wrote: > > 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. > > Would it be alright if I brought back the old DMA_SG interface that was removed > in commit c678fa66341c? It seems that what I've effectively done is > implementing the semantics of that API call under the guise of > dma_prep_slave. However I still need mem2mem SG transfer support on CDMA, which > seems long gone from the driver, even though the HW does offer it. > > If people are fine with it I can restore that interface and CDMA as the sole consumer. I guess I should start putting this regularly now! Yes it is okay to bring dma sg support, provided 1. We have a user 2. the sematics of how that api works is well defined. Esp in the case where is src_sg and dstn_sg are different Also, I would not accept patches which implement this in guise of a different API. Thanks -- ~Vinod
