On Fri, Feb 24, 2017 at 09:37:40PM +0100, Lars-Peter Clausen wrote: > 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. Yes but then should this be handled in drivers or moved to framework, I am thinking latter :) -- ~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
