[alsa-devel] [PATCH 1/2] ASoC: dapm - Add DAPM for always active DAC or ADC

[Mark Brown]

On Wed, Mar 25, 2009 at 05:34:57PM +0900, Joonyoung Shim wrote:

> Activating always DAC or ADC widget doesn't mean powering it on all the
> time. To power on DAC or ADC activated, we need one or more complete path
> connecting with DAC or ADC because the power of widgets is controlled by
> DAPM automatically. If complete path is no, DAC or ADC will be powered off
> , so we can control the power of DAC or ADC using controls at user space.

That will only work in a limited number of systems - it means there's no
facility provided to configure the DAI (I've no idea if the CODEC you're
interested in has any configuration there).  It also has problems in
situations where the voice DAC is hooked up to the CPU since no DAI is
provided.  Some systems will hook multiple DAIs in the CODEC up to the
CPU and then use this to either allow multiple streams to be played back
with mixing being done in the CODEC rather than by software or to allow
the different streams to be routed to different outputs.

> Thanks, but i think hooking in using events on the widgets is impossible
> because voice call is different operation with record or playback.

As, so you don't have any digital bypass paths (the fact that you're
also talking about ADCs suggested that you did)?  Like I said in reply
to the TWL4030 patch this sounds like you should be representing this as
a normal DAI.

> > When the core gains support for digital routing this can be replaced.
> > Alternatively, if there is no integration with record or playback
> > required then there's no reason to represent them as DACs and ADCs, they
> > could be done as some other path element that DAPM does know about.

> Hmm, I think additional support needs for voice call operation at ASoC, so
> i suggested a way of this patch.

This sort of configuration has been supported in ASoC for some time.
See the OpenMoko Neo1973 for a public example of how this can be
implemented.  It's not the nicest solution possible but it means that
when we do get something better the CODEC drivers won't require updates
and scenarios where the voice interface is connected to the CPU can be
supported.