1. Description
==============
-Dynamic Audio Power Management (DAPM) is designed to allow portable Linux devices
-to use the minimum amount of power within the audio subsystem at all times. It
-is independent of other kernel PM and as such, can easily co-exist with the
-other PM systems.
+Dynamic Audio Power Management (DAPM) is designed to allow portable
+Linux devices to use the minimum amount of power within the audio
+subsystem at all times. It is independent of other kernel PM and as
+such, can easily co-exist with the other PM systems.
-DAPM is also completely transparent to all user space applications as all power
-switching is done within the ASoC core. No code changes or recompiling are
-required for user space applications. DAPM makes power switching decisions based
-upon any audio stream (capture/playback) activity and audio mixer settings
-within the device.
+DAPM is also completely transparent to all user space applications as
+all power switching is done within the ASoC core. No code changes or
+recompiling are required for user space applications. DAPM makes power
+switching decisions based upon any audio stream (capture/playback)
+activity and audio mixer settings within the device.
-DAPM spans the whole machine. It covers power control within the entire audio
-subsystem, this includes internal codec power blocks and machine level power
-systems.
+DAPM spans the whole machine. It covers power control within the entire
+audio subsystem, this includes internal codec power blocks and machine
+level power systems.
There are 4 power domains within DAPM
Automatically set when mixer and mux settings are changed by the user.
e.g. alsamixer, amixer.
- 4. Stream domain - DAC's and ADC's.
+ 4. Stream domain - DACs and ADCs.
Enabled and disabled when stream playback/capture is started and
stopped respectively. e.g. aplay, arecord.
Audio DAPM widgets fall into a number of types:-
o Mixer - Mixes several analog signals into a single analog signal.
- o Mux - An analog switch that outputs only 1 of it's inputs.
+ o Mux - An analog switch that outputs only one of many inputs.
o PGA - A programmable gain amplifier or attenuation widget.
o ADC - Analog to Digital Converter
o DAC - Digital to Analog Converter
(Widgets are defined in include/sound/soc-dapm.h)
Widgets are usually added in the codec driver and the machine driver. There are
-convience macros defined in soc-dapm.h that can be used to quickly build a
+convenience macros defined in soc-dapm.h that can be used to quickly build a
list of widgets of the codecs and machines DAPM widgets.
Most widgets have a name, register, shift and invert. Some widgets have extra
2.1 Stream Domain Widgets
-------------------------
-Stream Widgets relate to the stream power domain and only consist of ADC's
-(analog to digital converters) and DAC's (digital to analog converters).
+Stream Widgets relate to the stream power domain and only consist of ADCs
+(analog to digital converters) and DACs (digital to analog converters).
Stream widgets have the following format:-
SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert),
-NOTE: the stream name must match the corresponding stream name in your codecs
+NOTE: the stream name must match the corresponding stream name in your codec
snd_soc_codec_dai.
e.g. stream widgets for HiFi playback and capture
2.2 Path Domain Widgets
-----------------------
-Path domain widgets have a ability to control or effect the audio signal or
+Path domain widgets have a ability to control or affect the audio signal or
audio paths within the audio subsystem. They have the following form:-
SND_SOC_DAPM_PGA(name, reg, shift, invert, controls, num_controls)
2.4 Codec Domain
----------------
-The Codec power domain has no widgets and is handled by the codecs DAPM event
+The codec power domain has no widgets and is handled by the codecs DAPM event
handler. This handler is called when the codec powerstate is changed wrt to any
stream event or by kernel PM events.
-------------------
Sometimes widgets exist in the codec or machine audio map that don't have any
-corresponding register bit for power control. In this case it's necessary to
-create a virtual widget - a widget with no control bits e.g.
+corresponding soft power control. In this case it is necessary to create
+a virtual widget - a widget with no control bits e.g.
SND_SOC_DAPM_MIXER("AC97 Mixer", SND_SOC_DAPM_NOPM, 0, 0, NULL, 0),
3. Codec Widget Interconnections
================================
-Widgets are connected to each other within the codec and machine by audio
-paths (called interconnections). Each interconnection must be defined in order
-to create a map of all audio paths between widgets.
+Widgets are connected to each other within the codec and machine by audio paths
+(called interconnections). Each interconnection must be defined in order to
+create a map of all audio paths between widgets.
+
This is easiest with a diagram of the codec (and schematic of the machine audio
system), as it requires joining widgets together via their audio signal paths.
-i.e. from the WM8731 codec's output mixer (wm8731.c)
+e.g., from the WM8731 output mixer (wm8731.c)
The WM8731 output mixer has 3 inputs (sources)
git.openpandora.org / pandora-kernel.git / blobdiff