[alsa-devel] [RFC don't apply] ASoC: Add support for optional auxiliary dailess codecs
broonie at opensource.wolfsonmicro.com
Fri Nov 26 14:41:52 CET 2010
On Fri, Nov 26, 2010 at 03:35:48PM +0200, Jarkko Nikula wrote:
> Peter Ujfalusi <peter.ujfalusi at nokia.com> wrote:
> > 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
That's pretty much where I'm coming from - we already have most of the
infrastructure, we just need to get the devices into the system but once
we do that we should be able to cope with everything already.
> > > 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.
Yup, WM9090 is a DAIless CODEC already as it's using the register cache.
The systems where it's typically deployed have a stub CODEC normally so
this happens to work as-is, it wouldn't work as-is otherwise.
More information about the Alsa-devel