Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

[Lars-Peter Clausen]

On 08/08/2016 11:08 AM, Vinod Koul wrote:
> On Thu, Aug 04, 2016 at 05:59:30PM +0200, Lars-Peter Clausen wrote:
>> On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote:
>> [...]
>>> What you instead need to do is to find some way to record in your
>>> driver that transaction 2 failed, and when dma_cookie_status() says
>>> that a transaction has DMA_COMPLETE status, you need to look up to
>>> see whether it failed.
>>
>> In my opinion this is where the current API is broken by design. For each
>> transfer that fails you need to store the cookie associated with that
>> transfer in some kind of lookup table. Since there is no lifetime associated
>> with a cookie entries in this table would need to be retained forever and it
>> will grow unbound.
> 
> And how many drivers can report errors? And how many drivers can guarantee
> DMA_COMPLETE implies transaction was succesful.

The former just a handful, the later hopefully all.

> 
>> Ideally we'd mark error reporting through this interface as deprecated and
>> discourage new users of the interface. As far as I can see most of the few
>> drivers that do return DMA_ERROR get it wrong anyway, e.g. return it
>> unconditionally for all cookies when an error occurred for any of them.
> 
> Error reporting is quite tricky as detection is a problem. So yes if you
> can do so, it is highly encouraged to report using new interface which is
> better than client checking after callback.
> 
> Btw what is the behaviour after error? I would think that client will see an
> error and report to upper layer while initiaite closure of transaction. So
> does driver need to keep the state for a longer time :-)

The problem is that this is not really clearly defined.

1) What should be done when multiple descriptors are queued and an error is
encountered on one of them. Should the descriptors that are after the one in
the queue that caused the error be discarded or should they be executed as
normal?

2) How long does a error result need to be retained. Can it be discarded
when the terminate_all() is called, or can it be discarded when the next
issue_pending() is called or should it be retained forever?

Unless we can clearly define the semantics of error reporting it is very
difficult for drivers to use it. Which is probably one of the reasons why
there are only very few DMAengine consumers that do actual error checking.