[alsa-devel] [RFC don't apply] ASoC: Add support for optional auxiliary dailess codecs

[Jarkko Nikula]

On Fri, 26 Nov 2010 14:19:42 +0200
Peter Ujfalusi <peter.ujfalusi at nokia.com> wrote:

> We could as well see these things as components on the audio path.
> A standard CODEC would have DAI + DAPM (analog/digital routings, amps) + gain 
> controls.
> In case of an external amplifier we only have the DAPM part + gain control.
> 
> If a component has DAI, than the normal PCM operations would apply to them, if 
> the component does not have DAI, than those are not applicable.
> I'm not sure, but I think we do have some level of separation of DAPM and PCM 
> operations, right? So why not to utilize, and extend that route?
> All component drivers would use the same registration, core would knows which 
> component has DAI, and which does not. Machine driver could specify a list of 
> components, provides the DAPM connection between the components.
> 
> If DAPM core knows which widget belongs to which component, than I see no real 
> problem with this method. The DAPM would work just fine. The PCM operatins would 
> only apply to component with DAI.
> 
Actually these are already well separated in current ASoC. Like my RFC
patch didn't not need touch soc-dapm.c at all and efectively other
changes were around codec probing/removal and by not registering the
PCM.

> > If I counted correctly we have currently only three amplifier drivers:
> > tpa6130a2.c, wm2000.c and wm9090.c so separation doesn't sound worth of
> > trouble at this point as the core serves well those cases also.
> 
> One more: max9877, if I recall correctly that was the first amp driver?
> 
Yeah, true. Looks like wm9090.c doesn't need any conversion after we
are able to register dailess codecs but those three can be then
converted to use standard probing mechanism and let them register itself
own widgets and controls. I.e. machine drivers don't need to call those
tailored _add_controls functions.


-- 
Jarkko