Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1457758

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

From Lars-Peter Clausen <lars@metafoo.de>
Newsgroups linux.kernel
Subject Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback
Date 2016-08-08 14:30 +0200
Message-ID <s3RQS-1ls-23@gated-at.bofh.it> (permalink)
References (6 earlier) <s2s89-24U-5@gated-at.bofh.it> <s2sUx-2Lw-17@gated-at.bofh.it> <s2sUx-2Lw-15@gated-at.bofh.it> <s2tnA-3cA-33@gated-at.bofh.it> <s3OJj-7Q6-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Vinod Koul <vinod.koul@intel.com> - 2016-08-04 14:50 +0200
  Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Sinan Kaya <okaya@codeaurora.org> - 2016-08-04 16:20 +0200
    Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-08-04 16:50 +0200
      Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-08-04 17:40 +0200
        Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Sinan Kaya <okaya@codeaurora.org> - 2016-08-04 18:10 +0200
          Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Lars-Peter Clausen <lars@metafoo.de> - 2016-08-04 18:20 +0200
            Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback Robert Jarzmik <robert.jarzmik@free.fr> - 2016-08-05 08:40 +0200
              Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Lars-Peter Clausen <lars@metafoo.de> - 2016-08-05 10:40 +0200
                Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Sinan Kaya <okaya@codeaurora.org> - 2016-08-05 17:20 +0200
        Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Lars-Peter Clausen <lars@metafoo.de> - 2016-08-04 18:10 +0200
          Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Vinod Koul <vinod.koul@intel.com> - 2016-08-08 11:10 +0200
            Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Lars-Peter Clausen <lars@metafoo.de> - 2016-08-08 14:30 +0200
              Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Vinod Koul <vinod.koul@intel.com> - 2016-08-10 20:50 +0200
      Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Sinan Kaya <okaya@codeaurora.org> - 2016-08-04 17:40 +0200
        Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Vinod Koul <vinod.koul@intel.com> - 2016-08-08 11:00 +0200
          Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Sinan Kaya <okaya@codeaurora.org> - 2016-08-08 16:50 +0200
            Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Vinod Koul <vinod.koul@intel.com> - 2016-08-10 21:00 +0200
              Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Sinan Kaya <okaya@codeaurora.org> - 2016-08-10 22:50 +0200
    Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback Vinod Koul <vinod.koul@intel.com> - 2016-08-08 10:50 +0200
      Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the  callback okaya@codeaurora.org - 2016-08-08 14:20 +0200

csiph-web