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


Groups > linux.kernel > #1456444

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

From Russell King - ARM Linux <linux@armlinux.org.uk>
Newsgroups linux.kernel
Subject Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback
Date 2016-08-04 16:50 +0200
Message-ID <s2s89-24U-5@gated-at.bofh.it> (permalink)
References (1 earlier) <rVmhb-5I5-1@gated-at.bofh.it> <rYkVz-4mo-3@gated-at.bofh.it> <rYP3k-5F3-15@gated-at.bofh.it> <s2qg1-IE-1@gated-at.bofh.it> <s2rF7-1SU-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Aug 04, 2016 at 10:17:24AM -0400, Sinan Kaya wrote:
> On 8/4/2016 8:55 AM, Vinod Koul wrote:
> > Dmaengine tells transaction is complete. It does not say if the txn is
> > success or failure. It can transfer data and not say if data was
> > correct. A successful transaction implies data integrity as well, which
> > dmaengine can't provide.
> 
> Thanks for describing this. I was confused about DMA_SUCCESS and DMA_COMPLETE.
> I now understand that tx_success API just returns information that the request
> was executed whether the result is error or not. This makes sense now.
> 
> However, if the txn is failure; then we should never call the client callback
> since DMA engine cannot provide such feedback to the client without Dave's patch.
> You are saying that the calling the callback is optional.
> 
> Then, the callback cannot be optional in the error case for old behavior.
> 
> How does the client know if memcpy executed or not? The client got its callback
> and tx_status is also DMA_COMPLETE.

If an error occurred, then dma_async_is_tx_complete() is supposed to
return DMA_ERROR.  It's up to the DMA engine driver to ensure that
this happens if it has error detection abilities.

Most of the helpers in drivers/dma/dmaengine.h are there to _assist_
the driver writer - they can't do magic.  dma_cookie_status() will
return from the point of view of the generic DMA code what the status
of a particular cookie is, and the cookie state.  It doesn't take
care of whether a particular transaction associated with a cookie
failed or not - that's up to the driver.

So, if dma_cookie_status() says that a cookie has DMA_COMPLETED
status, and the DMA engine is able to detect errors on individual
transfers, then the driver needs to do further status lookup to
determine whether the particular transaction referred to by the
cookie did fail, and modify the returned status appropriately.

If dma_cookie_status() says that the cookie is DMA_IN_PROGRESS,
then the driver is expected to calculate and report the residue
(the remaining number of bytes) of the referred to transaction.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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