[alsa-devel] [PATCH 000/127] ASoC: codec cleanup - codec probe/remove

[Kuninori Morimoto]

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.