On 8 December 2014 at 18:37, Vinod Koul <vinod.koul@xxxxxxxxx> wrote: > 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. > "awkward situation" and "ritual suffering" above, are two practical issues that we see. > 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... > So we at least agree that the "feature" is unused so far. And I doubt if it would ever make sense to batch transfers in slave dma (unlike offloading on async-dma) because the user has to also setup the master for each queued request, mostly if not always. > 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 > As Russell pointed out, that ain't the case either. So we are yet to figure out benefits of having explicit issue_pending() after tx_submit(). -Jassi -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |