On Sat, Dec 06, 2014 at 12:31:01PM +0530, Jassi Brar wrote: > It does, though, create an "awkward situation" when a channel is > active while new requests are submitted - why would the channel want > to stop after current transfer and await fresh issue_pending()? It's > not that the request can be modified after submission. > > And it isn't that tx_submit() is meant for 'sleepable' preparation for > the transfer and we need another call to be issued from atomic > context. From what I see most drivers don't need to sleep in > tx_submit(). In fact, from a quick look most clients seem to suffer > from the ritual i.e, there's nothing between tx_submit() and > issue_pending() calls. And when there is indeed some code, it seems > that can be moved just before tx_submit(). > > Last and apparently the least of all, we can never enforce the same > behavior of the api on Async dma and have uniform behavior over the > api. > > So, if all tx_submit() does is put the request in controller driver's > internal queue and the client can't touch the request after > tx_submit(), why not merge the tx_submit() and issue_pending()? You are thinking from an API point and not what can be done with this API. Today this API allows you to collate all pending txn and start while dmaengine driver can collate and submit as a batch to hardware and not waste time in getting irq and then setting next one. Sadly none of the drivers use this feature... I actually like the split model, you can also prepare txn ahead of time and submit them when needed. If you don't like this, then please do as most implementation do today, call prepare and submit in series. Flexiblity in API is a better option IMO Thanks -- ~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
