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.