linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).