All of lore.kernel.org
 help / color / mirror / Atom feed
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] DMA: extend documentation to provide more API details
Date: Thu, 10 Oct 2013 21:45:09 +0530	[thread overview]
Message-ID: <20131010161509.GC2954@intel.com> (raw)
In-Reply-To: <CAA9_cmdSh8j5rmzZ=SsOG_pRa+Aq1odEEWKvVNOUv9G0Ma=dEw@mail.gmail.com>

On Tue, Oct 08, 2013 at 06:34:42PM -0700, Dan Williams wrote:
> On Mon, Oct 7, 2013 at 3:39 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> > On Mon, Oct 07, 2013 at 12:17:28PM +0100, Russell King - ARM Linux wrote:
> >> On Mon, Oct 07, 2013 at 12:45:33PM +0200, Guennadi Liakhovetski wrote:
> >> > No, not something in the middle. I was thinking about
> >> >
> >> > (1) cookie 1-3 are submitted
> >> > (2) cookie 1 succeeds
> >> > (3) a DMA error occurs, cookies 2-3 are discarded
> > discarded using terminate_all right?
> >
> >> > (4) cookie 4 is submitted and succeeds
> >> > (5) the user requests status of cookie 2 and gets success back, AFAICS
> > No you cant!, you can only request for 4..
> >>
> >> This is a side effect of using a sequential cookie based system to indicate
> >> whether a descriptor has succeeded or not.
> > In the above case, since user calls terminate_all we can put a rule that
> > terminate should reset the cookie counter.
> > So after the terminate_all the cookies are sequentially valid!
> 
> I think you and Guennadi address this later in the thread, but I think
> cookie values should always increase.  I see nothing but trouble if
> cookie values are allowed to go backwards.
Ok, my idea was to do this in terminate_all ONLY which is complete reset for a
channel. Anything done before that should not be valid and should not e
referenced!
But am okay to drop the idea...

> > Anyways as pointed above user shouldnt check for 2, he should have removed all
> > refs till 3 before calling terminate.
> >
> >> What may be better is to change the wording here: not DMA_SUCCESS but
> >> DMA_COMPLETED.  That doesn't imply that it has been successful, merely
> >> that the DMA engine has finished with the transaction.
> > Agreed that its not indication of success but of DMA completetion. I have seen
> > cases where slave perhiphral got stuck while sending last FIFO but since DMA
> > finished transferiing to FIFO it says complete.
> >
> > Dan do you agree?
> 
> Yes, it's an indication of completion, not necessarily success.
Sure, will update this..

-- 
~Vinod

  reply	other threads:[~2013-10-10 16:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-05 17:36 [PATCH] DMA: extend documentation to provide more API details Guennadi Liakhovetski
2013-10-05 17:36 ` Guennadi Liakhovetski
2013-10-05 19:02 ` Russell King - ARM Linux
2013-10-05 19:02   ` Russell King - ARM Linux
2013-10-05 21:00   ` Guennadi Liakhovetski
2013-10-05 21:00     ` Guennadi Liakhovetski
2013-10-05 23:31     ` Russell King - ARM Linux
2013-10-05 23:31       ` Russell King - ARM Linux
2013-10-06  5:20       ` Vinod Koul
2013-10-07 10:45         ` Guennadi Liakhovetski
2013-10-07 10:41           ` Vinod Koul
2013-10-07 12:17             ` Guennadi Liakhovetski
2013-10-07 11:17           ` Russell King - ARM Linux
2013-10-07 10:39             ` Vinod Koul
2013-10-07 12:15               ` Guennadi Liakhovetski
2013-10-07 14:25                 ` Vinod Koul
2013-10-07 15:28                   ` Guennadi Liakhovetski
2013-10-07 14:43                     ` Vinod Koul
2013-10-07 15:45                       ` Guennadi Liakhovetski
2013-10-07 15:52                         ` Vinod Koul
2013-10-07 20:55                           ` Guennadi Liakhovetski
2013-10-08  3:52                             ` Vinod Koul
2013-10-08  7:28                               ` Guennadi Liakhovetski
2013-10-07 15:48                     ` Vinod Koul
2013-10-07 20:43                       ` Guennadi Liakhovetski
2013-10-08  3:58                         ` Vinod Koul
2013-10-08  7:17                           ` Guennadi Liakhovetski
2013-10-09  1:34               ` Dan Williams
2013-10-10 16:15                 ` Vinod Koul [this message]
2013-10-16 19:33                 ` Stephen Warren
2013-10-17  5:16                   ` Vinod Koul
2013-10-17 14:55                     ` Stephen Warren
2013-10-17 17:00                       ` Dan Williams
2013-10-07  7:40       ` Guennadi Liakhovetski
2013-10-07  7:40         ` Guennadi Liakhovetski
2013-10-09  1:28         ` Dan Williams
2013-10-09  1:28           ` Dan Williams

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=20131010161509.GC2954@intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.