On 08/03/2017 09:14 AM, Dan Williams wrote: > On Thu, Aug 3, 2017 at 8:55 AM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote: >> On Thu, Aug 03, 2017 at 08:06:07PM +0530, Jiang, Dave wrote: >>> >>> >>>> 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. >> >> 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. > Allen, isn't this what we were just talking about on IRC yesterday? <allenbh> I dislike prep_tx grabbing a device-specific descriptor. The device really only needs as many device-specific descriptors will keep the hw busy, and just let the logical layer queue up logical descriptors until hw descriptors become available. Let the client allocate descriptors to submit, and hw driver can translate to a hardware-specific descriptor at the last moment before notifying the hw. -- 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
