Re: [PATCH 00/13] ASoC: Move IO and kcontrols to the component level

[Takashi Iwai <tiwai@suse.de>]

At Tue, 18 Mar 2014 09:02:03 +0100,
Lars-Peter Clausen wrote:
> 
> Hi,
> 
> This series is the first step towards full componentisation of the ASoC core. It
> moves both the IO abstraction layers within ASoC as well as the standard set of
> kcontrols to the component level. This for example means we can get rid of
> constructs like
> 
> 	if (w->codec)
> 		snd_soc_read(....)
> 	else if(w->platform)
> 		snd_soc_platform_read(...)
> 
> Moving the kcontrols to the component level means we can use the same
> implementation also for other non-CODEC components. E.g. there seems to be an
> increasing amount of CPU components that have basic signal processing and things
> like volume controls etc. whose register layout is similar to those used in
> CODECs. Currently each CPU component driver re-implements these controls by
> hand.
> 
> The first two patches introduce two new helper functions which hide the actual
> implementation on how the CODEC or platform struct that register a control can
> be obtained from the control. This means that when the actual implementation is
> changed only the two helper functions need to be updated and not every single
> driver. The patches that follow that are just cleanups removing unused IO stuff
> and move all IO functions to soc-io.c. The next step is to make platforms also
> components. And then finally first the IO abstraction layers in ASoC are unified
> at the component level and then on top of that the kcontrol helpers are moved to
> the component level.
> 
> The series depends on quite a few topic branches related to changes to the core
> and cleanups for individual drivers. It is probably best to place it on top of
> asoc-v3.15-2. The patch that moves the kcontrols to the component level also has
> a runtime dependency on the not yet applied patches that move the ams-delta and
> mfld_machine controls to the card level.

I'd love to have seen this one or two weeks ago, if this is intended
for 3.15 upstream.  But I guess it's still OK if anyone can test the
stuff well.


thanks,

Takashi