From: Vinod Koul <vinod.koul@intel.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Dan Williams <dan.j.williams@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk
Subject: Re: [PATCH 01/28] dmaengine: use DMA_COMPLETE for dma completion status
Date: Thu, 17 Oct 2013 15:23:08 +0530 [thread overview]
Message-ID: <20131017095308.GF14013@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1310170851230.27369@axis700.grange>
On Thu, Oct 17, 2013 at 10:27:13AM +0200, Guennadi Liakhovetski wrote:
> On Thu, 17 Oct 2013, Vinod Koul wrote:
>
> > On Wed, Oct 16, 2013 at 11:45:48AM -0700, Dan Williams wrote:
> > > On Wed, Oct 16, 2013 at 11:29 AM, Guennadi Liakhovetski
> > > >
> > > > Doesn't this break kernel compilation for a total of 27 commits? Or am I
> > > > missing anything?
> > >
> > > Yes, I think at the start DMA_COMPLETE should just be a alias for
> > > DMA_SUCCESS, then after all the driver renames are in delete
> > > DMA_SUCCESS.
> > Oops, taht was bad of me. ffixes in v2 and sending patch 29 for removal case
>
> Ok, yes, this should work now. I'm wondering though - is DMA_COMPLTE
> really a better name? AFAICS, we can only differentiate between 2
> possibilities with the current API: a transfer is "in progress" - between
> last used and last completed, and "unknown" - either completed, or
> aborted, or not yet submitted - if the cookie is larger, than last
> completed and we assume, that it has wrapped.
well, once you submit N, and chekcing status, if you get last > N, then you
assume it completed. If last is M then M is completed and M + 1 running and rest
in queue. You know which one is last submitted in client
> Actually for a driver, that I'm currently working on, I implemented a
> cache of N last cookies (e.g. 128), which is a bitfield, where I just
> record a 1, if that descriptor has failed, and a 0, if completed
> successfully. That way I can report one of 4 states: cookie on queue,
> completed successfully, failed, unknown. I'm not sure, whether I'll keep
> this in the final version, this doesn't really fit the present dmaengine
> API concept. We could make this generic, if desired. Otherwise your
> proposed error callback should help too. But in either case I think with
> the current implementation we cannot find out whether a specific cookie
> completed successfully or failed.
The propsed error callback will tell you if dmaengine detected a failure or not.
That should with above cover well
> One more observation: I looked at a couple of drivers, using the DMA_ERROR
> state. E.g. mmp_tdma.c, mxs-dma.c. They store errors in a .status field in
> their private data. Then they return that status in their
> .device_tx_status() methods - independent on the cookie! This doesn't look
> right to me... at_hdmac.c does something similarly strange.
Yup bunch of ones arent being good citizens..
~Vinod
--
next prev parent reply other threads:[~2013-10-17 10:46 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-16 16:28 [PATCH 00/28]: dmaengine: use DMA_COMPLETE for dma completion status Vinod Koul
2013-10-16 16:28 ` [PATCH 01/28] " Vinod Koul
2013-10-16 18:29 ` Guennadi Liakhovetski
2013-10-16 18:45 ` Dan Williams
2013-10-17 2:07 ` Vinod Koul
2013-10-17 8:27 ` Guennadi Liakhovetski
2013-10-17 9:53 ` Vinod Koul [this message]
2013-10-17 14:27 ` Sebastian Andrzej Siewior
2013-10-17 13:48 ` Vinod Koul
2013-10-24 21:28 ` Guennadi Liakhovetski
2013-10-25 4:23 ` Vinod Koul
2013-10-25 6:32 ` Guennadi Liakhovetski
2013-10-25 5:43 ` Vinod Koul
2013-10-25 6:43 ` Guennadi Liakhovetski
2013-10-29 16:47 ` Olof Johansson
2013-10-30 13:03 ` Vinod Koul
2013-11-04 12:51 ` Sebastian Andrzej Siewior
2013-11-11 19:13 ` Olof Johansson
2013-11-12 4:00 ` Vinod Koul
2013-11-12 5:11 ` Olof Johansson
2013-11-12 4:47 ` Vinod Koul
2013-10-17 14:39 ` Guennadi Liakhovetski
2013-10-16 16:28 ` [PATCH 02/28] dmaengine: amba-pl08x: " Vinod Koul
2013-10-16 16:28 ` [PATCH 03/28] dmaengine: at_hdma: " Vinod Koul
2013-10-17 8:08 ` Nicolas Ferre
2013-10-16 16:28 ` [PATCH 04/28] dmaengine: coh901318: " Vinod Koul
2013-10-16 16:28 ` [PATCH 05/28] dmaengine: cppi41: " Vinod Koul
2013-10-16 16:28 ` [PATCH 06/28] dmaengine: jz4740: " Vinod Koul
2013-10-16 16:28 ` [PATCH 07/28] dmaengine: dmatest: " Vinod Koul
2013-10-16 16:28 ` [PATCH 08/28] dmaengine: dw: " Vinod Koul
2013-10-17 13:43 ` Andy Shevchenko
2013-10-21 7:33 ` Viresh Kumar
2013-10-16 16:28 ` [PATCH 09/28] dmaengine: edma: " Vinod Koul
2013-10-17 0:31 ` Joel Fernandes
2013-10-16 16:28 ` [PATCH 10/28] dmaengine: imx-dma: " Vinod Koul
2013-10-16 16:28 ` [PATCH 11/28] dmaengine: imx-sdma: " Vinod Koul
2013-10-16 16:28 ` [PATCH 12/28] dmaengine: intel_mid_dma: " Vinod Koul
2013-10-16 16:28 ` [PATCH 13/28] dmaengine: ioat: " Vinod Koul
2013-10-16 16:28 ` [PATCH 14/28] dmaengine: iop: " Vinod Koul
2013-10-16 16:28 ` [PATCH 15/28] dmaengine: k3dma: " Vinod Koul
2013-10-17 14:18 ` zhangfei gao
2013-10-16 16:28 ` [PATCH 16/28] dmaengine: mmp_tdma: " Vinod Koul
2013-10-17 14:19 ` zhangfei gao
2013-10-16 16:28 ` [PATCH 17/28] dmaengine: mv_xor: " Vinod Koul
2013-10-16 16:28 ` [PATCH 18/28] dmaengine: mxs-dma: " Vinod Koul
2013-10-16 16:28 ` [PATCH 19/28] dmaengine: omap: " Vinod Koul
2013-10-16 16:28 ` [PATCH 20/28] dmaengine: ppc4xx: " Vinod Koul
2013-10-16 16:28 ` [PATCH 21/28] dmaengine: sa11x0: " Vinod Koul
2013-10-16 16:28 ` [PATCH 22/28] dmaengine: sh: " Vinod Koul
2013-10-16 16:28 ` [PATCH 23/28] dmaengine: ste: " Vinod Koul
2013-10-16 16:28 ` [PATCH 24/28] dmaengine: tegra: " Vinod Koul
2013-10-16 16:28 ` [PATCH 25/28] dmaengine: txx9: " Vinod Koul
2013-10-16 16:28 ` [PATCH 26/28] async_tx: " Vinod Koul
2013-10-16 16:28 ` [PATCH 27/28] serial: sh: " Vinod Koul
2013-10-16 20:17 ` Greg Kroah-Hartman
2013-10-16 16:28 ` [PATCH 28/28] net: " Vinod Koul
2013-10-17 2:16 ` [PATCH 29/29] dmaengine: remove unused DMA_SUCCESS Vinod Koul
2013-10-17 4:55 ` [PATCH 28/28] net: use DMA_COMPLETE for dma completion status David Miller
2013-10-17 9:00 ` [PATCH 00/28]: dmaengine: " Linus Walleij
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=20131017095308.GF14013@intel.com \
--to=vinod.koul@intel.com \
--cc=dan.j.williams@intel.com \
--cc=g.liakhovetski@gmx.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/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).