On Fri, Apr 23, 2021 at 10:51 PM Vinod Koul [off-list ref] wrote:

On 23-04-21, 15:51, Lars-Peter Clausen wrote:

quoted

On 4/23/21 3:24 PM, Vinod Koul wrote:

quoted

On 23-04-21, 11:17, Lars-Peter Clausen wrote:

quoted

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.

quoted

quoted

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