On Wed, Aug 16, 2017 at 9:50 AM, Vinod Koul <vinod.k...@intel.com> wrote: > 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 :)
The high level is straightforward, the devil is in the details. Define a generic dma command object, perhaps 'struct dma_io' certainly not 'struct dma_async_tx_descriptor', and have just one entry point per-driver. That 'struct dma_io' would carry a generic command number a target address and a scatterlist. The driver entry point would then convert and build the command to the hardware command format plus submission queue. The basic driving design principle is convert all the current function pointer complexity with the prep_* routines into data structure complexity in the common command format. This trades off some efficiency because now you need to write the generic command and write the descriptor, but I think if the operation is worth offloading those conversion costs must already be in the noise. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
