Commit 10b98527 authored by Liam Girdwood's avatar Liam Girdwood Committed by Jaroslav Kysela

[ALSA] ASoC documentation updates

This patch updates the documentation for ASoC to reflect the recent
changes in API between 0.12.x and 0.13.x
Changes:-
 o Removed all reference to old API's.
 o Removed references and examples of automatic DAI config and matching.
 o Fixed 80 char line length on some files.
Signed-off-by: default avatarLiam Girdwood <lg@opensource.wolfsonmicro.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarJaroslav Kysela <perex@suse.cz>
parent c6d6eeea
This diff is collapsed.
......@@ -40,275 +40,12 @@ BCLK = LRC * x
BCLK = LRC * Channels * Word Size
This relationship depends on the codec or SoC CPU in particular. ASoC can quite
easily match BCLK generated by division (SND_SOC_DAI_BFS_DIV) with BCLK by
multiplication (SND_SOC_DAI_BFS_RATE) or BCLK generated by
Rate * Channels * Word size (RCW or SND_SOC_DAI_BFS_RCW).
This relationship depends on the codec or SoC CPU in particular. In general
it's best to configure BCLK to the lowest possible speed (depending on your
rate, number of channels and wordsize) to save on power.
It's also desireable to use the codec (if possible) to drive (or master) the
audio clocks as it's usually gives more accurate sample rates than the CPU.
ASoC Clocking
-------------
The ASoC core determines the clocking for each particular configuration at
runtime. This is to allow for dynamic audio clocking wereby the audio clock is
variable and depends on the system state or device usage scenario. i.e. a voice
call requires slower clocks (and hence less power) than MP3 playback.
ASoC will call the config_sysclock() function for the target machine during the
audio parameters configuration. The function is responsible for then clocking
the machine audio subsytem and returning the audio clock speed to the core.
This function should also call the codec and cpu DAI clock_config() functions
to configure their respective internal clocking if required.
ASoC Clocking Control Flow
--------------------------
The ASoC core will call the machine drivers config_sysclock() when most of the
DAI capabilities are known. The machine driver is then responsible for calling
the codec and/or CPU DAI drivers with the selected capabilities and the current
MCLK. Note that the machine driver is also resonsible for setting the MCLK (and
enabling it).
(1) Match Codec and CPU DAI capabilities. At this point we have
matched the majority of the DAI fields and now need to make sure this
mode is currently clockable.
(2) machine->config_sysclk() is now called with the matched DAI FS, sample
rate and BCLK master. This function then gets/sets the current audio
clock (depening on usage) and calls the codec and CPUI DAI drivers with
the FS, rate, BCLK master and MCLK.
(3) Codec/CPU DAI config_sysclock(). This function checks that the FS, rate,
BCLK master and MCLK are acceptable for the codec or CPU DAI. It also
sets the DAI internal state to work with said clocks.
The config_sysclk() functions for CPU, codec and machine should return the MCLK
on success and 0 on failure.
Examples (b = BCLK, l = LRC)
============================
Example 1
---------
Simple codec that only runs at 48k @ 256FS in master mode.
CPU only runs as slave DAI, however it generates a variable MCLK.
-------- ---------
| | <----mclk--- | |
| Codec |b -----------> | CPU |
| |l -----------> | |
| | | |
-------- ---------
The codec driver has the following config_sysclock()
static unsigned int config_sysclk(struct snd_soc_codec_dai *dai,
struct snd_soc_clock_info *info, unsigned int clk)
{
/* make sure clock is 256 * rate */
if(info->rate << 8 == clk) {
dai->mclk = clk;
return clk;
}
return 0;
}
The CPU I2S DAI driver has the following config_sysclk()
static unsigned int config_sysclk(struct snd_soc_codec_dai *dai,
struct snd_soc_clock_info *info, unsigned int clk)
{
/* can we support this clk */
if(set_audio_clk(clk) < 0)
return -EINVAL;
dai->mclk = clk;
return dai->clk;
}
The machine driver config_sysclk() in this example is as follows:-
unsigned int machine_config_sysclk(struct snd_soc_pcm_runtime *rtd,
struct snd_soc_clock_info *info)
{
int clk = info->rate * info->fs;
/* check that CPU can deliver clock */
if(rtd->cpu_dai->config_sysclk(rtd->cpu_dai, info, clk) < 0)
return -EINVAL;
/* can codec work with this clock */
return rtd->codec_dai->config_sysclk(rtd->codec_dai, info, clk);
}
Example 2
---------
Codec that can master at 8k and 48k at various FS (and hence supports a fixed
set of input MCLK's) and can also be slave at various FS .
The CPU can master at 8k and 48k @256 FS and can be slave at any FS.
MCLK is a 12.288MHz crystal on this machine.
-------- ---------
| | <---xtal---> | |
| Codec |b <----------> | CPU |
| |l <----------> | |
| | | |
-------- ---------
The codec driver has the following config_sysclock()
/* supported input clocks */
const static int hifi_clks[] = {11289600, 12000000, 12288000,
16934400, 18432000};
static unsigned int config_hsysclk(struct snd_soc_codec_dai *dai,
struct snd_soc_clock_info *info, unsigned int clk)
{
int i;
/* is clk supported */
for(i = 0; i < ARRAY_SIZE(hifi_clks); i++) {
if(clk == hifi_clks[i]) {
dai->mclk = clk;
return clk;
}
}
/* this clk is not supported */
return 0;
}
The CPU I2S DAI driver has the following config_sysclk()
static unsigned int config_sysclk(struct snd_soc_codec_dai *dai,
struct snd_soc_clock_info *info, unsigned int clk)
{
/* are we master or slave */
if (info->bclk_master &
(SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_CBM_CFS)) {
/* we can only master @ 256FS */
if(info->rate << 8 == clk) {
dai->mclk = clk;
return dai->mclk;
}
} else {
/* slave we can run at any FS */
dai->mclk = clk;
return dai->mclk;
}
/* not supported */
return dai->clk;
}
The machine driver config_sysclk() in this example is as follows:-
unsigned int machine_config_sysclk(struct snd_soc_pcm_runtime *rtd,
struct snd_soc_clock_info *info)
{
int clk = 12288000; /* 12.288MHz */
/* who's driving the link */
if (info->bclk_master &
(SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_CBM_CFS)) {
/* codec master */
/* check that CPU can work with clock */
if(rtd->cpu_dai->config_sysclk(rtd->cpu_dai, info, clk) < 0)
return -EINVAL;
/* can codec work with this clock */
return rtd->codec_dai->config_sysclk(rtd->codec_dai, info, clk);
} else {
/* cpu master */
/* check that codec can work with clock */
if(rtd->codec_dai->config_sysclk(rtd->codec_dai, info, clk) < 0)
return -EINVAL;
/* can CPU work with this clock */
return rtd->cpu_dai->config_sysclk(rtd->cpu_dai, info, clk);
}
}
Example 3
---------
Codec that masters at 8k ... 48k @256 FS. Codec can also be slave and
doesn't care about FS. The codec has an internal PLL and dividers to generate
the necessary internal clocks (for 256FS).
CPU can only be slave and doesn't care about FS.
MCLK is a non controllable 13MHz clock from the CPU.
-------- ---------
| | <----mclk--- | |
| Codec |b <----------> | CPU |
| |l <----------> | |
| | | |
-------- ---------
The codec driver has the following config_sysclock()
/* valid PCM clock dividers * 2 */
static int pcm_divs[] = {2, 6, 11, 4, 8, 12, 16};
static unsigned int config_vsysclk(struct snd_soc_codec_dai *dai,
struct snd_soc_clock_info *info, unsigned int clk)
{
int i, j, best_clk = info->fs * info->rate;
/* can we run at this clk without the PLL ? */
for (i = 0; i < ARRAY_SIZE(pcm_divs); i++) {
if ((best_clk >> 1) * pcm_divs[i] == clk) {
dai->pll_in = 0;
dai->clk_div = pcm_divs[i];
dai->mclk = best_clk;
return dai->mclk;
}
}
/* now check for PLL support */
for (i = 0; i < ARRAY_SIZE(pll_div); i++) {
if (pll_div[i].pll_in == clk) {
for (j = 0; j < ARRAY_SIZE(pcm_divs); j++) {
if (pll_div[i].pll_out == pcm_divs[j] * (best_clk >> 1)) {
dai->pll_in = clk;
dai->pll_out = pll_div[i].pll_out;
dai->clk_div = pcm_divs[j];
dai->mclk = best_clk;
return dai->mclk;
}
}
}
}
/* this clk is not supported */
return 0;
}
The CPU I2S DAI driver has the does not need a config_sysclk() as it can slave
at any FS.
unsigned int config_sysclk(struct snd_soc_pcm_runtime *rtd,
struct snd_soc_clock_info *info)
{
/* codec has pll that generates mclk from 13MHz xtal */
return rtd->codec_dai->config_sysclk(rtd->codec_dai, info, 13000000);
}
......@@ -6,21 +6,18 @@ codec to provide audio capture and playback. It should contain no code that is
specific to the target platform or machine. All platform and machine specific
code should be added to the platform and machine drivers respectively.
Each codec driver must provide the following features:-
Each codec driver *must* provide the following features:-
1) Digital audio interface (DAI) description
2) Digital audio interface configuration
3) PCM's description
4) Codec control IO - using I2C, 3 Wire(SPI) or both API's
5) Mixers and audio controls
6) Sysclk configuration
7) Codec audio operations
1) Codec DAI and PCM configuration
2) Codec control IO - using I2C, 3 Wire(SPI) or both API's
3) Mixers and audio controls
4) Codec audio operations
Optionally, codec drivers can also provide:-
8) DAPM description.
9) DAPM event handler.
10) DAC Digital mute control.
5) DAPM description.
6) DAPM event handler.
7) DAC Digital mute control.
It's probably best to use this guide in conjuction with the existing codec
driver code in sound/soc/codecs/
......@@ -28,58 +25,47 @@ driver code in sound/soc/codecs/
ASoC Codec driver breakdown
===========================
1 - Digital Audio Interface (DAI) description
---------------------------------------------
The DAI is a digital audio data transfer link between the codec and host SoC
CPU. It typically has data transfer capabilities in both directions
(playback and capture) and can run at a variety of different speeds.
Supported interfaces currently include AC97, I2S and generic PCM style links.
Please read DAI.txt for implementation information.
2 - Digital Audio Interface (DAI) configuration
-----------------------------------------------
DAI configuration is handled by the codec_pcm_prepare function and is
responsible for configuring and starting the DAI on the codec. This can be
called multiple times and is atomic. It can access the runtime parameters.
This usually consists of a large function with numerous switch statements to
set up each configuration option. These options are set by the core at runtime.
3 - Codec PCM's
---------------
Each codec must have it's PCM's defined. This defines the number of channels,
stream names, callbacks and codec name. It is also used to register the DAI
with the ASoC core. The PCM structure also associates the DAI capabilities with
the ALSA PCM.
1 - Codec DAI and PCM configuration
-----------------------------------
Each codec driver must have a struct snd_soc_codec_dai to define it's DAI and
PCM's capablities and operations. This struct is exported so that it can be
registered with the core by your machine driver.
e.g.
static struct snd_soc_pcm_codec wm8731_pcm_client = {
struct snd_soc_codec_dai wm8731_dai = {
.name = "WM8731",
/* playback capabilities */
.playback = {
.stream_name = "Playback",
.channels_min = 1,
.channels_max = 2,
},
.rates = WM8731_RATES,
.formats = WM8731_FORMATS,},
/* capture capabilities */
.capture = {
.stream_name = "Capture",
.channels_min = 1,
.channels_max = 2,
},
.config_sysclk = wm8731_config_sysclk,
.rates = WM8731_RATES,
.formats = WM8731_FORMATS,},
/* pcm operations - see section 4 below */
.ops = {
.prepare = wm8731_pcm_prepare,
.hw_params = wm8731_hw_params,
.shutdown = wm8731_shutdown,
},
.caps = {
.num_modes = ARRAY_SIZE(wm8731_hwfmt),
.modes = &wm8731_hwfmt[0],
},
/* DAI operations - see DAI.txt */
.dai_ops = {
.digital_mute = wm8731_mute,
.set_sysclk = wm8731_set_dai_sysclk,
.set_fmt = wm8731_set_dai_fmt,
}
};
EXPORT_SYMBOL_GPL(wm8731_dai);
4 - Codec control IO
2 - Codec control IO
--------------------
The codec can ususally be controlled via an I2C or SPI style interface (AC97
combines control with data in the DAI). The codec drivers will have to provide
......@@ -104,7 +90,7 @@ read/write:-
hw_read_t hw_read;
5 - Mixers and audio controls
3 - Mixers and audio controls
-----------------------------
All the codec mixers and audio controls can be defined using the convenience
macros defined in soc.h.
......@@ -143,28 +129,7 @@ Defines an single enumerated control as follows:-
Defines a stereo enumerated control
6 - System clock configuration.
-------------------------------
The system clock that drives the audio subsystem can change depending on sample
rate and the system power state. i.e.
o Higher sample rates sometimes need a higher system clock.
o Low system power states can sometimes limit the available clocks.
This function is a callback that the machine driver can call to set and
determine if the clock and sample rate combination is supported by the codec at
the present time (and system state).
NOTE: If the codec has a PLL then it has a lot more flexability wrt clock and
sample rate combinations.
Your config_sysclock function should return the MCLK if it's a valid
combination for your codec else 0;
Please read clocking.txt now.
7 - Codec Audio Operations
4 - Codec Audio Operations
--------------------------
The codec driver also supports the following alsa operations:-
......@@ -181,7 +146,7 @@ Please refer to the alsa driver PCM documentation for details.
http://www.alsa-project.org/~iwai/writing-an-alsa-driver/c436.htm
8 - DAPM description.
5 - DAPM description.
---------------------
The Dynamic Audio Power Management description describes the codec's power
components, their relationships and registers to the ASoC core. Please read
......@@ -190,7 +155,7 @@ dapm.txt for details of building the description.
Please also see the examples in other codec drivers.
9 - DAPM event handler
6 - DAPM event handler
----------------------
This function is a callback that handles codec domain PM calls and system
domain PM calls (e.g. suspend and resume). It's used to put the codec to sleep
......@@ -210,7 +175,7 @@ Power states:-
SNDRV_CTL_POWER_D3cold: /* Everything Off, without power */
10 - Codec DAC digital mute control.
7 - Codec DAC digital mute control.
------------------------------------
Most codecs have a digital mute before the DAC's that can be used to minimise
any system noise. The mute stops any digital data from entering the DAC.
......
......@@ -64,7 +64,7 @@ static struct snd_soc_dai_link corgi_dai = {
.cpu_dai = &pxa_i2s_dai,
.codec_dai = &wm8731_dai,
.init = corgi_wm8731_init,
.config_sysclk = corgi_config_sysclk,
.ops = &corgi_ops,
};
struct snd_soc_machine then sets up the machine with it's DAI's. e.g.
......@@ -74,7 +74,6 @@ static struct snd_soc_machine snd_soc_machine_corgi = {
.name = "Corgi",
.dai_link = &corgi_dai,
.num_links = 1,
.ops = &corgi_ops,
};
......
......@@ -2,14 +2,14 @@ Audio Pops and Clicks
=====================
Pops and clicks are unwanted audio artifacts caused by the powering up and down
of components within the audio subsystem. This is noticable on PC's when an audio
module is either loaded or unloaded (at module load time the sound card is
of components within the audio subsystem. This is noticable on PC's when an
audio module is either loaded or unloaded (at module load time the sound card is
powered up and causes a popping noise on the speakers).
Pops and clicks can be more frequent on portable systems with DAPM. This is because
the components within the subsystem are being dynamically powered depending on
the audio usage and this can subsequently cause a small pop or click every time a
component power state is changed.
Pops and clicks can be more frequent on portable systems with DAPM. This is
because the components within the subsystem are being dynamically powered
depending on the audio usage and this can subsequently cause a small pop or
click every time a component power state is changed.
Minimising Playback Pops and Clicks
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment