[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