Thread (35 messages) 35 messages, 5 authors, 2016-08-22

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

From: lars@metafoo.de (Lars-Peter Clausen)
Date: 2016-08-08 12:25:50
Also in: linux-arm-msm, lkml

On 08/08/2016 11:08 AM, Vinod Koul wrote:
On Thu, Aug 04, 2016 at 05:59:30PM +0200, Lars-Peter Clausen wrote:
quoted
On 08/04/2016 05:38 PM, Russell King - ARM Linux wrote:
[...]
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help