On Thu, Aug 03, 2017 at 09:14:13AM -0700, Dan Williams 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. > > > > Great, anyone who disagrees or can give better names :) > > All my suggestions would involve a lot more work. If we had infinite > time we'd stop with the per-operation-type entry points and make this > look like a typical driver sub-system that takes commands like > block-devices or usb, but perhaps that ship has sailed. Can you elaborate on this :) I have been thinking about the need to redo the API. So lets discuss :) -- ~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
