[alsa-devel] About snd_dmaengine_pcm_trigger()

Kuninori Morimoto kuninori.morimoto.gx at gmail.com
Wed Mar 5 09:32:32 CET 2014


Hi Lars

Thank you for your feedback

> > 3rd, our device needs special method on snd_pcm_ops
> > int the future.
> >
> 
> What kind of special ops?

It would like to use snd_soc_dapm_widget,
but we can update snd_soc_component instead of platform ?

> I don't think using the snd_dmaengine_pcm helpers should be difficult, 
> since, as I said, each of them perform one very specific task. If you'd 
> directly call the dmaengine API you'd end up with pretty much the same code 
> as the dmaengine PCM helpers. What's more of a challenge would be to use the 
> generic dmaengine PCM driver.
> 
> I think the issue with the sound/soc/sh/ code is that there never was a 
> clean separation between the DMA/PIO and the DAI configuration code. And 
> especially with rcar you seem to be reimplementing a ASoC-like framework 
> on-top of ASoC. Which makes it rather hard to reused generic code, since the 
> generic code doesn't know about all the custom hooks and callbacks. The ASoC 
> framework is not set in stone, if there is something missing to properly 
> support your hardware you should try to extend the framework to support this 
> rather than working around it in your drivers.

I see...
I need investigate more about this,
but, before that, can I confirm ? 

basically...

platform  : for PIO or DMA transfer method
component : for DAI configuration = CPU side HW settings etc

Is this correct ?

And about ASoC-like framework, rcar driver needs to control many kind of devices,
and it depends on platform which device is used.
(each devices have different feature)
So, I used ASoC-like framework, but in this case, what should I do ?



More information about the Alsa-devel mailing list