Re: [PATCH 0/4] Expand Xilinx CDMA functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :)

> > 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



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux