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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
