Hi Lars
Thank you for your feedback
But, we will need many "codec dai name exchange", becouse
- the dai name rule on 1-dai / multi-dai are different, it was depend on snd_soc_register_dai[s].
- component is using both snd_soc_register_dai[s] inside (this was for "cpu" side limit)
- codec have been used snd_soc_register_dais even though it was not multi-dai
We only added the distinction between components with one DAIs and multiple DAIs since most of the CPU DAI drivers with only one DAI used snd_soc_register_dai() and we wanted to avoid having to update all the DAI links. How about adding a boolean flag to __snd_soc_register_component() which if set causes the function to always use snd_soc_register_dais(). This will allow us to keep the existing naming for CODEC dai.
It is easy hack. OK, we can try it.
2nd patch is rough version of "code dai name exchange" for it. Of course we need more and more codec driver patches, but it is wm8978 only as trial now.
I guess "codec driver" should have "component driver" pointer too ? (it has .name only at this point, and 2nd patch includes it)
In my opinion it is better to embed the component_driver struct into the codec_driver struct just like the component struct is embedded in the codec struct. Otherwise your patch looks fine to me. Maybe move
I see.
__snd_soc_register_component() up, so the forward declaration is not needed anymore.
This was the reason why I used "rough" naming here :P
We can move some feature from codec to component after this step ?
Yes. I think most of the fields managed by the core which are not touched by any drivers can be moved easily.
Nice !
As my previous email said, this patch cares only codec <-> component, but we re-consider about "component" if component will be used from "platform" (and "card" too ?) ? (since it is controlling "dai" inside) Or is it 2nd step like above ?
I can say current style is quick-hack, but it is easy to go to next step. I'm not sure this is good plan
Best regards --- Kuninori Morimoto