[alsa-devel] [RFC 4/7] ASoC: Add dmaengine PCM helper functions

Russell King - ARM Linux linux at arm.linux.org.uk
Wed Feb 22 14:32:07 CET 2012

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.

More information about the Alsa-devel mailing list