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

[Kuninori Morimoto]

Hi Mark

> If something is only using the component interfaces except for things
> like probe and remove then converting them to component interfaces makes
> sense.  If it's still using CODEC interfaces for some bits then it's
> less clear that this is a good idea.
> 
> > But it seems your opinion is like this ?
> >  - ASoC will care only "component" (same as my opinion)
> >  - This "component" includes all features
> >    (= Codec feature, CPU feature, Platform feature, etc)
> 
> I think so, yes.  To me the goal is to avoid too much rigid
> categorization of components so that we can handle devices that have
> combinations of these features effectively without having to worry about
> exactly what terminology we use to describe them.

Hmm... If my understand was correct, my concern is this.
If we merged all (CPU/Codec/Platform/etc...) features into component,
it will be big size, and almost all feature are not needed for almost all devices.
And in the future, we will have new type of device which we never know yet today.
In such case, more new feature (it is unnecessary for existing devices) will be
added to component. Then it will be bigger and bigger and bigger...

My opinion is that "component" which will be base of new ASoC should keep simple and small.
New "component" has "each connection", and "callback" for each necessary point,
and very basic feature only (like format, channel, etc)
And each device struct which is based on component can have detail information if it wants.
But here, ASoC cares component only. If framework need to do something for detail
things, it should be done by callback.

This doesn't mean "categorization". Of course current CPU/Codec/Platform looks
like one of them, but I would like to say it will be "helper".
Current "Codec" specific operation can go to "codec struct" specific callback,
and ASoC framework doesn't care about it, it just call generic callback.
This means soc-core will have "component" related operation only,
and new soc-codec.c will have codec related operation as callback, for example.

> > Anyway, I don't want to create new issue on ASoC.
> > It seems we (or only me ?) still don't have cristal clear big-picture (?)
> > If so, my previous patch-set might make new style switching difficult.
> > Mark, because of this reasons, is it possible to remove my previous
> > patch-set (= topic/codec-component) from your repository ?
> > Incomplete big-patch-set will cause new trouble.
> > I want to cleanup ASoC, but I want to do it under cristal clear agreement.
> 
> I think that's a reasonable thing to do in general, I don't see a
> particular need to revert it.  Like Lars said I probably wouldn't have
> done it right now but you've done the work so I don't see any need to
> revert it.

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 = {

If so my previous patch is doing pointless effort, and will be trouble ?