> On Aug 3, 2017, at 1:56 AM, Koul, Vinod <vinod.koul@xxxxxxxxx> wrote: > >> On Thu, Aug 03, 2017 at 11:06:13AM +0530, Jiang, Dave wrote: >> >> >>>> On Aug 2, 2017, at 10:25 PM, Koul, Vinod <vinod.koul@xxxxxxxxx> wrote: >>>> >>>> On Thu, Aug 03, 2017 at 10:41:51AM +0530, Jiang, Dave wrote: >>>> >>>> >>>>>> On Aug 2, 2017, at 9:58 PM, Koul, Vinod <vinod.koul@xxxxxxxxx> wrote: >>>>>> >>>>>> On Wed, Aug 02, 2017 at 02:13:56PM -0700, Dave Jiang wrote: >>>>>> >>>>>> >>>>>>> On 08/02/2017 02:10 PM, Sinan Kaya wrote: >>>>>>> On 8/2/2017 4:52 PM, Dave Jiang wrote: >>>>>>>>> Do we need a new API / new function, or new capability? >>>>>>>> Hmmm...you are right. I wonder if we need something like DMA_SG cap.... >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Unfortunately, DMA_SG means something else. Maybe, we need DMA_MEMCPY_SG >>>>>>> to be similar with DMA_MEMSET_SG. >>>>>> >>>>>> I'm ok with that if Vinod is. >>>>> >>>>> So what exactly is the ask here, are you trying to do MEMCPY or SG or MEMSET >>>>> or all :). We should have done bitfields for this though... >>>> >>>> Add DMA_MEMCPY_SG to transaction type. >>> >>> Not MEMSET right, then why not use DMA_SG, DMA_SG is supposed for >>> scatterlist to scatterlist copy which is used to check for >>> device_prep_dma_sg() calls >>> >> Right. But we are doing flat buffer to/from scatterlist, not sg to sg. So >> we need something separate than what DMA_SG is used for. > > Hmm, its SG-buffer and its memcpy, so should we call it DMA_SG_BUFFER, > since it is not memset (or is it) I would not call it memset, or maybe we > should also change DMA_SG to DMA_SG_SG to make it terribly clear :D I can create patches for both. > > -- > ~Vinod -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
