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. -- 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
