[PATCH] dmaengine: pl330: Set residue in tx_status callback

[Jassi Brar]

On 8 December 2014 at 18:37, Vinod Koul <vinod.koul at intel.com> 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