On 02/24/2017 06:38 PM, Dave Jiang wrote: > > > On 02/24/2017 10:27 AM, Lars-Peter Clausen wrote: >> On 02/24/2017 06:19 PM, Dave Jiang wrote: >>> >>> >>> On 02/23/2017 05:41 PM, Dan Williams wrote: >>>> On Thu, Feb 23, 2017 at 4:13 PM, Vinod Koul <vinod.koul@xxxxxxxxx> wrote: >>>>> There have been discussions on need for change of dmaengine API for >>>>> a) allow sleepy invocation of the prepare descriptor so that drivers can >>>>> do the runtime pm (maybe move into core as well) >>>>> b) split the prepare operation to allocate and new prepare methods >>>> >>>> I'm wondering if you should you go even further and move to a more >>>> idiomatic model where a generic request is prepared outside the driver >>>> and passed in, rather than the current situation of requiring the >>>> driver to wrap a dma_async_tx_descriptor inside it's internal command >>>> structure. >>> >>> I wonder if we should support allowing proper batching of requests >>> before submission in the framework. Certain consumers of the DMA driver >>> can take advantage of that to improve performance. >> >> Some drivers already do this and the API allows this. issue_pending() is the >> operation that starts the transfer. So when a descriptor is submitted and >> there are already other descriptors pending it is OK to batch those >> descriptors together into one hardware-linked descriptor chain. >> > > Right, a lot of the mechanism is in the driver. And the prep call leaves > the submission lock held does it not? That prevents more prep calls > being invoked. That's not an issue, what you do is: prep() submit() prep() submit() ... prep() submit() issue_pending() All the descriptors submitted up to the issue_pending() can be batch into one hardware-linked list of descriptors. - Lars -- 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
