aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/sound/alsa
diff options
context:
space:
mode:
authorMark Brown <broonie@opensource.wolfsonmicro.com>2008-01-23 02:41:46 -0500
committerJaroslav Kysela <perex@perex.cz>2008-01-31 11:30:10 -0500
commit7c4dbbd87c0dc62849f0f72449464dc37da0a82a (patch)
tree27ea47730466503e9c4e92bebb7a64a9fb5538ea /Documentation/sound/alsa
parentdca008f367586f73bd1c766836e4f7a38ce9814f (diff)
[ALSA] ASoC documentation updates
Update the ASoC documentation. Along with minor formatting and grammar cleanups it moves the ASoC overview into the present tense to reflect the fact that it has now been merged. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Diffstat (limited to 'Documentation/sound/alsa')
-rw-r--r--Documentation/sound/alsa/soc/DAI.txt6
-rw-r--r--Documentation/sound/alsa/soc/clocking.txt10
-rw-r--r--Documentation/sound/alsa/soc/codec.txt53
-rw-r--r--Documentation/sound/alsa/soc/dapm.txt51
-rw-r--r--Documentation/sound/alsa/soc/machine.txt12
-rw-r--r--Documentation/sound/alsa/soc/overview.txt42
-rw-r--r--Documentation/sound/alsa/soc/platform.txt6
-rw-r--r--Documentation/sound/alsa/soc/pops_clicks.txt10
8 files changed, 97 insertions, 93 deletions
diff --git a/Documentation/sound/alsa/soc/DAI.txt b/Documentation/sound/alsa/soc/DAI.txt
index 3feeb9ecdec4..0ebd7ea9706c 100644
--- a/Documentation/sound/alsa/soc/DAI.txt
+++ b/Documentation/sound/alsa/soc/DAI.txt
@@ -1,5 +1,5 @@
1ASoC currently supports the three main Digital Audio Interfaces (DAI) found on 1ASoC currently supports the three main Digital Audio Interfaces (DAI) found on
2SoC controllers and portable audio CODECS today, namely AC97, I2S and PCM. 2SoC controllers and portable audio CODECs today, namely AC97, I2S and PCM.
3 3
4 4
5AC97 5AC97
@@ -25,7 +25,7 @@ left/right clock (LRC) synchronise the link. I2S is flexible in that either the
25controller or CODEC can drive (master) the BCLK and LRC clock lines. Bit clock 25controller or CODEC can drive (master) the BCLK and LRC clock lines. Bit clock
26usually varies depending on the sample rate and the master system clock 26usually varies depending on the sample rate and the master system clock
27(SYSCLK). LRCLK is the same as the sample rate. A few devices support separate 27(SYSCLK). LRCLK is the same as the sample rate. A few devices support separate
28ADC and DAC LRCLK's, this allows for simultaneous capture and playback at 28ADC and DAC LRCLKs, this allows for simultaneous capture and playback at
29different sample rates. 29different sample rates.
30 30
31I2S has several different operating modes:- 31I2S has several different operating modes:-
@@ -35,7 +35,7 @@ I2S has several different operating modes:-
35 35
36 o Left Justified - MSB is transmitted on transition of LRC. 36 o Left Justified - MSB is transmitted on transition of LRC.
37 37
38 o Right Justified - MSB is transmitted sample size BCLK's before LRC 38 o Right Justified - MSB is transmitted sample size BCLKs before LRC
39 transition. 39 transition.
40 40
41PCM 41PCM
diff --git a/Documentation/sound/alsa/soc/clocking.txt b/Documentation/sound/alsa/soc/clocking.txt
index 14930887c25f..b1300162e01c 100644
--- a/Documentation/sound/alsa/soc/clocking.txt
+++ b/Documentation/sound/alsa/soc/clocking.txt
@@ -13,7 +13,7 @@ or SYSCLK). This audio master clock can be derived from a number of sources
13(e.g. crystal, PLL, CPU clock) and is responsible for producing the correct 13(e.g. crystal, PLL, CPU clock) and is responsible for producing the correct
14audio playback and capture sample rates. 14audio playback and capture sample rates.
15 15
16Some master clocks (e.g. PLL's and CPU based clocks) are configurable in that 16Some master clocks (e.g. PLLs and CPU based clocks) are configurable in that
17their speed can be altered by software (depending on the system use and to save 17their speed can be altered by software (depending on the system use and to save
18power). Other master clocks are fixed at a set frequency (i.e. crystals). 18power). Other master clocks are fixed at a set frequency (i.e. crystals).
19 19
@@ -41,11 +41,11 @@ BCLK = LRC * x
41BCLK = LRC * Channels * Word Size 41BCLK = LRC * Channels * Word Size
42 42
43This relationship depends on the codec or SoC CPU in particular. In general 43This relationship depends on the codec or SoC CPU in particular. In general
44it's best to configure BCLK to the lowest possible speed (depending on your 44it is best to configure BCLK to the lowest possible speed (depending on your
45rate, number of channels and wordsize) to save on power. 45rate, number of channels and word size) to save on power.
46 46
47It's also desirable to use the codec (if possible) to drive (or master) the 47It is also desirable to use the codec (if possible) to drive (or master) the
48audio clocks as it's usually gives more accurate sample rates than the CPU. 48audio clocks as it usually gives more accurate sample rates than the CPU.
49 49
50 50
51 51
diff --git a/Documentation/sound/alsa/soc/codec.txt b/Documentation/sound/alsa/soc/codec.txt
index 1e766ad0ebd1..1e95342ed72e 100644
--- a/Documentation/sound/alsa/soc/codec.txt
+++ b/Documentation/sound/alsa/soc/codec.txt
@@ -9,7 +9,7 @@ code should be added to the platform and machine drivers respectively.
9Each codec driver *must* provide the following features:- 9Each codec driver *must* provide the following features:-
10 10
11 1) Codec DAI and PCM configuration 11 1) Codec DAI and PCM configuration
12 2) Codec control IO - using I2C, 3 Wire(SPI) or both API's 12 2) Codec control IO - using I2C, 3 Wire(SPI) or both APIs
13 3) Mixers and audio controls 13 3) Mixers and audio controls
14 4) Codec audio operations 14 4) Codec audio operations
15 15
@@ -19,7 +19,7 @@ Optionally, codec drivers can also provide:-
19 6) DAPM event handler. 19 6) DAPM event handler.
20 7) DAC Digital mute control. 20 7) DAC Digital mute control.
21 21
22It's probably best to use this guide in conjunction with the existing codec 22Its probably best to use this guide in conjunction with the existing codec
23driver code in sound/soc/codecs/ 23driver code in sound/soc/codecs/
24 24
25ASoC Codec driver breakdown 25ASoC Codec driver breakdown
@@ -27,8 +27,8 @@ ASoC Codec driver breakdown
27 27
281 - Codec DAI and PCM configuration 281 - Codec DAI and PCM configuration
29----------------------------------- 29-----------------------------------
30Each codec driver must have a struct snd_soc_codec_dai to define it's DAI and 30Each codec driver must have a struct snd_soc_codec_dai to define its DAI and
31PCM's capabilities and operations. This struct is exported so that it can be 31PCM capabilities and operations. This struct is exported so that it can be
32registered with the core by your machine driver. 32registered with the core by your machine driver.
33 33
34e.g. 34e.g.
@@ -67,18 +67,18 @@ EXPORT_SYMBOL_GPL(wm8731_dai);
67 67
682 - Codec control IO 682 - Codec control IO
69-------------------- 69--------------------
70The codec can usually be controlled via an I2C or SPI style interface (AC97 70The codec can usually be controlled via an I2C or SPI style interface
71combines control with data in the DAI). The codec drivers will have to provide 71(AC97 combines control with data in the DAI). The codec drivers provide
72functions to read and write the codec registers along with supplying a register 72functions to read and write the codec registers along with supplying a
73cache:- 73register cache:-
74 74
75 /* IO control data and register cache */ 75 /* IO control data and register cache */
76 void *control_data; /* codec control (i2c/3wire) data */ 76 void *control_data; /* codec control (i2c/3wire) data */
77 void *reg_cache; 77 void *reg_cache;
78 78
79Codec read/write should do any data formatting and call the hardware read write 79Codec read/write should do any data formatting and call the hardware
80below to perform the IO. These functions are called by the core and alsa when 80read write below to perform the IO. These functions are called by the
81performing DAPM or changing the mixer:- 81core and ALSA when performing DAPM or changing the mixer:-
82 82
83 unsigned int (*read)(struct snd_soc_codec *, unsigned int); 83 unsigned int (*read)(struct snd_soc_codec *, unsigned int);
84 int (*write)(struct snd_soc_codec *, unsigned int, unsigned int); 84 int (*write)(struct snd_soc_codec *, unsigned int, unsigned int);
@@ -131,7 +131,7 @@ Defines a stereo enumerated control
131 131
1324 - Codec Audio Operations 1324 - Codec Audio Operations
133-------------------------- 133--------------------------
134The codec driver also supports the following alsa operations:- 134The codec driver also supports the following ALSA operations:-
135 135
136/* SoC audio ops */ 136/* SoC audio ops */
137struct snd_soc_ops { 137struct snd_soc_ops {
@@ -142,15 +142,15 @@ struct snd_soc_ops {
142 int (*prepare)(struct snd_pcm_substream *); 142 int (*prepare)(struct snd_pcm_substream *);
143}; 143};
144 144
145Please refer to the alsa driver PCM documentation for details. 145Please refer to the ALSA driver PCM documentation for details.
146http://www.alsa-project.org/~iwai/writing-an-alsa-driver/c436.htm 146http://www.alsa-project.org/~iwai/writing-an-alsa-driver/c436.htm
147 147
148 148
1495 - DAPM description. 1495 - DAPM description.
150--------------------- 150---------------------
151The Dynamic Audio Power Management description describes the codec's power 151The Dynamic Audio Power Management description describes the codec power
152components, their relationships and registers to the ASoC core. Please read 152components and their relationships and registers to the ASoC core.
153dapm.txt for details of building the description. 153Please read dapm.txt for details of building the description.
154 154
155Please also see the examples in other codec drivers. 155Please also see the examples in other codec drivers.
156 156
@@ -158,8 +158,8 @@ Please also see the examples in other codec drivers.
1586 - DAPM event handler 1586 - DAPM event handler
159---------------------- 159----------------------
160This function is a callback that handles codec domain PM calls and system 160This function is a callback that handles codec domain PM calls and system
161domain PM calls (e.g. suspend and resume). It's used to put the codec to sleep 161domain PM calls (e.g. suspend and resume). It is used to put the codec
162when not in use. 162to sleep when not in use.
163 163
164Power states:- 164Power states:-
165 165
@@ -175,13 +175,14 @@ Power states:-
175 SNDRV_CTL_POWER_D3cold: /* Everything Off, without power */ 175 SNDRV_CTL_POWER_D3cold: /* Everything Off, without power */
176 176
177 177
1787 - Codec DAC digital mute control. 1787 - Codec DAC digital mute control
179------------------------------------ 179----------------------------------
180Most codecs have a digital mute before the DAC's that can be used to minimise 180Most codecs have a digital mute before the DACs that can be used to
181any system noise. The mute stops any digital data from entering the DAC. 181minimise any system noise. The mute stops any digital data from
182entering the DAC.
182 183
183A callback can be created that is called by the core for each codec DAI when the 184A callback can be created that is called by the core for each codec DAI
184mute is applied or freed. 185when the mute is applied or freed.
185 186
186i.e. 187i.e.
187 188
diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt
index ab0766fd7869..c784a18b94dc 100644
--- a/Documentation/sound/alsa/soc/dapm.txt
+++ b/Documentation/sound/alsa/soc/dapm.txt
@@ -4,20 +4,20 @@ Dynamic Audio Power Management for Portable Devices
41. Description 41. Description
5============== 5==============
6 6
7Dynamic Audio Power Management (DAPM) is designed to allow portable Linux devices 7Dynamic Audio Power Management (DAPM) is designed to allow portable
8to use the minimum amount of power within the audio subsystem at all times. It 8Linux devices to use the minimum amount of power within the audio
9is independent of other kernel PM and as such, can easily co-exist with the 9subsystem at all times. It is independent of other kernel PM and as
10other PM systems. 10such, can easily co-exist with the other PM systems.
11 11
12DAPM is also completely transparent to all user space applications as all power 12DAPM is also completely transparent to all user space applications as
13switching is done within the ASoC core. No code changes or recompiling are 13all power switching is done within the ASoC core. No code changes or
14required for user space applications. DAPM makes power switching decisions based 14recompiling are required for user space applications. DAPM makes power
15upon any audio stream (capture/playback) activity and audio mixer settings 15switching decisions based upon any audio stream (capture/playback)
16within the device. 16activity and audio mixer settings within the device.
17 17
18DAPM spans the whole machine. It covers power control within the entire audio 18DAPM spans the whole machine. It covers power control within the entire
19subsystem, this includes internal codec power blocks and machine level power 19audio subsystem, this includes internal codec power blocks and machine
20systems. 20level power systems.
21 21
22There are 4 power domains within DAPM 22There are 4 power domains within DAPM
23 23
@@ -34,7 +34,7 @@ There are 4 power domains within DAPM
34 Automatically set when mixer and mux settings are changed by the user. 34 Automatically set when mixer and mux settings are changed by the user.
35 e.g. alsamixer, amixer. 35 e.g. alsamixer, amixer.
36 36
37 4. Stream domain - DAC's and ADC's. 37 4. Stream domain - DACs and ADCs.
38 Enabled and disabled when stream playback/capture is started and 38 Enabled and disabled when stream playback/capture is started and
39 stopped respectively. e.g. aplay, arecord. 39 stopped respectively. e.g. aplay, arecord.
40 40
@@ -51,7 +51,7 @@ widgets hereafter.
51Audio DAPM widgets fall into a number of types:- 51Audio DAPM widgets fall into a number of types:-
52 52
53 o Mixer - Mixes several analog signals into a single analog signal. 53 o Mixer - Mixes several analog signals into a single analog signal.
54 o Mux - An analog switch that outputs only 1 of it's inputs. 54 o Mux - An analog switch that outputs only one of many inputs.
55 o PGA - A programmable gain amplifier or attenuation widget. 55 o PGA - A programmable gain amplifier or attenuation widget.
56 o ADC - Analog to Digital Converter 56 o ADC - Analog to Digital Converter
57 o DAC - Digital to Analog Converter 57 o DAC - Digital to Analog Converter
@@ -78,14 +78,14 @@ parameters for stream name and kcontrols.
782.1 Stream Domain Widgets 782.1 Stream Domain Widgets
79------------------------- 79-------------------------
80 80
81Stream Widgets relate to the stream power domain and only consist of ADC's 81Stream Widgets relate to the stream power domain and only consist of ADCs
82(analog to digital converters) and DAC's (digital to analog converters). 82(analog to digital converters) and DACs (digital to analog converters).
83 83
84Stream widgets have the following format:- 84Stream widgets have the following format:-
85 85
86SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert), 86SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert),
87 87
88NOTE: the stream name must match the corresponding stream name in your codecs 88NOTE: the stream name must match the corresponding stream name in your codec
89snd_soc_codec_dai. 89snd_soc_codec_dai.
90 90
91e.g. stream widgets for HiFi playback and capture 91e.g. stream widgets for HiFi playback and capture
@@ -97,7 +97,7 @@ SND_SOC_DAPM_ADC("HiFi ADC", "HiFi Capture", REG, 2, 1),
972.2 Path Domain Widgets 972.2 Path Domain Widgets
98----------------------- 98-----------------------
99 99
100Path domain widgets have a ability to control or effect the audio signal or 100Path domain widgets have a ability to control or affect the audio signal or
101audio paths within the audio subsystem. They have the following form:- 101audio paths within the audio subsystem. They have the following form:-
102 102
103SND_SOC_DAPM_PGA(name, reg, shift, invert, controls, num_controls) 103SND_SOC_DAPM_PGA(name, reg, shift, invert, controls, num_controls)
@@ -149,7 +149,7 @@ SND_SOC_DAPM_MIC("Mic Jack", spitz_mic_bias),
1492.4 Codec Domain 1492.4 Codec Domain
150---------------- 150----------------
151 151
152The Codec power domain has no widgets and is handled by the codecs DAPM event 152The codec power domain has no widgets and is handled by the codecs DAPM event
153handler. This handler is called when the codec powerstate is changed wrt to any 153handler. This handler is called when the codec powerstate is changed wrt to any
154stream event or by kernel PM events. 154stream event or by kernel PM events.
155 155
@@ -158,8 +158,8 @@ stream event or by kernel PM events.
158------------------- 158-------------------
159 159
160Sometimes widgets exist in the codec or machine audio map that don't have any 160Sometimes widgets exist in the codec or machine audio map that don't have any
161corresponding register bit for power control. In this case it's necessary to 161corresponding soft power control. In this case it is necessary to create
162create a virtual widget - a widget with no control bits e.g. 162a virtual widget - a widget with no control bits e.g.
163 163
164SND_SOC_DAPM_MIXER("AC97 Mixer", SND_SOC_DAPM_NOPM, 0, 0, NULL, 0), 164SND_SOC_DAPM_MIXER("AC97 Mixer", SND_SOC_DAPM_NOPM, 0, 0, NULL, 0),
165 165
@@ -172,13 +172,14 @@ subsystem individually with a call to snd_soc_dapm_new_control().
1723. Codec Widget Interconnections 1723. Codec Widget Interconnections
173================================ 173================================
174 174
175Widgets are connected to each other within the codec and machine by audio 175Widgets are connected to each other within the codec and machine by audio paths
176paths (called interconnections). Each interconnection must be defined in order 176(called interconnections). Each interconnection must be defined in order to
177to create a map of all audio paths between widgets. 177create a map of all audio paths between widgets.
178
178This is easiest with a diagram of the codec (and schematic of the machine audio 179This is easiest with a diagram of the codec (and schematic of the machine audio
179system), as it requires joining widgets together via their audio signal paths. 180system), as it requires joining widgets together via their audio signal paths.
180 181
181i.e. from the WM8731 codec's output mixer (wm8731.c) 182e.g., from the WM8731 output mixer (wm8731.c)
182 183
183The WM8731 output mixer has 3 inputs (sources) 184The WM8731 output mixer has 3 inputs (sources)
184 185
diff --git a/Documentation/sound/alsa/soc/machine.txt b/Documentation/sound/alsa/soc/machine.txt
index 72bd222f2a21..f370e7db86af 100644
--- a/Documentation/sound/alsa/soc/machine.txt
+++ b/Documentation/sound/alsa/soc/machine.txt
@@ -16,7 +16,7 @@ struct snd_soc_machine {
16 int (*remove)(struct platform_device *pdev); 16 int (*remove)(struct platform_device *pdev);
17 17
18 /* the pre and post PM functions are used to do any PM work before and 18 /* the pre and post PM functions are used to do any PM work before and
19 * after the codec and DAI's do any PM work. */ 19 * after the codec and DAIs do any PM work. */
20 int (*suspend_pre)(struct platform_device *pdev, pm_message_t state); 20 int (*suspend_pre)(struct platform_device *pdev, pm_message_t state);
21 int (*suspend_post)(struct platform_device *pdev, pm_message_t state); 21 int (*suspend_post)(struct platform_device *pdev, pm_message_t state);
22 int (*resume_pre)(struct platform_device *pdev); 22 int (*resume_pre)(struct platform_device *pdev);
@@ -38,7 +38,7 @@ probe/remove are optional. Do any machine specific probe here.
38suspend()/resume() 38suspend()/resume()
39------------------ 39------------------
40The machine driver has pre and post versions of suspend and resume to take care 40The machine driver has pre and post versions of suspend and resume to take care
41of any machine audio tasks that have to be done before or after the codec, DAI's 41of any machine audio tasks that have to be done before or after the codec, DAIs
42and DMA is suspended and resumed. Optional. 42and DMA is suspended and resumed. Optional.
43 43
44 44
@@ -49,10 +49,10 @@ The machine specific audio operations can be set here. Again this is optional.
49 49
50Machine DAI Configuration 50Machine DAI Configuration
51------------------------- 51-------------------------
52The machine DAI configuration glues all the codec and CPU DAI's together. It can 52The machine DAI configuration glues all the codec and CPU DAIs together. It can
53also be used to set up the DAI system clock and for any machine related DAI 53also be used to set up the DAI system clock and for any machine related DAI
54initialisation e.g. the machine audio map can be connected to the codec audio 54initialisation e.g. the machine audio map can be connected to the codec audio
55map, unconnnected codec pins can be set as such. Please see corgi.c, spitz.c 55map, unconnected codec pins can be set as such. Please see corgi.c, spitz.c
56for examples. 56for examples.
57 57
58struct snd_soc_dai_link is used to set up each DAI in your machine. e.g. 58struct snd_soc_dai_link is used to set up each DAI in your machine. e.g.
@@ -67,7 +67,7 @@ static struct snd_soc_dai_link corgi_dai = {
67 .ops = &corgi_ops, 67 .ops = &corgi_ops,
68}; 68};
69 69
70struct snd_soc_machine then sets up the machine with it's DAI's. e.g. 70struct snd_soc_machine then sets up the machine with it's DAIs. e.g.
71 71
72/* corgi audio machine driver */ 72/* corgi audio machine driver */
73static struct snd_soc_machine snd_soc_machine_corgi = { 73static struct snd_soc_machine snd_soc_machine_corgi = {
@@ -110,4 +110,4 @@ details.
110Machine Controls 110Machine Controls
111---------------- 111----------------
112 112
113Machine specific audio mixer controls can be added in the dai init function. \ No newline at end of file 113Machine specific audio mixer controls can be added in the DAI init function.
diff --git a/Documentation/sound/alsa/soc/overview.txt b/Documentation/sound/alsa/soc/overview.txt
index c47ce9530677..1e4c6d3655f2 100644
--- a/Documentation/sound/alsa/soc/overview.txt
+++ b/Documentation/sound/alsa/soc/overview.txt
@@ -1,25 +1,26 @@
1ALSA SoC Layer 1ALSA SoC Layer
2============== 2==============
3 3
4The overall project goal of the ALSA System on Chip (ASoC) layer is to provide 4The overall project goal of the ALSA System on Chip (ASoC) layer is to
5better ALSA support for embedded system-on-chip processors (e.g. pxa2xx, au1x00, 5provide better ALSA support for embedded system-on-chip processors (e.g.
6iMX, etc) and portable audio codecs. Currently there is some support in the 6pxa2xx, au1x00, iMX, etc) and portable audio codecs. Prior to the ASoC
7kernel for SoC audio, however it has some limitations:- 7subsystem there was some support in the kernel for SoC audio, however it
8had some limitations:-
8 9
9 * Currently, codec drivers are often tightly coupled to the underlying SoC 10 * Codec drivers were often tightly coupled to the underlying SoC
10 CPU. This is not ideal and leads to code duplication i.e. Linux now has 4 11 CPU. This is not ideal and leads to code duplication - for example,
11 different wm8731 drivers for 4 different SoC platforms. 12 Linux had different wm8731 drivers for 4 different SoC platforms.
12 13
13 * There is no standard method to signal user initiated audio events (e.g. 14 * There was no standard method to signal user initiated audio events (e.g.
14 Headphone/Mic insertion, Headphone/Mic detection after an insertion 15 Headphone/Mic insertion, Headphone/Mic detection after an insertion
15 event). These are quite common events on portable devices and often require 16 event). These are quite common events on portable devices and often require
16 machine specific code to re-route audio, enable amps, etc., after such an 17 machine specific code to re-route audio, enable amps, etc., after such an
17 event. 18 event.
18 19
19 * Current drivers tend to power up the entire codec when playing 20 * Drivers tended to power up the entire codec when playing (or
20 (or recording) audio. This is fine for a PC, but tends to waste a lot of 21 recording) audio. This is fine for a PC, but tends to waste a lot of
21 power on portable devices. There is also no support for saving power via 22 power on portable devices. There was also no support for saving
22 changing codec oversampling rates, bias currents, etc. 23 power via changing codec oversampling rates, bias currents, etc.
23 24
24 25
25ASoC Design 26ASoC Design
@@ -31,12 +32,13 @@ features :-
31 * Codec independence. Allows reuse of codec drivers on other platforms 32 * Codec independence. Allows reuse of codec drivers on other platforms
32 and machines. 33 and machines.
33 34
34 * Easy I2S/PCM audio interface setup between codec and SoC. Each SoC interface 35 * Easy I2S/PCM audio interface setup between codec and SoC. Each SoC
35 and codec registers it's audio interface capabilities with the core and are 36 interface and codec registers it's audio interface capabilities with the
36 subsequently matched and configured when the application hw params are known. 37 core and are subsequently matched and configured when the application
38 hardware parameters are known.
37 39
38 * Dynamic Audio Power Management (DAPM). DAPM automatically sets the codec to 40 * Dynamic Audio Power Management (DAPM). DAPM automatically sets the codec to
39 it's minimum power state at all times. This includes powering up/down 41 its minimum power state at all times. This includes powering up/down
40 internal power blocks depending on the internal codec audio routing and any 42 internal power blocks depending on the internal codec audio routing and any
41 active streams. 43 active streams.
42 44
@@ -45,16 +47,16 @@ features :-
45 signals the codec when to change power states. 47 signals the codec when to change power states.
46 48
47 * Machine specific controls: Allow machines to add controls to the sound card 49 * Machine specific controls: Allow machines to add controls to the sound card
48 (e.g. volume control for speaker amp). 50 (e.g. volume control for speaker amplifier).
49 51
50To achieve all this, ASoC basically splits an embedded audio system into 3 52To achieve all this, ASoC basically splits an embedded audio system into 3
51components :- 53components :-
52 54
53 * Codec driver: The codec driver is platform independent and contains audio 55 * Codec driver: The codec driver is platform independent and contains audio
54 controls, audio interface capabilities, codec dapm definition and codec IO 56 controls, audio interface capabilities, codec DAPM definition and codec IO
55 functions. 57 functions.
56 58
57 * Platform driver: The platform driver contains the audio dma engine and audio 59 * Platform driver: The platform driver contains the audio DMA engine and audio
58 interface drivers (e.g. I2S, AC97, PCM) for that platform. 60 interface drivers (e.g. I2S, AC97, PCM) for that platform.
59 61
60 * Machine driver: The machine driver handles any machine specific controls and 62 * Machine driver: The machine driver handles any machine specific controls and
@@ -81,4 +83,4 @@ machine.txt: Machine driver internals.
81 83
82pop_clicks.txt: How to minimise audio artifacts. 84pop_clicks.txt: How to minimise audio artifacts.
83 85
84clocking.txt: ASoC clocking for best power performance. \ No newline at end of file 86clocking.txt: ASoC clocking for best power performance.
diff --git a/Documentation/sound/alsa/soc/platform.txt b/Documentation/sound/alsa/soc/platform.txt
index d4678b4dc6c6..b681d17fc388 100644
--- a/Documentation/sound/alsa/soc/platform.txt
+++ b/Documentation/sound/alsa/soc/platform.txt
@@ -8,7 +8,7 @@ specific code.
8Audio DMA 8Audio DMA
9========= 9=========
10 10
11The platform DMA driver optionally supports the following alsa operations:- 11The platform DMA driver optionally supports the following ALSA operations:-
12 12
13/* SoC audio ops */ 13/* SoC audio ops */
14struct snd_soc_ops { 14struct snd_soc_ops {
@@ -38,7 +38,7 @@ struct snd_soc_platform {
38 struct snd_pcm_ops *pcm_ops; 38 struct snd_pcm_ops *pcm_ops;
39}; 39};
40 40
41Please refer to the alsa driver documentation for details of audio DMA. 41Please refer to the ALSA driver documentation for details of audio DMA.
42http://www.alsa-project.org/~iwai/writing-an-alsa-driver/c436.htm 42http://www.alsa-project.org/~iwai/writing-an-alsa-driver/c436.htm
43 43
44An example DMA driver is soc/pxa/pxa2xx-pcm.c 44An example DMA driver is soc/pxa/pxa2xx-pcm.c
@@ -52,7 +52,7 @@ Each SoC DAI driver must provide the following features:-
52 1) Digital audio interface (DAI) description 52 1) Digital audio interface (DAI) description
53 2) Digital audio interface configuration 53 2) Digital audio interface configuration
54 3) PCM's description 54 3) PCM's description
55 4) Sysclk configuration 55 4) SYSCLK configuration
56 5) Suspend and resume (optional) 56 5) Suspend and resume (optional)
57 57
58Please see codec.txt for a description of items 1 - 4. 58Please see codec.txt for a description of items 1 - 4.
diff --git a/Documentation/sound/alsa/soc/pops_clicks.txt b/Documentation/sound/alsa/soc/pops_clicks.txt
index 3371bd9d7cfa..e1e74daa4497 100644
--- a/Documentation/sound/alsa/soc/pops_clicks.txt
+++ b/Documentation/sound/alsa/soc/pops_clicks.txt
@@ -15,11 +15,11 @@ click every time a component power state is changed.
15Minimising Playback Pops and Clicks 15Minimising Playback Pops and Clicks
16=================================== 16===================================
17 17
18Playback pops in portable audio subsystems cannot be completely eliminated atm, 18Playback pops in portable audio subsystems cannot be completely eliminated
19however future audio codec hardware will have better pop and click suppression. 19currently, however future audio codec hardware will have better pop and click
20Pops can be reduced within playback by powering the audio components in a 20suppression. Pops can be reduced within playback by powering the audio
21specific order. This order is different for startup and shutdown and follows 21components in a specific order. This order is different for startup and
22some basic rules:- 22shutdown and follows some basic rules:-
23 23
24 Startup Order :- DAC --> Mixers --> Output PGA --> Digital Unmute 24 Startup Order :- DAC --> Mixers --> Output PGA --> Digital Unmute
25 25