From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Ryan Mallon <rmallon@gmail.com>,
alsa-devel@alsa-project.org,
Sascha Hauer <s.hauer@pengutronix.de>,
Wolfram Sang <w.sang@pengutronix.de>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Mika Westerberg <mika.westerberg@iki.fi>,
Shawn Guo <shawn.guo@linaro.org>, Liam Girdwood <lrg@ti.com>
Subject: Re: [RFC 4/7] ASoC: Add dmaengine PCM helper functions
Date: Wed, 22 Feb 2012 13:32:07 +0000 [thread overview]
Message-ID: <20120222133207.GD22562@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20120222132107.GD7340@opensource.wolfsonmicro.com>
On Wed, Feb 22, 2012 at 01:21:08PM +0000, Mark Brown wrote:
> On Wed, Feb 22, 2012 at 10:49:08AM +0100, Lars-Peter Clausen wrote:
> > This patch adds a set of functions which are intended to be used when
> > implementing a dmaengine based sound PCM driver.
>
> Looks good - if you need to resend then:
>
> > + * Note that this function will use private_data field of the substream's
> > + * runtime. So it is not availabe to your pcm driver implementation. If you need
> > + * to keep additional data attached to a substream use
> > + * snd_dmaeinge_pcm_{set,get}_data.
>
> there's a typo here but no need to resend just for that.
>
> I'd like to see some review from both Morimoto-san as we should convert
> fsi over to this too, Vinod I guess you're also pretty much happy given
> your comments on the previous version?
>
> For the non-cyclic DMAs the idea of emulating at the dmaengine layer
> does seem very sensible but if that's hard then having the code at the
> ASoC level and pushing it down later seems fine. We do have several
> platforms with non-cyclic DMA so it's a general need.
I think you're making the assumption that other people need cyclic
transfers. I've seen little evidence that anyone other than sound
needs such things, so I don't think there's justification to push
this code into every DMA engine driver.
Remember, there's no common code to a DMA engine driver at all,
everyone implements their own way with their own bugs. I would agree
with you if there was some decent DMA engine infrastructure to abstract
out such things, but there isn't.
So what you're asking is for N different ways of doing this, instead of
having one centralized way.
next prev parent reply other threads:[~2012-02-22 13:32 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 9:49 [RFC 0/7] ASoC: Introduce dmaengine pcm helper functions Lars-Peter Clausen
2012-02-22 9:49 ` [RFC 1/7] ASoC: imx-ssi: Set dma data early Lars-Peter Clausen
2012-02-22 13:22 ` Mark Brown
2012-02-22 9:49 ` [RFC 2/7] ASoC: imx-pcm: Request DMA channel early Lars-Peter Clausen
2012-02-22 13:22 ` Mark Brown
2012-02-22 9:49 ` [RFC 3/7] ASoC: mxs-pcm: " Lars-Peter Clausen
2012-02-22 13:22 ` Mark Brown
2012-02-22 9:49 ` [RFC 4/7] ASoC: Add dmaengine PCM helper functions Lars-Peter Clausen
2012-02-22 10:01 ` Russell King - ARM Linux
2012-02-22 12:52 ` Lars-Peter Clausen
2012-02-22 13:00 ` Mark Brown
2012-02-22 13:21 ` Mark Brown
2012-02-22 13:30 ` Vinod Koul
2012-02-22 13:30 ` Mark Brown
2012-02-22 13:32 ` Russell King - ARM Linux [this message]
2012-02-22 13:39 ` Mark Brown
2012-02-22 14:22 ` Russell King - ARM Linux
2012-02-22 15:04 ` Mark Brown
2012-02-22 15:23 ` Russell King - ARM Linux
2012-02-22 15:39 ` Mark Brown
2012-02-23 6:57 ` Vinod Koul
2012-03-02 13:59 ` Mark Brown
2012-03-05 12:30 ` Lars-Peter Clausen
2012-03-05 12:41 ` Mark Brown
2012-03-07 0:38 ` Kuninori Morimoto
2012-03-07 11:42 ` Mark Brown
2012-02-22 9:49 ` [RFC 5/7] ASoC: imx-pcm-dma: Use " Lars-Peter Clausen
2012-02-22 9:49 ` [RFC 6/7] ASoC: mxs-pcm: " Lars-Peter Clausen
2012-02-22 9:49 ` [RFC 7/7] ASoC: ep93xx-pcm: " Lars-Peter Clausen
2012-02-27 8:19 ` Mika Westerberg
2012-02-27 8:51 ` Lars-Peter Clausen
2012-02-27 19:01 ` Mika Westerberg
2012-02-28 8:47 ` Lars-Peter Clausen
2012-02-28 12:52 ` Mark Brown
2012-02-28 14:17 ` Lars-Peter Clausen
2012-02-28 14:30 ` Mark Brown
2012-02-28 19:23 ` Mika Westerberg
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=20120222133207.GD22562@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lars@metafoo.de \
--cc=lrg@ti.com \
--cc=mika.westerberg@iki.fi \
--cc=rmallon@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=shawn.guo@linaro.org \
--cc=vinod.koul@linux.intel.com \
--cc=w.sang@pengutronix.de \
/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).