From: Linus Walleij <linus.ml.walleij@gmail.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: "Linus Walleij" <linus.walleij@stericsson.com>,
"Guennadi Liakhovetski" <g.liakhovetski@gmx.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Sosnowski, Maciej" <maciej.sosnowski@intel.com>,
"Nicolas Ferre" <nicolas.ferre@atmel.com>,
"Pavel Machek" <pavel@ucw.cz>, "Li Yang" <leoli@freescale.com>,
"Paul Mundt" <lethal@linux-sh.org>,
"Ralf Baechle" <ralf@linux-mips.org>,
"Haavard Skinnemoen" <haavard.skinnemoen@atmel.com>,
"Magnus Damm" <damm@opensource.se>,
"Liam Girdwood" <lrg@slimlogic.co.uk>,
"Joe Perches" <joe@perches.com>,
"Roland Dreier" <rdreier@cisco.com>,
"Richard Röjfors" <richard.rojfors@pelagicore.com>,
"Steven J. Magnani" <steve@digidescorp.com>
Subject: Re: [PATCH 2/2] DMAENGINE: generic channel status v2
Date: Sat, 27 Mar 2010 09:32:52 +0100 [thread overview]
Message-ID: <63386a3d1003270132x48e1eaen9fa3fcb17b87aa85@mail.gmail.com> (raw)
In-Reply-To: <1269649039.23499.15.camel@dwillia2-linux>
2010/3/27 Dan Williams <dan.j.williams@intel.com>:
> Sidenote: one thing I notice via this exercise is that not every driver
> is triggering a descriptor cleanup in their device_tx_status()
> implementation. It's really only needed for the drivers that will
> service requests from the async_tx api (now the minority), but something
> to keep in mind. In some cases async_tx polls for completion on
> descriptor allocation failure, so either ->device_tx_status() or
> ->device_prep* needs to run descriptor reclaim.
Not that I designed this thing, but the idea of device_tx_status()
cleaning things up seems a bit kludgy, what about adding a new
control command to device_control() instead, like
DMA_CLEANUP_TX and require that you call this after a
polling async transfer has been found to be complete?
Is this thing supposed to be used for DMA hardware that cannot
trigger interrupts on completion by the way? That seems like the
natural reason...
Linus Walleij
prev parent reply other threads:[~2010-03-27 8:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-26 14:20 [PATCH 2/2] DMAENGINE: generic channel status v2 Linus Walleij
2010-03-27 0:17 ` Dan Williams
2010-03-27 8:32 ` Linus Walleij [this message]
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=63386a3d1003270132x48e1eaen9fa3fcb17b87aa85@mail.gmail.com \
--to=linus.ml.walleij@gmail.com \
--cc=damm@opensource.se \
--cc=dan.j.williams@intel.com \
--cc=g.liakhovetski@gmx.de \
--cc=haavard.skinnemoen@atmel.com \
--cc=joe@perches.com \
--cc=leoli@freescale.com \
--cc=lethal@linux-sh.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=maciej.sosnowski@intel.com \
--cc=nicolas.ferre@atmel.com \
--cc=pavel@ucw.cz \
--cc=ralf@linux-mips.org \
--cc=rdreier@cisco.com \
--cc=richard.rojfors@pelagicore.com \
--cc=steve@digidescorp.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