From: Sinan Kaya <okaya@codeaurora.org>
To: Vinod Koul <vinod.koul@intel.com>
Cc: dmaengine@vger.kernel.org, timur@codeaurora.org,
Christopher Covington <cov@codeaurora.org>,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback
Date: Thu, 4 Aug 2016 10:17:24 -0400 [thread overview]
Message-ID: <71a15611-645f-7523-1c26-14b420aff667@codeaurora.org> (raw)
In-Reply-To: <20160804125525.GF9681@localhost>
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.
Is the client supposed to do a memcmp ? (BTW, it doesn't make sense).
>> In my opinion, the new behavior is correct. Calling dma_cookie_complete(desc) all the time
>> > is not. Do you agree?
>> >
>> > If yes, I can divide this patch into two. One to correct the ordering. Another one
>> > for behavioral change.
> See above..
>
> A callback or tx_status will only tell you the txn is completed. That is
> why we have DMA_COMPLETE and not DMA_SUCCESS.
>
Still calling the callback and returning DMA_COMPLETE isn't right. There is no indication
of an actual DMA error. The transaction is complete but data integrity failed.
> So current order seems fine to me!
I posted v2 of this patch without introducing the behavior change leaving the behavior discussion
out for another patch. The current code will not call the callback if error was observed.
This patch is needed to fix a race condition as the commit message describes.
The callback is called before returning the descriptor back to free pool.
If the client calls free resources, the descriptor that was not returned to free pool gets lost due
to race condition.
I'll refactor the code after Dave's change for passing the error code while calling the
callback. That will be a different patch anyhow.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2016-08-04 14:17 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-14 2:57 Sinan Kaya
2016-07-16 1:00 ` Sinan Kaya
2016-07-24 6:24 ` Vinod Koul
2016-07-25 14:19 ` Sinan Kaya
2016-08-04 12:55 ` Vinod Koul
2016-08-04 14:17 ` Sinan Kaya [this message]
2016-08-04 14:40 ` Russell King - ARM Linux
2016-08-04 15:27 ` Sinan Kaya
2016-08-04 15:38 ` Russell King - ARM Linux
2016-08-04 15:59 ` Lars-Peter Clausen
2016-08-08 9:08 ` Vinod Koul
2016-08-08 12:25 ` Lars-Peter Clausen
2016-08-10 17:23 ` Vinod Koul
2016-08-04 16:08 ` Sinan Kaya
2016-08-04 16:15 ` Lars-Peter Clausen
2016-08-05 6:32 ` Robert Jarzmik
2016-08-05 8:34 ` Lars-Peter Clausen
2016-08-05 15:17 ` Sinan Kaya
2016-08-08 9:02 ` Vinod Koul
2016-08-08 14:45 ` Sinan Kaya
2016-08-10 17:28 ` Vinod Koul
2016-08-10 17:31 ` Sinan Kaya
2016-08-19 2:48 ` Vinod Koul
2016-08-19 3:26 ` Sinan Kaya
2016-08-19 3:42 ` Vinod Koul
2016-08-19 3:48 ` Sinan Kaya
2016-08-19 5:52 ` Vinod Koul
2016-08-19 11:13 ` okaya
2016-08-19 17:02 ` Vinod Koul
2016-08-19 17:21 ` Sinan Kaya
2016-08-22 6:08 ` Vinod Koul
2016-08-22 13:27 ` Sinan Kaya
2016-08-22 17:00 ` Vinod Koul
2016-08-08 8:51 ` Vinod Koul
2016-08-08 12:10 ` okaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=71a15611-645f-7523-1c26-14b420aff667@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=cov@codeaurora.org \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=timur@codeaurora.org \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®