[alsa-devel] [PATCH 1/2] ASoC: dapm - Add DAPM for always active DAC or ADC
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) \
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.
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.
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.
participants (2)
-
Joonyoung Shim -
Mark Brown