Hi Mark, Lars
Over time the hardware landscape changed and the distinction feature wise did become smaller between the different types of components. The CPU side components started to take care of tasks that were previously only found in CODECS and wise versa.
This lead to a lot of code duplication in ASoC since the same functionality was now implemented multiple times. Is this where the original componentization effort started. The goal of this effort was to introduce the snd_soc_component struct as a common base for all types of components in ASoC. This allowed us to remove a lot of duplicated code and also reduce struct sizes by implementing a more strict hierarchy.
Ahh... I see... OK, I could understand.
According to your (and Lars ?) idea, if component includes all features, then, current "codec" will be "component", and "platform" will be "component" too (?). If so, I think necessary patch in final stage is like this ?
- static struct snd_soc_codec_driver xxxx = {
- static struct snd_soc_component_driver xxxx = {
In the long run probably yes, with the distinction of particular features happening at a different level. E.g. like I pointed out in one of the earlier e-mails, one such layer could be the domain and bridge layer were a component is subdivided into domains and bridges.
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 ? But I wonder current which portion is the "domain" position ? ("domain" + "bridge" = current snd_soc_dai ?) Or we don't have such position at this point ?
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()
If above were OK, some codec driver can use component side .probe/.remove I think Lars's opinion is that this should be final stage, but I think we can do this as parallel, and I like step-by-step approach. Of course I can skip it if you have strong objection. So please let me know. I will have summer vacation from tomorrow, so I can start it after that.