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

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

[Joonyoung Shim]

This patch supports DAPM widget for always active DAC or ADC regardless
of stream. This widgets will be used for voice call at TWL4030 codec.

TWL4030 codec use the digital signal for voice call, so it needs DAC and
ADC to change signal to digital or analog, however currently DAC and ADC
widgets cannot support voice call because they are activated only when
playback or capture is executed.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
---
 Documentation/sound/alsa/soc/dapm.txt |    3 +++
 include/sound/soc-dapm.h              |    6 ++++++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt
index 9e67632..50a1e21 100644
--- a/Documentation/sound/alsa/soc/dapm.txt
+++ b/Documentation/sound/alsa/soc/dapm.txt
@@ -93,6 +93,9 @@ e.g. stream widgets for HiFi playback and capture
 SND_SOC_DAPM_DAC("HiFi DAC", "HiFi Playback", REG, 3, 1),
 SND_SOC_DAPM_ADC("HiFi ADC", "HiFi Capture", REG, 2, 1),
 
+If you want always active DAC or ADC widget regardless of stream, you can use
+SND_SOC_DAPM_DAC_ACTIVE or SND_SOC_DAPM_ADC_ACTIVE instead, and stream name
+parameter isn't used.
 
 2.2 Path Domain Widgets
 -----------------------
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index a7def6a..5e26f81 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -143,6 +143,12 @@
 #define SND_SOC_DAPM_ADC(wname, stname, wreg, wshift, winvert) \
 {	.id = snd_soc_dapm_adc, .name = wname, .sname = stname, .reg = wreg, \
 	.shift = wshift, .invert = winvert}
+#define SND_SOC_DAPM_DAC_ACTIVE(wname, wreg, wshift, winvert) \
+{	.id = snd_soc_dapm_dac, .name = wname, .reg = wreg, \
+	.shift = wshift, .invert = winvert, .active = 1}
+#define SND_SOC_DAPM_ADC_ACTIVE(wname, wreg, wshift, winvert) \
+{	.id = snd_soc_dapm_adc, .name = wname, .reg = wreg, \
+	.shift = wshift, .invert = winvert, .active = 1}
 
 /* generic register modifier widget */
 #define SND_SOC_DAPM_REG(wid, wname, wreg, wshift, wmask, won_val, woff_val) \
-- 
1.5.6.3

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

[Mark Brown]

On Tue, Mar 24, 2009 at 09:57:20PM +0900, Joonyoung Shim wrote:
> This patch supports DAPM widget for always active DAC or ADC regardless
> of stream. This widgets will be used for voice call at TWL4030 codec.

> TWL4030 codec use the digital signal for voice call, so it needs DAC and
> ADC to change signal to digital or analog, however currently DAC and ADC
> widgets cannot support voice call because they are activated only when
> playback or capture is executed.

What's actually needed here is proper path management in the digital
domain.  Powering components on all the time is clearly suboptimal since
it consumes power when the bypass paths aren't in use, potentially
including power from other components 

This is something that's planned in for the core (there are devices out
there with more complex digital routing needs than can be solved with
this sort of configuration) but I can't give you a specific schedule for
it.

What I'd suggest doing for now is providing a direct analog link from
the ADC input to the DAC output for DAPM and then hooking in using
events on the widgets to manage the power of the DAC and ADC manually.
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.

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

[Joonyoung Shim]

Mark Brown 쓴 글:
> On Tue, Mar 24, 2009 at 09:57:20PM +0900, Joonyoung Shim wrote:
>> This patch supports DAPM widget for always active DAC or ADC regardless
>> of stream. This widgets will be used for voice call at TWL4030 codec.
> 
>> TWL4030 codec use the digital signal for voice call, so it needs DAC and
>> ADC to change signal to digital or analog, however currently DAC and ADC
>> widgets cannot support voice call because they are activated only when
>> playback or capture is executed.
> 
> What's actually needed here is proper path management in the digital
> domain.  Powering components on all the time is clearly suboptimal since
> it consumes power when the bypass paths aren't in use, potentially
> including power from other components 

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.

> 
> This is something that's planned in for the core (there are devices out
> there with more complex digital routing needs than can be solved with
> this sort of configuration) but I can't give you a specific schedule for
> it.
> 
> What I'd suggest doing for now is providing a direct analog link from
> the ADC input to the DAC output for DAPM and then hooking in using
> events on the widgets to manage the power of the DAC and ADC manually.

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

> 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.

> 

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [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.