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 ?