From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback
Date: Thu, 4 Aug 2016 18:25:25 +0530 [thread overview]
Message-ID: <20160804125525.GF9681@localhost> (raw)
In-Reply-To: <971733d9-fd18-2a1b-07c0-349b47747d49@codeaurora.org>
On Mon, Jul 25, 2016 at 10:19:44AM -0400, Sinan Kaya wrote:
> >>
> >> It looks like I introduced a behavioral change while refactoring the code.
> >> The previous one would call the callback only if the transfer was successful
> >> but it would always call dma_cookie_complete.
> >>
> >> The new behavior is to call dma_cookie_complete only if the transfer is successful
> >> and it calls the callback even in the case of error cases. Then, the client has
> >> to query if transfer was successful.
> >>
> >> Which one is the correct behavior?
> >
> > Hi Sinan,
> >
> > Cookie is always completed. That simply means trasactions was completed and
> > has no indication if the transaction was successfull or not.
> >
> > Uptill now we had no way of reporting error, Dave's series adds that up, so
> > you can use it.
> >
> > Callback is optional for users. Again we didnt convey success of
> > transaction, but a callback for reporting that trasaction was completed. So
> > invoking callback makes sense everytime.
> >
>
> Let's put Dave's series aside for the moment and assume an error case where
> something bad happened during the transfer. I can add the error code once Dave's
> series get merged.
Fair enough..
> Here is the callback from dmatest.
>
> static void dmatest_callback(void *arg)
> {
> done->done = true;
> }
>
> Here is how the request is made.
>
> dma_async_issue_pending(chan);
>
> wait_event_freezable_timeout(done_wait, done.done,
> msecs_to_jiffies(params->timeout));
>
> status = dma_async_is_tx_complete(chan, cookie, NULL, NULL);
> if (!done.done) {
> timeout
> } else if (status != DMA_COMPLETE) {
> error
> }
>
> success.
>
> Based on what I see here, receiving callback all the time is OK. The client
> checks if the callback is received or not first.
Callback is optional from API PoV. Yes ppl do implement it :)
> Next, the client checks the status of the tx_status.
>
> In the error case mentioned, the callback will be executed. done.done will be true.
>
> If I set dma_cookie_complete(desc) in error case, it would be wrong to tell the client
> that the transfer is successful.
And here is the thing that you missed :)
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.
> 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.
So current order seems fine to me!
--
~Vinod
next prev parent reply other threads:[~2016-08-04 12:55 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-14 2:57 [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback 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 [this message]
2016-08-04 14:17 ` Sinan Kaya
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 at codeaurora.org
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 at codeaurora.org
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=20160804125525.GF9681@localhost \
--to=vinod.koul@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).