Hi Lars > > If my understanding was correct, > > current CPU/Codec/Platform will merged and goes to your "component" position. > > current snd_soc_dai will be cleanuped and goes to your "bridge" position. > > Are these correct ? > > The domain+bridge concept is currently just an idea, it still needs somebody > to implement it before it becomes reality. OK I see > > BTW, I would like to replace below as next challenge. > > These are easy, and necessary. > > snd_soc_write() -> snd_soc_component_write() > > snd_soc_update_bits() -> snd_soc_component_update_bits() > > > > This is a little bit difficult, but I can do is step-by-step. > > snd_soc_read() -> snd_soc_component_read() > > How do you want to replace them? > > snd_soc_read() is placed at the CODEC layer and snd_soc_component_read() is > placed at the component layer. As long as the driver is a CODEC driver > (using snd_soc_register_codec()) it is OK that it uses snd_soc_read() and > similar. Using snd_soc_component_read() on the other hand would introduce > some slight boilerplate code, since the driver now has to cast from > snd_soc_codec to snd_soc_component. > > snd_soc_read() and similar are part of a clear hierarchy and are not part of > the current problem. Removing them is not a priority and changing them to > snd_soc_component_read() should only be done where it makes sense (driver is > a component driver and uses snd_soc_register_component()). > > The problems are where we break the hierarchy, e.g. the codec point in > snd_soc_component. This is something we should try to work towards removing > and fixing if we can. Ahh.. your indicated sample is changing - function parameter "codec" to "component" - snd_soc_write() to regmap_write() - snd_soc_add_codec_controls() to snd_soc_add_component_controls() - snd_soc_register_codec() to devm_snd_soc_register_component() If my understanding is correct, your opinion is you want change "codec" to "component" by 1 patch ? In this sample case, my opinion was we need 3 or 4 patches. I don't know which is good idea, but I like low-risk conversion. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
