2011-06-09 13:45:53 +00:00
|
|
|
/*
|
|
|
|
* soc-pcm.c -- ALSA SoC PCM
|
|
|
|
*
|
|
|
|
* Copyright 2005 Wolfson Microelectronics PLC.
|
|
|
|
* Copyright 2005 Openedhand Ltd.
|
|
|
|
* Copyright (C) 2010 Slimlogic Ltd.
|
|
|
|
* Copyright (C) 2010 Texas Instruments Inc.
|
|
|
|
*
|
|
|
|
* Authors: Liam Girdwood <lrg@ti.com>
|
|
|
|
* Mark Brown <broonie@opensource.wolfsonmicro.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
* Free Software Foundation; either version 2 of the License, or (at your
|
|
|
|
* option) any later version.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/delay.h>
|
ASoC: Add pinctrl PM to components of active DAIs
It's quite popular that more drivers are using pinctrl PM, for example:
(Documentation/devicetree/bindings/arm/primecell.txt). Just like what
runtime PM does, it would deactivate and activate pin group depending
on whether it's being used or not.
And this pinctrl PM might be also beneficial to cpu dai drivers because
they might have actual pinctrl so as to sleep their pins and wake them
up as needed.
To achieve this goal, this patch sets pins to the default state during
resume or startup; While during suspend and shutdown, it would set pins
to the sleep state.
As pinctrl PM would return zero if there is no such pinctrl sleep state
settings, this patch would not break current ASoC subsystem directly.
[ However, there is still an exception that the patch can not handle,
that is, when cpu dai driver does not have pinctrl property but another
device has it. (The AUDMUX <-> SSI on Freescale i.MX6 series for example.
SSI as a cpu dai doesn't contain pinctrl property while AUDMUX, an Audio
Multiplexer, has it). In this case, this kind of cpu dai driver needs to
find a way to obtain the pinctrl property as its own, by moving property
from AUDMUX to SSI, or creating a pins link/dependency between these two
devices, or using a more decent way after we figure it out. ]
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-11-04 06:57:31 +00:00
|
|
|
#include <linux/pinctrl/consumer.h>
|
2011-12-03 20:14:31 +00:00
|
|
|
#include <linux/pm_runtime.h>
|
2011-06-09 13:45:53 +00:00
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/workqueue.h>
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
#include <linux/export.h>
|
2012-04-25 11:12:50 +00:00
|
|
|
#include <linux/debugfs.h>
|
2011-06-09 13:45:53 +00:00
|
|
|
#include <sound/core.h>
|
|
|
|
#include <sound/pcm.h>
|
|
|
|
#include <sound/pcm_params.h>
|
|
|
|
#include <sound/soc.h>
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
#include <sound/soc-dpcm.h>
|
2011-06-09 13:45:53 +00:00
|
|
|
#include <sound/initval.h>
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
#define DPCM_MAX_BE_USERS 8
|
|
|
|
|
2013-05-14 09:05:30 +00:00
|
|
|
/**
|
|
|
|
* snd_soc_set_runtime_hwparams - set the runtime hardware parameters
|
|
|
|
* @substream: the pcm substream
|
|
|
|
* @hw: the hardware parameters
|
|
|
|
*
|
|
|
|
* Sets the substream runtime hardware parameters.
|
|
|
|
*/
|
|
|
|
int snd_soc_set_runtime_hwparams(struct snd_pcm_substream *substream,
|
|
|
|
const struct snd_pcm_hardware *hw)
|
|
|
|
{
|
|
|
|
struct snd_pcm_runtime *runtime = substream->runtime;
|
|
|
|
runtime->hw.info = hw->info;
|
|
|
|
runtime->hw.formats = hw->formats;
|
|
|
|
runtime->hw.period_bytes_min = hw->period_bytes_min;
|
|
|
|
runtime->hw.period_bytes_max = hw->period_bytes_max;
|
|
|
|
runtime->hw.periods_min = hw->periods_min;
|
|
|
|
runtime->hw.periods_max = hw->periods_max;
|
|
|
|
runtime->hw.buffer_bytes_max = hw->buffer_bytes_max;
|
|
|
|
runtime->hw.fifo_size = hw->fifo_size;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_set_runtime_hwparams);
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
/* DPCM stream event, send event to FE and all active BEs. */
|
|
|
|
static int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir,
|
|
|
|
int event)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[dir].be_clients, list_be) {
|
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: BE %s event %d dir %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
be->dai_link->name, event, dir);
|
|
|
|
|
|
|
|
snd_soc_dapm_stream_event(be, dir, event);
|
|
|
|
}
|
|
|
|
|
|
|
|
snd_soc_dapm_stream_event(fe, dir, event);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-08-29 09:15:14 +00:00
|
|
|
static int soc_pcm_apply_symmetry(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_soc_dai *soc_dai)
|
2011-06-09 13:45:53 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
int ret;
|
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
if (soc_dai->rate && (soc_dai->driver->symmetric_rates ||
|
|
|
|
rtd->dai_link->symmetric_rates)) {
|
|
|
|
dev_dbg(soc_dai->dev, "ASoC: Symmetry forces %dHz rate\n",
|
|
|
|
soc_dai->rate);
|
|
|
|
|
|
|
|
ret = snd_pcm_hw_constraint_minmax(substream->runtime,
|
|
|
|
SNDRV_PCM_HW_PARAM_RATE,
|
|
|
|
soc_dai->rate, soc_dai->rate);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(soc_dai->dev,
|
|
|
|
"ASoC: Unable to apply rate constraint: %d\n",
|
|
|
|
ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
if (soc_dai->channels && (soc_dai->driver->symmetric_channels ||
|
|
|
|
rtd->dai_link->symmetric_channels)) {
|
|
|
|
dev_dbg(soc_dai->dev, "ASoC: Symmetry forces %d channel(s)\n",
|
|
|
|
soc_dai->channels);
|
|
|
|
|
|
|
|
ret = snd_pcm_hw_constraint_minmax(substream->runtime,
|
|
|
|
SNDRV_PCM_HW_PARAM_CHANNELS,
|
|
|
|
soc_dai->channels,
|
|
|
|
soc_dai->channels);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(soc_dai->dev,
|
|
|
|
"ASoC: Unable to apply channel symmetry constraint: %d\n",
|
|
|
|
ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (soc_dai->sample_bits && (soc_dai->driver->symmetric_samplebits ||
|
|
|
|
rtd->dai_link->symmetric_samplebits)) {
|
|
|
|
dev_dbg(soc_dai->dev, "ASoC: Symmetry forces %d sample bits\n",
|
|
|
|
soc_dai->sample_bits);
|
|
|
|
|
|
|
|
ret = snd_pcm_hw_constraint_minmax(substream->runtime,
|
|
|
|
SNDRV_PCM_HW_PARAM_SAMPLE_BITS,
|
|
|
|
soc_dai->sample_bits,
|
|
|
|
soc_dai->sample_bits);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(soc_dai->dev,
|
|
|
|
"ASoC: Unable to apply sample bits symmetry constraint: %d\n",
|
|
|
|
ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
static int soc_pcm_params_symmetry(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_pcm_hw_params *params)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
unsigned int rate, channels, sample_bits, symmetry;
|
|
|
|
|
|
|
|
rate = params_rate(params);
|
|
|
|
channels = params_channels(params);
|
|
|
|
sample_bits = snd_pcm_format_physical_width(params_format(params));
|
|
|
|
|
|
|
|
/* reject unmatched parameters when applying symmetry */
|
|
|
|
symmetry = cpu_dai->driver->symmetric_rates ||
|
|
|
|
codec_dai->driver->symmetric_rates ||
|
|
|
|
rtd->dai_link->symmetric_rates;
|
|
|
|
if (symmetry && cpu_dai->rate && cpu_dai->rate != rate) {
|
|
|
|
dev_err(rtd->dev, "ASoC: unmatched rate symmetry: %d - %d\n",
|
|
|
|
cpu_dai->rate, rate);
|
|
|
|
return -EINVAL;
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
symmetry = cpu_dai->driver->symmetric_channels ||
|
|
|
|
codec_dai->driver->symmetric_channels ||
|
|
|
|
rtd->dai_link->symmetric_channels;
|
|
|
|
if (symmetry && cpu_dai->channels && cpu_dai->channels != channels) {
|
|
|
|
dev_err(rtd->dev, "ASoC: unmatched channel symmetry: %d - %d\n",
|
|
|
|
cpu_dai->channels, channels);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
symmetry = cpu_dai->driver->symmetric_samplebits ||
|
|
|
|
codec_dai->driver->symmetric_samplebits ||
|
|
|
|
rtd->dai_link->symmetric_samplebits;
|
|
|
|
if (symmetry && cpu_dai->sample_bits && cpu_dai->sample_bits != sample_bits) {
|
|
|
|
dev_err(rtd->dev, "ASoC: unmatched sample bits symmetry: %d - %d\n",
|
|
|
|
cpu_dai->sample_bits, sample_bits);
|
|
|
|
return -EINVAL;
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-11-30 16:38:58 +00:00
|
|
|
static bool soc_pcm_has_symmetry(struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_dai_driver *cpu_driver = rtd->cpu_dai->driver;
|
|
|
|
struct snd_soc_dai_driver *codec_driver = rtd->codec_dai->driver;
|
|
|
|
struct snd_soc_dai_link *link = rtd->dai_link;
|
|
|
|
|
|
|
|
return cpu_driver->symmetric_rates || codec_driver->symmetric_rates ||
|
|
|
|
link->symmetric_rates || cpu_driver->symmetric_channels ||
|
|
|
|
codec_driver->symmetric_channels || link->symmetric_channels ||
|
|
|
|
cpu_driver->symmetric_samplebits ||
|
|
|
|
codec_driver->symmetric_samplebits ||
|
|
|
|
link->symmetric_samplebits;
|
|
|
|
}
|
|
|
|
|
2012-01-16 18:38:51 +00:00
|
|
|
/*
|
|
|
|
* List of sample sizes that might go over the bus for parameter
|
|
|
|
* application. There ought to be a wildcard sample size for things
|
|
|
|
* like the DAC/ADC resolution to use but there isn't right now.
|
|
|
|
*/
|
|
|
|
static int sample_sizes[] = {
|
2012-01-25 08:09:41 +00:00
|
|
|
24, 32,
|
2012-01-16 18:38:51 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void soc_pcm_apply_msb(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_soc_dai *dai)
|
|
|
|
{
|
|
|
|
int ret, i, bits;
|
|
|
|
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
bits = dai->driver->playback.sig_bits;
|
|
|
|
else
|
|
|
|
bits = dai->driver->capture.sig_bits;
|
|
|
|
|
|
|
|
if (!bits)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(sample_sizes); i++) {
|
2012-01-19 18:04:18 +00:00
|
|
|
if (bits >= sample_sizes[i])
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = snd_pcm_hw_constraint_msbits(substream->runtime, 0,
|
|
|
|
sample_sizes[i], bits);
|
2012-01-16 18:38:51 +00:00
|
|
|
if (ret != 0)
|
|
|
|
dev_warn(dai->dev,
|
2012-11-19 14:39:15 +00:00
|
|
|
"ASoC: Failed to set MSB %d/%d: %d\n",
|
2012-01-16 18:38:51 +00:00
|
|
|
bits, sample_sizes[i], ret);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-14 09:05:31 +00:00
|
|
|
static void soc_pcm_init_runtime_hw(struct snd_pcm_hardware *hw,
|
|
|
|
struct snd_soc_pcm_stream *codec_stream,
|
|
|
|
struct snd_soc_pcm_stream *cpu_stream)
|
|
|
|
{
|
|
|
|
hw->rate_min = max(codec_stream->rate_min, cpu_stream->rate_min);
|
|
|
|
hw->rate_max = max(codec_stream->rate_max, cpu_stream->rate_max);
|
|
|
|
hw->channels_min = max(codec_stream->channels_min,
|
|
|
|
cpu_stream->channels_min);
|
|
|
|
hw->channels_max = min(codec_stream->channels_max,
|
|
|
|
cpu_stream->channels_max);
|
|
|
|
hw->formats = codec_stream->formats & cpu_stream->formats;
|
|
|
|
hw->rates = codec_stream->rates & cpu_stream->rates;
|
|
|
|
if (codec_stream->rates
|
|
|
|
& (SNDRV_PCM_RATE_KNOT | SNDRV_PCM_RATE_CONTINUOUS))
|
|
|
|
hw->rates |= cpu_stream->rates;
|
|
|
|
if (cpu_stream->rates
|
|
|
|
& (SNDRV_PCM_RATE_KNOT | SNDRV_PCM_RATE_CONTINUOUS))
|
|
|
|
hw->rates |= codec_stream->rates;
|
|
|
|
}
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
/*
|
|
|
|
* Called by ALSA when a PCM substream is opened, the runtime->hw record is
|
|
|
|
* then initialized and any private data can be allocated. This also calls
|
|
|
|
* startup for the cpu DAI, platform, machine and codec DAI.
|
|
|
|
*/
|
|
|
|
static int soc_pcm_open(struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_pcm_runtime *runtime = substream->runtime;
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
struct snd_soc_dai_driver *cpu_dai_drv = cpu_dai->driver;
|
|
|
|
struct snd_soc_dai_driver *codec_dai_drv = codec_dai->driver;
|
|
|
|
int ret = 0;
|
|
|
|
|
ASoC: Add pinctrl PM to components of active DAIs
It's quite popular that more drivers are using pinctrl PM, for example:
(Documentation/devicetree/bindings/arm/primecell.txt). Just like what
runtime PM does, it would deactivate and activate pin group depending
on whether it's being used or not.
And this pinctrl PM might be also beneficial to cpu dai drivers because
they might have actual pinctrl so as to sleep their pins and wake them
up as needed.
To achieve this goal, this patch sets pins to the default state during
resume or startup; While during suspend and shutdown, it would set pins
to the sleep state.
As pinctrl PM would return zero if there is no such pinctrl sleep state
settings, this patch would not break current ASoC subsystem directly.
[ However, there is still an exception that the patch can not handle,
that is, when cpu dai driver does not have pinctrl property but another
device has it. (The AUDMUX <-> SSI on Freescale i.MX6 series for example.
SSI as a cpu dai doesn't contain pinctrl property while AUDMUX, an Audio
Multiplexer, has it). In this case, this kind of cpu dai driver needs to
find a way to obtain the pinctrl property as its own, by moving property
from AUDMUX to SSI, or creating a pins link/dependency between these two
devices, or using a more decent way after we figure it out. ]
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-11-04 06:57:31 +00:00
|
|
|
pinctrl_pm_select_default_state(cpu_dai->dev);
|
|
|
|
pinctrl_pm_select_default_state(codec_dai->dev);
|
2011-12-03 20:14:31 +00:00
|
|
|
pm_runtime_get_sync(cpu_dai->dev);
|
|
|
|
pm_runtime_get_sync(codec_dai->dev);
|
|
|
|
pm_runtime_get_sync(platform->dev);
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
/* startup the audio subsystem */
|
2013-10-31 00:47:39 +00:00
|
|
|
if (cpu_dai->driver->ops && cpu_dai->driver->ops->startup) {
|
2011-06-09 13:45:53 +00:00
|
|
|
ret = cpu_dai->driver->ops->startup(substream, cpu_dai);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(cpu_dai->dev, "ASoC: can't open interface"
|
|
|
|
" %s: %d\n", cpu_dai->name, ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (platform->driver->ops && platform->driver->ops->open) {
|
|
|
|
ret = platform->driver->ops->open(substream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(platform->dev, "ASoC: can't open platform"
|
|
|
|
" %s: %d\n", platform->name, ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto platform_err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (codec_dai->driver->ops && codec_dai->driver->ops->startup) {
|
2011-06-09 13:45:53 +00:00
|
|
|
ret = codec_dai->driver->ops->startup(substream, codec_dai);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(codec_dai->dev, "ASoC: can't open codec"
|
|
|
|
" %s: %d\n", codec_dai->name, ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto codec_dai_err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rtd->dai_link->ops && rtd->dai_link->ops->startup) {
|
|
|
|
ret = rtd->dai_link->ops->startup(substream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
pr_err("ASoC: %s startup failed: %d\n",
|
2012-02-01 21:30:32 +00:00
|
|
|
rtd->dai_link->name, ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto machine_err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
/* Dynamic PCM DAI links compat checks use dynamic capabilities */
|
|
|
|
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm)
|
|
|
|
goto dynamic;
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
/* Check that the codec and cpu DAIs are compatible */
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
2013-05-14 09:05:31 +00:00
|
|
|
soc_pcm_init_runtime_hw(&runtime->hw, &codec_dai_drv->playback,
|
|
|
|
&cpu_dai_drv->playback);
|
2011-06-09 13:45:53 +00:00
|
|
|
} else {
|
2013-05-14 09:05:31 +00:00
|
|
|
soc_pcm_init_runtime_hw(&runtime->hw, &codec_dai_drv->capture,
|
|
|
|
&cpu_dai_drv->capture);
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
2013-11-30 16:38:58 +00:00
|
|
|
if (soc_pcm_has_symmetry(substream))
|
|
|
|
runtime->hw.info |= SNDRV_PCM_INFO_JOINT_DUPLEX;
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
snd_pcm_limit_hw_rates(runtime);
|
|
|
|
if (!runtime->hw.rates) {
|
2012-11-19 14:39:15 +00:00
|
|
|
printk(KERN_ERR "ASoC: %s <-> %s No matching rates\n",
|
2011-06-09 13:45:53 +00:00
|
|
|
codec_dai->name, cpu_dai->name);
|
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
if (!runtime->hw.formats) {
|
2012-11-19 14:39:15 +00:00
|
|
|
printk(KERN_ERR "ASoC: %s <-> %s No matching formats\n",
|
2011-06-09 13:45:53 +00:00
|
|
|
codec_dai->name, cpu_dai->name);
|
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
if (!runtime->hw.channels_min || !runtime->hw.channels_max ||
|
|
|
|
runtime->hw.channels_min > runtime->hw.channels_max) {
|
2012-11-19 14:39:15 +00:00
|
|
|
printk(KERN_ERR "ASoC: %s <-> %s No matching channels\n",
|
2011-06-09 13:45:53 +00:00
|
|
|
codec_dai->name, cpu_dai->name);
|
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
|
2012-01-16 18:38:51 +00:00
|
|
|
soc_pcm_apply_msb(substream, codec_dai);
|
|
|
|
soc_pcm_apply_msb(substream, cpu_dai);
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
/* Symmetry only applies if we've already got an active stream. */
|
2011-08-29 09:15:14 +00:00
|
|
|
if (cpu_dai->active) {
|
|
|
|
ret = soc_pcm_apply_symmetry(substream, cpu_dai);
|
|
|
|
if (ret != 0)
|
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (codec_dai->active) {
|
|
|
|
ret = soc_pcm_apply_symmetry(substream, codec_dai);
|
2011-06-09 13:45:53 +00:00
|
|
|
if (ret != 0)
|
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
pr_debug("ASoC: %s <-> %s info:\n",
|
2011-06-09 13:45:53 +00:00
|
|
|
codec_dai->name, cpu_dai->name);
|
2012-11-19 14:39:15 +00:00
|
|
|
pr_debug("ASoC: rate mask 0x%x\n", runtime->hw.rates);
|
|
|
|
pr_debug("ASoC: min ch %d max ch %d\n", runtime->hw.channels_min,
|
2011-06-09 13:45:53 +00:00
|
|
|
runtime->hw.channels_max);
|
2012-11-19 14:39:15 +00:00
|
|
|
pr_debug("ASoC: min rate %d max rate %d\n", runtime->hw.rate_min,
|
2011-06-09 13:45:53 +00:00
|
|
|
runtime->hw.rate_max);
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
dynamic:
|
2011-06-09 13:45:53 +00:00
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
|
|
|
cpu_dai->playback_active++;
|
|
|
|
codec_dai->playback_active++;
|
|
|
|
} else {
|
|
|
|
cpu_dai->capture_active++;
|
|
|
|
codec_dai->capture_active++;
|
|
|
|
}
|
|
|
|
cpu_dai->active++;
|
|
|
|
codec_dai->active++;
|
|
|
|
rtd->codec->active++;
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_unlock(&rtd->pcm_mutex);
|
2011-06-09 13:45:53 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
config_err:
|
|
|
|
if (rtd->dai_link->ops && rtd->dai_link->ops->shutdown)
|
|
|
|
rtd->dai_link->ops->shutdown(substream);
|
|
|
|
|
|
|
|
machine_err:
|
|
|
|
if (codec_dai->driver->ops->shutdown)
|
|
|
|
codec_dai->driver->ops->shutdown(substream, codec_dai);
|
|
|
|
|
|
|
|
codec_dai_err:
|
|
|
|
if (platform->driver->ops && platform->driver->ops->close)
|
|
|
|
platform->driver->ops->close(substream);
|
|
|
|
|
|
|
|
platform_err:
|
|
|
|
if (cpu_dai->driver->ops->shutdown)
|
|
|
|
cpu_dai->driver->ops->shutdown(substream, cpu_dai);
|
|
|
|
out:
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_unlock(&rtd->pcm_mutex);
|
2011-12-03 20:14:31 +00:00
|
|
|
|
|
|
|
pm_runtime_put(platform->dev);
|
|
|
|
pm_runtime_put(codec_dai->dev);
|
|
|
|
pm_runtime_put(cpu_dai->dev);
|
ASoC: Add pinctrl PM to components of active DAIs
It's quite popular that more drivers are using pinctrl PM, for example:
(Documentation/devicetree/bindings/arm/primecell.txt). Just like what
runtime PM does, it would deactivate and activate pin group depending
on whether it's being used or not.
And this pinctrl PM might be also beneficial to cpu dai drivers because
they might have actual pinctrl so as to sleep their pins and wake them
up as needed.
To achieve this goal, this patch sets pins to the default state during
resume or startup; While during suspend and shutdown, it would set pins
to the sleep state.
As pinctrl PM would return zero if there is no such pinctrl sleep state
settings, this patch would not break current ASoC subsystem directly.
[ However, there is still an exception that the patch can not handle,
that is, when cpu dai driver does not have pinctrl property but another
device has it. (The AUDMUX <-> SSI on Freescale i.MX6 series for example.
SSI as a cpu dai doesn't contain pinctrl property while AUDMUX, an Audio
Multiplexer, has it). In this case, this kind of cpu dai driver needs to
find a way to obtain the pinctrl property as its own, by moving property
from AUDMUX to SSI, or creating a pins link/dependency between these two
devices, or using a more decent way after we figure it out. ]
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-11-04 06:57:31 +00:00
|
|
|
if (!codec_dai->active)
|
|
|
|
pinctrl_pm_select_sleep_state(codec_dai->dev);
|
|
|
|
if (!cpu_dai->active)
|
|
|
|
pinctrl_pm_select_sleep_state(cpu_dai->dev);
|
2011-12-03 20:14:31 +00:00
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Power down the audio subsystem pmdown_time msecs after close is called.
|
|
|
|
* This is to ensure there are no pops or clicks in between any music tracks
|
|
|
|
* due to DAPM power cycling.
|
|
|
|
*/
|
|
|
|
static void close_delayed_work(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd =
|
|
|
|
container_of(work, struct snd_soc_pcm_runtime, delayed_work.work);
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(rtd->dev, "ASoC: pop wq checking: %s status: %s waiting: %s\n",
|
2011-06-09 13:45:53 +00:00
|
|
|
codec_dai->driver->playback.stream_name,
|
|
|
|
codec_dai->playback_active ? "active" : "inactive",
|
ASoC: Prevent pop_wait overwrite
pop_wait is used to determine if a deferred playback close
needs to be cancelled when the a PCM is open or if after
the power-down delay expires it needs to run. pop_wait is
associated with the CODEC DAI, so the CODEC DAI must be
unique. This holds true for most CODECs, except for the
dummy CODEC and its DAI.
In DAI links with non-unique dummy CODECs (e.g. front-ends),
pop_wait can be overwritten by another DAI link using also a
dummy CODEC. Failure to cancel a deferred close can cause
mute due to the DAPM STOP event sent in the deferred work.
One scenario where pop_wait is overwritten and causing mute
is below (where hw:0,0 and hw:0,1 are two front-ends with
default pmdown_time = 5 secs):
aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE -d 1
sleep 1
aplay /dev/urandom -D hw:0,1 -c 2 -r 48000 -f S16_LE -d 3 &
aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE
Since CODECs may not be unique, pop_wait is moved to the PCM
runtime structure. Creating separate dummy CODECs for each
DAI link can also solve the problem, but at this point it's
only pop_wait variable in the CODEC DAI that has negative
effects by not being unique.
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-13 18:23:05 +00:00
|
|
|
rtd->pop_wait ? "yes" : "no");
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
/* are we waiting on this codec DAI stream */
|
ASoC: Prevent pop_wait overwrite
pop_wait is used to determine if a deferred playback close
needs to be cancelled when the a PCM is open or if after
the power-down delay expires it needs to run. pop_wait is
associated with the CODEC DAI, so the CODEC DAI must be
unique. This holds true for most CODECs, except for the
dummy CODEC and its DAI.
In DAI links with non-unique dummy CODECs (e.g. front-ends),
pop_wait can be overwritten by another DAI link using also a
dummy CODEC. Failure to cancel a deferred close can cause
mute due to the DAPM STOP event sent in the deferred work.
One scenario where pop_wait is overwritten and causing mute
is below (where hw:0,0 and hw:0,1 are two front-ends with
default pmdown_time = 5 secs):
aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE -d 1
sleep 1
aplay /dev/urandom -D hw:0,1 -c 2 -r 48000 -f S16_LE -d 3 &
aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE
Since CODECs may not be unique, pop_wait is moved to the PCM
runtime structure. Creating separate dummy CODECs for each
DAI link can also solve the problem, but at this point it's
only pop_wait variable in the CODEC DAI that has negative
effects by not being unique.
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-13 18:23:05 +00:00
|
|
|
if (rtd->pop_wait == 1) {
|
|
|
|
rtd->pop_wait = 0;
|
2012-02-16 23:03:27 +00:00
|
|
|
snd_soc_dapm_stream_event(rtd, SNDRV_PCM_STREAM_PLAYBACK,
|
2012-03-07 16:32:59 +00:00
|
|
|
SND_SOC_DAPM_STREAM_STOP);
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_unlock(&rtd->pcm_mutex);
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called by ALSA when a PCM substream is closed. Private data can be
|
|
|
|
* freed here. The cpu DAI, codec DAI, machine and platform are also
|
|
|
|
* shutdown.
|
|
|
|
*/
|
2011-06-09 16:04:59 +00:00
|
|
|
static int soc_pcm_close(struct snd_pcm_substream *substream)
|
2011-06-09 13:45:53 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
struct snd_soc_codec *codec = rtd->codec;
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
|
|
|
cpu_dai->playback_active--;
|
|
|
|
codec_dai->playback_active--;
|
|
|
|
} else {
|
|
|
|
cpu_dai->capture_active--;
|
|
|
|
codec_dai->capture_active--;
|
|
|
|
}
|
|
|
|
|
|
|
|
cpu_dai->active--;
|
|
|
|
codec_dai->active--;
|
|
|
|
codec->active--;
|
|
|
|
|
2011-08-29 09:15:14 +00:00
|
|
|
/* clear the corresponding DAIs rate when inactive */
|
|
|
|
if (!cpu_dai->active)
|
|
|
|
cpu_dai->rate = 0;
|
|
|
|
|
|
|
|
if (!codec_dai->active)
|
|
|
|
codec_dai->rate = 0;
|
2011-08-17 07:20:01 +00:00
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
if (cpu_dai->driver->ops->shutdown)
|
|
|
|
cpu_dai->driver->ops->shutdown(substream, cpu_dai);
|
|
|
|
|
|
|
|
if (codec_dai->driver->ops->shutdown)
|
|
|
|
codec_dai->driver->ops->shutdown(substream, codec_dai);
|
|
|
|
|
|
|
|
if (rtd->dai_link->ops && rtd->dai_link->ops->shutdown)
|
|
|
|
rtd->dai_link->ops->shutdown(substream);
|
|
|
|
|
|
|
|
if (platform->driver->ops && platform->driver->ops->close)
|
|
|
|
platform->driver->ops->close(substream);
|
|
|
|
cpu_dai->runtime = NULL;
|
|
|
|
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
2012-02-08 20:10:56 +00:00
|
|
|
if (!rtd->pmdown_time || codec->ignore_pmdown_time ||
|
2011-10-27 10:11:26 +00:00
|
|
|
rtd->dai_link->ignore_pmdown_time) {
|
2011-10-14 11:43:33 +00:00
|
|
|
/* powered down playback stream now */
|
|
|
|
snd_soc_dapm_stream_event(rtd,
|
2012-02-16 23:03:27 +00:00
|
|
|
SNDRV_PCM_STREAM_PLAYBACK,
|
|
|
|
SND_SOC_DAPM_STREAM_STOP);
|
2011-10-14 11:43:33 +00:00
|
|
|
} else {
|
|
|
|
/* start delayed pop wq here for playback streams */
|
ASoC: Prevent pop_wait overwrite
pop_wait is used to determine if a deferred playback close
needs to be cancelled when the a PCM is open or if after
the power-down delay expires it needs to run. pop_wait is
associated with the CODEC DAI, so the CODEC DAI must be
unique. This holds true for most CODECs, except for the
dummy CODEC and its DAI.
In DAI links with non-unique dummy CODECs (e.g. front-ends),
pop_wait can be overwritten by another DAI link using also a
dummy CODEC. Failure to cancel a deferred close can cause
mute due to the DAPM STOP event sent in the deferred work.
One scenario where pop_wait is overwritten and causing mute
is below (where hw:0,0 and hw:0,1 are two front-ends with
default pmdown_time = 5 secs):
aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE -d 1
sleep 1
aplay /dev/urandom -D hw:0,1 -c 2 -r 48000 -f S16_LE -d 3 &
aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE
Since CODECs may not be unique, pop_wait is moved to the PCM
runtime structure. Creating separate dummy CODECs for each
DAI link can also solve the problem, but at this point it's
only pop_wait variable in the CODEC DAI that has negative
effects by not being unique.
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-13 18:23:05 +00:00
|
|
|
rtd->pop_wait = 1;
|
2013-07-18 10:52:17 +00:00
|
|
|
queue_delayed_work(system_power_efficient_wq,
|
|
|
|
&rtd->delayed_work,
|
|
|
|
msecs_to_jiffies(rtd->pmdown_time));
|
2011-10-14 11:43:33 +00:00
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
} else {
|
|
|
|
/* capture streams can be powered down now */
|
2012-02-16 23:03:27 +00:00
|
|
|
snd_soc_dapm_stream_event(rtd, SNDRV_PCM_STREAM_CAPTURE,
|
2012-03-07 16:32:59 +00:00
|
|
|
SND_SOC_DAPM_STREAM_STOP);
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_unlock(&rtd->pcm_mutex);
|
2011-12-03 20:14:31 +00:00
|
|
|
|
|
|
|
pm_runtime_put(platform->dev);
|
|
|
|
pm_runtime_put(codec_dai->dev);
|
|
|
|
pm_runtime_put(cpu_dai->dev);
|
ASoC: Add pinctrl PM to components of active DAIs
It's quite popular that more drivers are using pinctrl PM, for example:
(Documentation/devicetree/bindings/arm/primecell.txt). Just like what
runtime PM does, it would deactivate and activate pin group depending
on whether it's being used or not.
And this pinctrl PM might be also beneficial to cpu dai drivers because
they might have actual pinctrl so as to sleep their pins and wake them
up as needed.
To achieve this goal, this patch sets pins to the default state during
resume or startup; While during suspend and shutdown, it would set pins
to the sleep state.
As pinctrl PM would return zero if there is no such pinctrl sleep state
settings, this patch would not break current ASoC subsystem directly.
[ However, there is still an exception that the patch can not handle,
that is, when cpu dai driver does not have pinctrl property but another
device has it. (The AUDMUX <-> SSI on Freescale i.MX6 series for example.
SSI as a cpu dai doesn't contain pinctrl property while AUDMUX, an Audio
Multiplexer, has it). In this case, this kind of cpu dai driver needs to
find a way to obtain the pinctrl property as its own, by moving property
from AUDMUX to SSI, or creating a pins link/dependency between these two
devices, or using a more decent way after we figure it out. ]
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
2013-11-04 06:57:31 +00:00
|
|
|
if (!codec_dai->active)
|
|
|
|
pinctrl_pm_select_sleep_state(codec_dai->dev);
|
|
|
|
if (!cpu_dai->active)
|
|
|
|
pinctrl_pm_select_sleep_state(cpu_dai->dev);
|
2011-12-03 20:14:31 +00:00
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called by ALSA when the PCM substream is prepared, can set format, sample
|
|
|
|
* rate, etc. This function is non atomic and can be called multiple times,
|
|
|
|
* it can refer to the runtime info.
|
|
|
|
*/
|
|
|
|
static int soc_pcm_prepare(struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
int ret = 0;
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
if (rtd->dai_link->ops && rtd->dai_link->ops->prepare) {
|
|
|
|
ret = rtd->dai_link->ops->prepare(substream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(rtd->card->dev, "ASoC: machine prepare error:"
|
|
|
|
" %d\n", ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (platform->driver->ops && platform->driver->ops->prepare) {
|
|
|
|
ret = platform->driver->ops->prepare(substream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(platform->dev, "ASoC: platform prepare error:"
|
|
|
|
" %d\n", ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (codec_dai->driver->ops && codec_dai->driver->ops->prepare) {
|
2011-06-09 13:45:53 +00:00
|
|
|
ret = codec_dai->driver->ops->prepare(substream, codec_dai);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(codec_dai->dev, "ASoC: DAI prepare error: %d\n",
|
2012-02-01 21:30:32 +00:00
|
|
|
ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (cpu_dai->driver->ops && cpu_dai->driver->ops->prepare) {
|
2011-06-09 13:45:53 +00:00
|
|
|
ret = cpu_dai->driver->ops->prepare(substream, cpu_dai);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(cpu_dai->dev, "ASoC: DAI prepare error: %d\n",
|
2012-02-01 21:30:32 +00:00
|
|
|
ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* cancel any delayed stream shutdown that is pending */
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
|
ASoC: Prevent pop_wait overwrite
pop_wait is used to determine if a deferred playback close
needs to be cancelled when the a PCM is open or if after
the power-down delay expires it needs to run. pop_wait is
associated with the CODEC DAI, so the CODEC DAI must be
unique. This holds true for most CODECs, except for the
dummy CODEC and its DAI.
In DAI links with non-unique dummy CODECs (e.g. front-ends),
pop_wait can be overwritten by another DAI link using also a
dummy CODEC. Failure to cancel a deferred close can cause
mute due to the DAPM STOP event sent in the deferred work.
One scenario where pop_wait is overwritten and causing mute
is below (where hw:0,0 and hw:0,1 are two front-ends with
default pmdown_time = 5 secs):
aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE -d 1
sleep 1
aplay /dev/urandom -D hw:0,1 -c 2 -r 48000 -f S16_LE -d 3 &
aplay /dev/urandom -D hw:0,0 -c 2 -r 48000 -f S16_LE
Since CODECs may not be unique, pop_wait is moved to the PCM
runtime structure. Creating separate dummy CODECs for each
DAI link can also solve the problem, but at this point it's
only pop_wait variable in the CODEC DAI that has negative
effects by not being unique.
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-12-13 18:23:05 +00:00
|
|
|
rtd->pop_wait) {
|
|
|
|
rtd->pop_wait = 0;
|
2011-06-09 13:45:53 +00:00
|
|
|
cancel_delayed_work(&rtd->delayed_work);
|
|
|
|
}
|
|
|
|
|
2012-03-07 16:32:59 +00:00
|
|
|
snd_soc_dapm_stream_event(rtd, substream->stream,
|
|
|
|
SND_SOC_DAPM_STREAM_START);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2013-02-06 15:44:07 +00:00
|
|
|
snd_soc_dai_digital_mute(codec_dai, 0, substream->stream);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
out:
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_unlock(&rtd->pcm_mutex);
|
2011-06-09 13:45:53 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called by ALSA when the hardware params are set by application. This
|
|
|
|
* function can also be called multiple times and can allocate buffers
|
|
|
|
* (using snd_pcm_lib_* ). It's non-atomic.
|
|
|
|
*/
|
|
|
|
static int soc_pcm_hw_params(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_pcm_hw_params *params)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
int ret = 0;
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
ret = soc_pcm_params_symmetry(substream, params);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
if (rtd->dai_link->ops && rtd->dai_link->ops->hw_params) {
|
|
|
|
ret = rtd->dai_link->ops->hw_params(substream, params);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(rtd->card->dev, "ASoC: machine hw_params"
|
|
|
|
" failed: %d\n", ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (codec_dai->driver->ops && codec_dai->driver->ops->hw_params) {
|
2011-06-09 13:45:53 +00:00
|
|
|
ret = codec_dai->driver->ops->hw_params(substream, params, codec_dai);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(codec_dai->dev, "ASoC: can't set %s hw params:"
|
|
|
|
" %d\n", codec_dai->name, ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto codec_err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (cpu_dai->driver->ops && cpu_dai->driver->ops->hw_params) {
|
2011-06-09 13:45:53 +00:00
|
|
|
ret = cpu_dai->driver->ops->hw_params(substream, params, cpu_dai);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(cpu_dai->dev, "ASoC: %s hw params failed: %d\n",
|
2012-02-01 21:30:32 +00:00
|
|
|
cpu_dai->name, ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto interface_err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (platform->driver->ops && platform->driver->ops->hw_params) {
|
|
|
|
ret = platform->driver->ops->hw_params(substream, params);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(platform->dev, "ASoC: %s hw params failed: %d\n",
|
2012-02-01 21:30:32 +00:00
|
|
|
platform->name, ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto platform_err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
/* store the parameters for each DAIs */
|
2011-08-29 09:15:14 +00:00
|
|
|
cpu_dai->rate = params_rate(params);
|
2013-11-13 10:56:24 +00:00
|
|
|
cpu_dai->channels = params_channels(params);
|
|
|
|
cpu_dai->sample_bits =
|
|
|
|
snd_pcm_format_physical_width(params_format(params));
|
|
|
|
|
2011-08-29 09:15:14 +00:00
|
|
|
codec_dai->rate = params_rate(params);
|
2013-11-13 10:56:24 +00:00
|
|
|
codec_dai->channels = params_channels(params);
|
|
|
|
codec_dai->sample_bits =
|
|
|
|
snd_pcm_format_physical_width(params_format(params));
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
out:
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_unlock(&rtd->pcm_mutex);
|
2011-06-09 13:45:53 +00:00
|
|
|
return ret;
|
|
|
|
|
|
|
|
platform_err:
|
2013-10-31 00:47:39 +00:00
|
|
|
if (cpu_dai->driver->ops && cpu_dai->driver->ops->hw_free)
|
2011-06-09 13:45:53 +00:00
|
|
|
cpu_dai->driver->ops->hw_free(substream, cpu_dai);
|
|
|
|
|
|
|
|
interface_err:
|
2013-10-31 00:47:39 +00:00
|
|
|
if (codec_dai->driver->ops && codec_dai->driver->ops->hw_free)
|
2011-06-09 13:45:53 +00:00
|
|
|
codec_dai->driver->ops->hw_free(substream, codec_dai);
|
|
|
|
|
|
|
|
codec_err:
|
|
|
|
if (rtd->dai_link->ops && rtd->dai_link->ops->hw_free)
|
|
|
|
rtd->dai_link->ops->hw_free(substream);
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_unlock(&rtd->pcm_mutex);
|
2011-06-09 13:45:53 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Frees resources allocated by hw_params, can be called multiple times
|
|
|
|
*/
|
|
|
|
static int soc_pcm_hw_free(struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
struct snd_soc_codec *codec = rtd->codec;
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2013-11-20 10:37:09 +00:00
|
|
|
/* clear the corresponding DAIs parameters when going to be inactive */
|
|
|
|
if (cpu_dai->active == 1) {
|
|
|
|
cpu_dai->rate = 0;
|
|
|
|
cpu_dai->channels = 0;
|
|
|
|
cpu_dai->sample_bits = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (codec_dai->active == 1) {
|
|
|
|
codec_dai->rate = 0;
|
|
|
|
codec_dai->channels = 0;
|
|
|
|
codec_dai->sample_bits = 0;
|
|
|
|
}
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
/* apply codec digital mute */
|
|
|
|
if (!codec->active)
|
2013-02-06 15:44:07 +00:00
|
|
|
snd_soc_dai_digital_mute(codec_dai, 1, substream->stream);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
/* free any machine hw params */
|
|
|
|
if (rtd->dai_link->ops && rtd->dai_link->ops->hw_free)
|
|
|
|
rtd->dai_link->ops->hw_free(substream);
|
|
|
|
|
|
|
|
/* free any DMA resources */
|
|
|
|
if (platform->driver->ops && platform->driver->ops->hw_free)
|
|
|
|
platform->driver->ops->hw_free(substream);
|
|
|
|
|
|
|
|
/* now free hw params for the DAIs */
|
2013-10-31 00:47:39 +00:00
|
|
|
if (codec_dai->driver->ops && codec_dai->driver->ops->hw_free)
|
2011-06-09 13:45:53 +00:00
|
|
|
codec_dai->driver->ops->hw_free(substream, codec_dai);
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (cpu_dai->driver->ops && cpu_dai->driver->ops->hw_free)
|
2011-06-09 13:45:53 +00:00
|
|
|
cpu_dai->driver->ops->hw_free(substream, cpu_dai);
|
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_unlock(&rtd->pcm_mutex);
|
2011-06-09 13:45:53 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int soc_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
int ret;
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (codec_dai->driver->ops && codec_dai->driver->ops->trigger) {
|
2011-06-09 13:45:53 +00:00
|
|
|
ret = codec_dai->driver->ops->trigger(substream, cmd, codec_dai);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (platform->driver->ops && platform->driver->ops->trigger) {
|
|
|
|
ret = platform->driver->ops->trigger(substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (cpu_dai->driver->ops && cpu_dai->driver->ops->trigger) {
|
2011-06-09 13:45:53 +00:00
|
|
|
ret = cpu_dai->driver->ops->trigger(substream, cmd, cpu_dai);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-05-09 20:46:27 +00:00
|
|
|
static int soc_pcm_bespoke_trigger(struct snd_pcm_substream *substream,
|
|
|
|
int cmd)
|
2012-04-25 11:12:52 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
int ret;
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (codec_dai->driver->ops &&
|
|
|
|
codec_dai->driver->ops->bespoke_trigger) {
|
2012-04-25 11:12:52 +00:00
|
|
|
ret = codec_dai->driver->ops->bespoke_trigger(substream, cmd, codec_dai);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (platform->driver->ops && platform->driver->bespoke_trigger) {
|
2012-04-25 11:12:52 +00:00
|
|
|
ret = platform->driver->bespoke_trigger(substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (cpu_dai->driver->ops && cpu_dai->driver->ops->bespoke_trigger) {
|
2012-04-25 11:12:52 +00:00
|
|
|
ret = cpu_dai->driver->ops->bespoke_trigger(substream, cmd, cpu_dai);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
/*
|
|
|
|
* soc level wrapper for pointer callback
|
|
|
|
* If cpu_dai, codec_dai, platform driver has the delay callback, than
|
|
|
|
* the runtime->delay will be updated accordingly.
|
|
|
|
*/
|
|
|
|
static snd_pcm_uframes_t soc_pcm_pointer(struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
struct snd_pcm_runtime *runtime = substream->runtime;
|
|
|
|
snd_pcm_uframes_t offset = 0;
|
|
|
|
snd_pcm_sframes_t delay = 0;
|
|
|
|
|
|
|
|
if (platform->driver->ops && platform->driver->ops->pointer)
|
|
|
|
offset = platform->driver->ops->pointer(substream);
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (cpu_dai->driver->ops && cpu_dai->driver->ops->delay)
|
2011-06-09 13:45:53 +00:00
|
|
|
delay += cpu_dai->driver->ops->delay(substream, cpu_dai);
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (codec_dai->driver->ops && codec_dai->driver->ops->delay)
|
2011-06-09 13:45:53 +00:00
|
|
|
delay += codec_dai->driver->ops->delay(substream, codec_dai);
|
|
|
|
|
|
|
|
if (platform->driver->delay)
|
|
|
|
delay += platform->driver->delay(substream, codec_dai);
|
|
|
|
|
|
|
|
runtime->delay = delay;
|
|
|
|
|
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
/* connect a FE and BE */
|
|
|
|
static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe,
|
|
|
|
struct snd_soc_pcm_runtime *be, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
|
|
|
|
/* only add new dpcms */
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
if (dpcm->be == be && dpcm->fe == fe)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
dpcm = kzalloc(sizeof(struct snd_soc_dpcm), GFP_KERNEL);
|
|
|
|
if (!dpcm)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
dpcm->be = be;
|
|
|
|
dpcm->fe = fe;
|
|
|
|
be->dpcm[stream].runtime = fe->dpcm[stream].runtime;
|
|
|
|
dpcm->state = SND_SOC_DPCM_LINK_STATE_NEW;
|
|
|
|
list_add(&dpcm->list_be, &fe->dpcm[stream].be_clients);
|
|
|
|
list_add(&dpcm->list_fe, &be->dpcm[stream].fe_clients);
|
|
|
|
|
2013-09-30 14:08:15 +00:00
|
|
|
dev_dbg(fe->dev, "connected new DPCM %s path %s %s %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback", fe->dai_link->name,
|
|
|
|
stream ? "<-" : "->", be->dai_link->name);
|
|
|
|
|
2012-04-25 11:12:50 +00:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
dpcm->debugfs_state = debugfs_create_u32(be->dai_link->name, 0644,
|
|
|
|
fe->debugfs_dpcm_root, &dpcm->state);
|
|
|
|
#endif
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* reparent a BE onto another FE */
|
|
|
|
static void dpcm_be_reparent(struct snd_soc_pcm_runtime *fe,
|
|
|
|
struct snd_soc_pcm_runtime *be, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
struct snd_pcm_substream *fe_substream, *be_substream;
|
|
|
|
|
|
|
|
/* reparent if BE is connected to other FEs */
|
|
|
|
if (!be->dpcm[stream].users)
|
|
|
|
return;
|
|
|
|
|
|
|
|
be_substream = snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &be->dpcm[stream].fe_clients, list_fe) {
|
|
|
|
if (dpcm->fe == fe)
|
|
|
|
continue;
|
|
|
|
|
2013-09-30 14:08:15 +00:00
|
|
|
dev_dbg(fe->dev, "reparent %s path %s %s %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback",
|
|
|
|
dpcm->fe->dai_link->name,
|
|
|
|
stream ? "<-" : "->", dpcm->be->dai_link->name);
|
|
|
|
|
|
|
|
fe_substream = snd_soc_dpcm_get_substream(dpcm->fe, stream);
|
|
|
|
be_substream->runtime = fe_substream->runtime;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* disconnect a BE and FE */
|
|
|
|
static void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm, *d;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(dpcm, d, &fe->dpcm[stream].be_clients, list_be) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: BE %s disconnect check for %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback",
|
|
|
|
dpcm->be->dai_link->name);
|
|
|
|
|
|
|
|
if (dpcm->state != SND_SOC_DPCM_LINK_STATE_FREE)
|
|
|
|
continue;
|
|
|
|
|
2013-09-30 14:08:15 +00:00
|
|
|
dev_dbg(fe->dev, "freed DSP %s path %s %s %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback", fe->dai_link->name,
|
|
|
|
stream ? "<-" : "->", dpcm->be->dai_link->name);
|
|
|
|
|
|
|
|
/* BEs still alive need new FE */
|
|
|
|
dpcm_be_reparent(fe, dpcm->be, stream);
|
|
|
|
|
2012-04-25 11:12:50 +00:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
debugfs_remove(dpcm->debugfs_state);
|
|
|
|
#endif
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
list_del(&dpcm->list_be);
|
|
|
|
list_del(&dpcm->list_fe);
|
|
|
|
kfree(dpcm);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* get BE for DAI widget and stream */
|
|
|
|
static struct snd_soc_pcm_runtime *dpcm_get_be(struct snd_soc_card *card,
|
|
|
|
struct snd_soc_dapm_widget *widget, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *be;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
|
|
|
for (i = 0; i < card->num_links; i++) {
|
|
|
|
be = &card->rtd[i];
|
|
|
|
|
2012-06-05 18:26:59 +00:00
|
|
|
if (!be->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
if (be->cpu_dai->playback_widget == widget ||
|
|
|
|
be->codec_dai->playback_widget == widget)
|
|
|
|
return be;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
|
|
|
|
for (i = 0; i < card->num_links; i++) {
|
|
|
|
be = &card->rtd[i];
|
|
|
|
|
2012-06-05 18:26:59 +00:00
|
|
|
if (!be->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
if (be->cpu_dai->capture_widget == widget ||
|
|
|
|
be->codec_dai->capture_widget == widget)
|
|
|
|
return be;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(card->dev, "ASoC: can't get %s BE for %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback", widget->name);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct snd_soc_dapm_widget *
|
|
|
|
rtd_get_cpu_widget(struct snd_soc_pcm_runtime *rtd, int stream)
|
|
|
|
{
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
return rtd->cpu_dai->playback_widget;
|
|
|
|
else
|
|
|
|
return rtd->cpu_dai->capture_widget;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct snd_soc_dapm_widget *
|
|
|
|
rtd_get_codec_widget(struct snd_soc_pcm_runtime *rtd, int stream)
|
|
|
|
{
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
return rtd->codec_dai->playback_widget;
|
|
|
|
else
|
|
|
|
return rtd->codec_dai->capture_widget;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int widget_in_list(struct snd_soc_dapm_widget_list *list,
|
|
|
|
struct snd_soc_dapm_widget *widget)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < list->num_widgets; i++) {
|
|
|
|
if (widget == list->widgets[i])
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_path_get(struct snd_soc_pcm_runtime *fe,
|
|
|
|
int stream, struct snd_soc_dapm_widget_list **list_)
|
|
|
|
{
|
|
|
|
struct snd_soc_dai *cpu_dai = fe->cpu_dai;
|
|
|
|
struct snd_soc_dapm_widget_list *list;
|
|
|
|
int paths;
|
|
|
|
|
|
|
|
list = kzalloc(sizeof(struct snd_soc_dapm_widget_list) +
|
|
|
|
sizeof(struct snd_soc_dapm_widget *), GFP_KERNEL);
|
|
|
|
if (list == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* get number of valid DAI paths and their widgets */
|
|
|
|
paths = snd_soc_dapm_dai_get_connected_widgets(cpu_dai, stream, &list);
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: found %d audio %s paths\n", paths,
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback");
|
|
|
|
|
|
|
|
*list_ = list;
|
|
|
|
return paths;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void dpcm_path_put(struct snd_soc_dapm_widget_list **list)
|
|
|
|
{
|
|
|
|
kfree(*list);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_prune_paths(struct snd_soc_pcm_runtime *fe, int stream,
|
|
|
|
struct snd_soc_dapm_widget_list **list_)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
struct snd_soc_dapm_widget_list *list = *list_;
|
|
|
|
struct snd_soc_dapm_widget *widget;
|
|
|
|
int prune = 0;
|
|
|
|
|
|
|
|
/* Destroy any old FE <--> BE connections */
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
|
|
|
|
/* is there a valid CPU DAI widget for this BE */
|
|
|
|
widget = rtd_get_cpu_widget(dpcm->be, stream);
|
|
|
|
|
|
|
|
/* prune the BE if it's no longer in our active list */
|
|
|
|
if (widget && widget_in_list(list, widget))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* is there a valid CODEC DAI widget for this BE */
|
|
|
|
widget = rtd_get_codec_widget(dpcm->be, stream);
|
|
|
|
|
|
|
|
/* prune the BE if it's no longer in our active list */
|
|
|
|
if (widget && widget_in_list(list, widget))
|
|
|
|
continue;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: pruning %s BE %s for %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback",
|
|
|
|
dpcm->be->dai_link->name, fe->dai_link->name);
|
|
|
|
dpcm->state = SND_SOC_DPCM_LINK_STATE_FREE;
|
|
|
|
dpcm->be->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_BE;
|
|
|
|
prune++;
|
|
|
|
}
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: found %d old BE paths for pruning\n", prune);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
return prune;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_add_paths(struct snd_soc_pcm_runtime *fe, int stream,
|
|
|
|
struct snd_soc_dapm_widget_list **list_)
|
|
|
|
{
|
|
|
|
struct snd_soc_card *card = fe->card;
|
|
|
|
struct snd_soc_dapm_widget_list *list = *list_;
|
|
|
|
struct snd_soc_pcm_runtime *be;
|
|
|
|
int i, new = 0, err;
|
|
|
|
|
|
|
|
/* Create any new FE <--> BE connections */
|
|
|
|
for (i = 0; i < list->num_widgets; i++) {
|
|
|
|
|
2013-06-05 18:36:11 +00:00
|
|
|
switch (list->widgets[i]->id) {
|
|
|
|
case snd_soc_dapm_dai_in:
|
|
|
|
case snd_soc_dapm_dai_out:
|
|
|
|
break;
|
|
|
|
default:
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
continue;
|
2013-06-05 18:36:11 +00:00
|
|
|
}
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
|
|
|
/* is there a valid BE rtd for this widget */
|
|
|
|
be = dpcm_get_be(card, list->widgets[i], stream);
|
|
|
|
if (!be) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev, "ASoC: no BE found for %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
list->widgets[i]->name);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* make sure BE is a real BE */
|
|
|
|
if (!be->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* don't connect if FE is not running */
|
|
|
|
if (!fe->dpcm[stream].runtime)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* newly connected FE and BE */
|
|
|
|
err = dpcm_be_connect(fe, be, stream);
|
|
|
|
if (err < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev, "ASoC: can't connect %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
list->widgets[i]->name);
|
|
|
|
break;
|
|
|
|
} else if (err == 0) /* already connected */
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* new */
|
|
|
|
be->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_BE;
|
|
|
|
new++;
|
|
|
|
}
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: found %d new BE paths\n", new);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
return new;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the corresponding BE DAIs that source or sink audio to this
|
|
|
|
* FE substream.
|
|
|
|
*/
|
|
|
|
static int dpcm_process_paths(struct snd_soc_pcm_runtime *fe,
|
|
|
|
int stream, struct snd_soc_dapm_widget_list **list, int new)
|
|
|
|
{
|
|
|
|
if (new)
|
|
|
|
return dpcm_add_paths(fe, stream, list);
|
|
|
|
else
|
|
|
|
return dpcm_prune_paths(fe, stream, list);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dpcm_clear_pending_state(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be)
|
|
|
|
dpcm->be->dpcm[stream].runtime_update =
|
|
|
|
SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dpcm_be_dai_startup_unwind(struct snd_soc_pcm_runtime *fe,
|
|
|
|
int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
|
|
|
|
/* disable any enabled and non active backends */
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
|
|
|
if (be->dpcm[stream].users == 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(be->dev, "ASoC: no users %s at close - state %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback",
|
|
|
|
be->dpcm[stream].state);
|
|
|
|
|
|
|
|
if (--be->dpcm[stream].users != 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
soc_pcm_close(be_substream);
|
|
|
|
be_substream->runtime = NULL;
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_CLOSE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_be_dai_startup(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int err, count = 0;
|
|
|
|
|
|
|
|
/* only startup BE DAIs that are either sinks or sources to this FE DAI */
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
2013-10-31 15:09:20 +00:00
|
|
|
if (!be_substream) {
|
|
|
|
dev_err(be->dev, "ASoC: no backend %s stream\n",
|
|
|
|
stream ? "capture" : "playback");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
/* is this op for this BE ? */
|
|
|
|
if (!snd_soc_dpcm_be_can_update(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* first time the dpcm is open ? */
|
|
|
|
if (be->dpcm[stream].users == DPCM_MAX_BE_USERS)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(be->dev, "ASoC: too many users %s at open %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback",
|
|
|
|
be->dpcm[stream].state);
|
|
|
|
|
|
|
|
if (be->dpcm[stream].users++ != 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_NEW) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_CLOSE))
|
|
|
|
continue;
|
|
|
|
|
2013-10-31 15:09:20 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: open %s BE %s\n",
|
|
|
|
stream ? "capture" : "playback", be->dai_link->name);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
|
|
|
be_substream->runtime = be->dpcm[stream].runtime;
|
|
|
|
err = soc_pcm_open(be_substream);
|
|
|
|
if (err < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(be->dev, "ASoC: BE open failed %d\n", err);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
be->dpcm[stream].users--;
|
|
|
|
if (be->dpcm[stream].users < 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(be->dev, "ASoC: no users %s at unwind %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback",
|
|
|
|
be->dpcm[stream].state);
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_CLOSE;
|
|
|
|
goto unwind;
|
|
|
|
}
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_OPEN;
|
|
|
|
count++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return count;
|
|
|
|
|
|
|
|
unwind:
|
|
|
|
/* disable any enabled and non active backends */
|
|
|
|
list_for_each_entry_continue_reverse(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
|
|
|
if (!snd_soc_dpcm_be_can_update(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (be->dpcm[stream].users == 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(be->dev, "ASoC: no users %s at close %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback",
|
|
|
|
be->dpcm[stream].state);
|
|
|
|
|
|
|
|
if (--be->dpcm[stream].users != 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
soc_pcm_close(be_substream);
|
|
|
|
be_substream->runtime = NULL;
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_CLOSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2014-01-06 13:19:06 +00:00
|
|
|
static void dpcm_init_runtime_hw(struct snd_pcm_runtime *runtime,
|
|
|
|
struct snd_soc_pcm_stream *stream)
|
|
|
|
{
|
|
|
|
runtime->hw.rate_min = stream->rate_min;
|
|
|
|
runtime->hw.rate_max = stream->rate_max;
|
|
|
|
runtime->hw.channels_min = stream->channels_min;
|
|
|
|
runtime->hw.channels_max = stream->channels_max;
|
2014-01-06 13:19:07 +00:00
|
|
|
if (runtime->hw.formats)
|
|
|
|
runtime->hw.formats &= stream->formats;
|
|
|
|
else
|
|
|
|
runtime->hw.formats = stream->formats;
|
2014-01-06 13:19:06 +00:00
|
|
|
runtime->hw.rates = stream->rates;
|
|
|
|
}
|
|
|
|
|
2012-05-09 20:46:27 +00:00
|
|
|
static void dpcm_set_fe_runtime(struct snd_pcm_substream *substream)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
{
|
|
|
|
struct snd_pcm_runtime *runtime = substream->runtime;
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai_driver *cpu_dai_drv = cpu_dai->driver;
|
|
|
|
|
2014-01-06 13:19:06 +00:00
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
dpcm_init_runtime_hw(runtime, &cpu_dai_drv->playback);
|
|
|
|
else
|
|
|
|
dpcm_init_runtime_hw(runtime, &cpu_dai_drv->capture);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_fe_dai_startup(struct snd_pcm_substream *fe_substream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = fe_substream->private_data;
|
|
|
|
struct snd_pcm_runtime *runtime = fe_substream->runtime;
|
|
|
|
int stream = fe_substream->stream, ret = 0;
|
|
|
|
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE;
|
|
|
|
|
|
|
|
ret = dpcm_be_dai_startup(fe, fe_substream->stream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: failed to start some BEs %d\n", ret);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
goto be_err;
|
|
|
|
}
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: open FE %s\n", fe->dai_link->name);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
|
|
|
/* start the DAI frontend */
|
|
|
|
ret = soc_pcm_open(fe_substream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: failed to start FE %d\n", ret);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
goto unwind;
|
|
|
|
}
|
|
|
|
|
|
|
|
fe->dpcm[stream].state = SND_SOC_DPCM_STATE_OPEN;
|
|
|
|
|
|
|
|
dpcm_set_fe_runtime(fe_substream);
|
|
|
|
snd_pcm_limit_hw_rates(runtime);
|
|
|
|
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
unwind:
|
|
|
|
dpcm_be_dai_startup_unwind(fe, fe_substream->stream);
|
|
|
|
be_err:
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_be_dai_shutdown(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
|
|
|
|
/* only shutdown BEs that are either sinks or sources to this FE DAI */
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
|
|
|
/* is this op for this BE ? */
|
|
|
|
if (!snd_soc_dpcm_be_can_update(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (be->dpcm[stream].users == 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(be->dev, "ASoC: no users %s at close - state %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
stream ? "capture" : "playback",
|
|
|
|
be->dpcm[stream].state);
|
|
|
|
|
|
|
|
if (--be->dpcm[stream].users != 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN))
|
|
|
|
continue;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: close BE %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
dpcm->fe->dai_link->name);
|
|
|
|
|
|
|
|
soc_pcm_close(be_substream);
|
|
|
|
be_substream->runtime = NULL;
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_CLOSE;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_fe_dai_shutdown(struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
int stream = substream->stream;
|
|
|
|
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE;
|
|
|
|
|
|
|
|
/* shutdown the BEs */
|
|
|
|
dpcm_be_dai_shutdown(fe, substream->stream);
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: close FE %s\n", fe->dai_link->name);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
|
|
|
/* now shutdown the frontend */
|
|
|
|
soc_pcm_close(substream);
|
|
|
|
|
|
|
|
/* run the stream event for each BE */
|
|
|
|
dpcm_dapm_stream_event(fe, stream, SND_SOC_DAPM_STREAM_STOP);
|
|
|
|
|
|
|
|
fe->dpcm[stream].state = SND_SOC_DPCM_STATE_CLOSE;
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_be_dai_hw_free(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
|
|
|
|
/* only hw_params backends that are either sinks or sources
|
|
|
|
* to this frontend DAI */
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
|
|
|
/* is this op for this BE ? */
|
|
|
|
if (!snd_soc_dpcm_be_can_update(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* only free hw when no longer used - check all FEs */
|
|
|
|
if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_PREPARE) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE) &&
|
2012-12-20 03:36:02 +00:00
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED) &&
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP))
|
|
|
|
continue;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: hw_free BE %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
dpcm->fe->dai_link->name);
|
|
|
|
|
|
|
|
soc_pcm_hw_free(be_substream);
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_HW_FREE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-05-09 20:46:27 +00:00
|
|
|
static int dpcm_fe_dai_hw_free(struct snd_pcm_substream *substream)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
int err, stream = substream->stream;
|
|
|
|
|
|
|
|
mutex_lock_nested(&fe->card->mutex, SND_SOC_CARD_CLASS_RUNTIME);
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: hw_free FE %s\n", fe->dai_link->name);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
|
|
|
/* call hw_free on the frontend */
|
|
|
|
err = soc_pcm_hw_free(substream);
|
|
|
|
if (err < 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: hw_free FE %s failed\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
fe->dai_link->name);
|
|
|
|
|
|
|
|
/* only hw_params backends that are either sinks or sources
|
|
|
|
* to this frontend DAI */
|
|
|
|
err = dpcm_be_dai_hw_free(fe, stream);
|
|
|
|
|
|
|
|
fe->dpcm[stream].state = SND_SOC_DPCM_STATE_HW_FREE;
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
|
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_be_dai_hw_params(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
|
|
|
/* is this op for this BE ? */
|
|
|
|
if (!snd_soc_dpcm_be_can_update(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* only allow hw_params() if no connected FEs are running */
|
|
|
|
if (!snd_soc_dpcm_can_be_params(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE))
|
|
|
|
continue;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: hw_params BE %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
dpcm->fe->dai_link->name);
|
|
|
|
|
|
|
|
/* copy params for each dpcm */
|
|
|
|
memcpy(&dpcm->hw_params, &fe->dpcm[stream].hw_params,
|
|
|
|
sizeof(struct snd_pcm_hw_params));
|
|
|
|
|
|
|
|
/* perform any hw_params fixups */
|
|
|
|
if (be->dai_link->be_hw_params_fixup) {
|
|
|
|
ret = be->dai_link->be_hw_params_fixup(be,
|
|
|
|
&dpcm->hw_params);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(be->dev,
|
2012-11-19 14:39:15 +00:00
|
|
|
"ASoC: hw_params BE fixup failed %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
ret);
|
|
|
|
goto unwind;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = soc_pcm_hw_params(be_substream, &dpcm->hw_params);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dpcm->be->dev,
|
2012-11-19 14:39:15 +00:00
|
|
|
"ASoC: hw_params BE failed %d\n", ret);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
goto unwind;
|
|
|
|
}
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_HW_PARAMS;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
unwind:
|
|
|
|
/* disable any enabled and non active backends */
|
|
|
|
list_for_each_entry_continue_reverse(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
|
|
|
if (!snd_soc_dpcm_be_can_update(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* only allow hw_free() if no connected FEs are running */
|
|
|
|
if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
soc_pcm_hw_free(be_substream);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-05-09 20:46:27 +00:00
|
|
|
static int dpcm_fe_dai_hw_params(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_pcm_hw_params *params)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
int ret, stream = substream->stream;
|
|
|
|
|
|
|
|
mutex_lock_nested(&fe->card->mutex, SND_SOC_CARD_CLASS_RUNTIME);
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE;
|
|
|
|
|
|
|
|
memcpy(&fe->dpcm[substream->stream].hw_params, params,
|
|
|
|
sizeof(struct snd_pcm_hw_params));
|
|
|
|
ret = dpcm_be_dai_hw_params(fe, substream->stream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: hw_params BE failed %d\n", ret);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: hw_params FE %s rate %d chan %x fmt %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
fe->dai_link->name, params_rate(params),
|
|
|
|
params_channels(params), params_format(params));
|
|
|
|
|
|
|
|
/* call hw_params on the frontend */
|
|
|
|
ret = soc_pcm_hw_params(substream, params);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: hw_params FE failed %d\n", ret);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
dpcm_be_dai_hw_free(fe, stream);
|
|
|
|
} else
|
|
|
|
fe->dpcm[stream].state = SND_SOC_DPCM_STATE_HW_PARAMS;
|
|
|
|
|
|
|
|
out:
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_do_trigger(struct snd_soc_dpcm *dpcm,
|
|
|
|
struct snd_pcm_substream *substream, int cmd)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(dpcm->be->dev, "ASoC: trigger BE %s cmd %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
dpcm->fe->dai_link->name, cmd);
|
|
|
|
|
|
|
|
ret = soc_pcm_trigger(substream, cmd);
|
|
|
|
if (ret < 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(dpcm->be->dev,"ASoC: trigger BE failed %d\n", ret);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-05-09 20:46:27 +00:00
|
|
|
static int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream,
|
|
|
|
int cmd)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
|
|
|
/* is this op for this BE ? */
|
|
|
|
if (!snd_soc_dpcm_be_can_update(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case SNDRV_PCM_TRIGGER_START:
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_PREPARE) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = dpcm_do_trigger(dpcm, be_substream, cmd);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_START;
|
|
|
|
break;
|
|
|
|
case SNDRV_PCM_TRIGGER_RESUME:
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = dpcm_do_trigger(dpcm, be_substream, cmd);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_START;
|
|
|
|
break;
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = dpcm_do_trigger(dpcm, be_substream, cmd);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_START;
|
|
|
|
break;
|
|
|
|
case SNDRV_PCM_TRIGGER_STOP:
|
|
|
|
if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = dpcm_do_trigger(dpcm, be_substream, cmd);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_STOP;
|
|
|
|
break;
|
|
|
|
case SNDRV_PCM_TRIGGER_SUSPEND:
|
|
|
|
if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = dpcm_do_trigger(dpcm, be_substream, cmd);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_SUSPEND;
|
|
|
|
break;
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
|
|
|
|
if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!snd_soc_dpcm_can_be_free_stop(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = dpcm_do_trigger(dpcm, be_substream, cmd);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_PAUSED;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dpcm_be_dai_trigger);
|
|
|
|
|
2012-05-09 20:46:27 +00:00
|
|
|
static int dpcm_fe_dai_trigger(struct snd_pcm_substream *substream, int cmd)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
int stream = substream->stream, ret;
|
|
|
|
enum snd_soc_dpcm_trigger trigger = fe->dai_link->trigger[stream];
|
|
|
|
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE;
|
|
|
|
|
|
|
|
switch (trigger) {
|
|
|
|
case SND_SOC_DPCM_TRIGGER_PRE:
|
|
|
|
/* call trigger on the frontend before the backend. */
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: pre trigger FE %s cmd %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
fe->dai_link->name, cmd);
|
|
|
|
|
|
|
|
ret = soc_pcm_trigger(substream, cmd);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: trigger FE failed %d\n", ret);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = dpcm_be_dai_trigger(fe, substream->stream, cmd);
|
|
|
|
break;
|
|
|
|
case SND_SOC_DPCM_TRIGGER_POST:
|
|
|
|
/* call trigger on the frontend after the backend. */
|
|
|
|
|
|
|
|
ret = dpcm_be_dai_trigger(fe, substream->stream, cmd);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: trigger FE failed %d\n", ret);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: post trigger FE %s cmd %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
fe->dai_link->name, cmd);
|
|
|
|
|
|
|
|
ret = soc_pcm_trigger(substream, cmd);
|
|
|
|
break;
|
2012-04-25 11:12:52 +00:00
|
|
|
case SND_SOC_DPCM_TRIGGER_BESPOKE:
|
|
|
|
/* bespoke trigger() - handles both FE and BEs */
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: bespoke trigger FE %s cmd %d\n",
|
2012-04-25 11:12:52 +00:00
|
|
|
fe->dai_link->name, cmd);
|
|
|
|
|
|
|
|
ret = soc_pcm_bespoke_trigger(substream, cmd);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: trigger FE failed %d\n", ret);
|
2012-04-25 11:12:52 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
break;
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
default:
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev, "ASoC: invalid trigger cmd %d for %s\n", cmd,
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
fe->dai_link->name);
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case SNDRV_PCM_TRIGGER_START:
|
|
|
|
case SNDRV_PCM_TRIGGER_RESUME:
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
|
|
|
|
fe->dpcm[stream].state = SND_SOC_DPCM_STATE_START;
|
|
|
|
break;
|
|
|
|
case SNDRV_PCM_TRIGGER_STOP:
|
|
|
|
case SNDRV_PCM_TRIGGER_SUSPEND:
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
|
|
|
|
fe->dpcm[stream].state = SND_SOC_DPCM_STATE_STOP;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_be_dai_prepare(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
|
|
|
/* is this op for this BE ? */
|
|
|
|
if (!snd_soc_dpcm_be_can_update(fe, be, stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP))
|
|
|
|
continue;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: prepare BE %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
dpcm->fe->dai_link->name);
|
|
|
|
|
|
|
|
ret = soc_pcm_prepare(be_substream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(be->dev, "ASoC: backend prepare failed %d\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
ret);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_PREPARE;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-05-09 20:46:27 +00:00
|
|
|
static int dpcm_fe_dai_prepare(struct snd_pcm_substream *substream)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
int stream = substream->stream, ret = 0;
|
|
|
|
|
|
|
|
mutex_lock_nested(&fe->card->mutex, SND_SOC_CARD_CLASS_RUNTIME);
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: prepare FE %s\n", fe->dai_link->name);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE;
|
|
|
|
|
|
|
|
/* there is no point preparing this FE if there are no BEs */
|
|
|
|
if (list_empty(&fe->dpcm[stream].be_clients)) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev, "ASoC: no backend DAIs enabled for %s\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
fe->dai_link->name);
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = dpcm_be_dai_prepare(fe, substream->stream);
|
|
|
|
if (ret < 0)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* call prepare on the frontend */
|
|
|
|
ret = soc_pcm_prepare(substream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: prepare FE %s failed\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
fe->dai_link->name);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* run the stream event for each BE */
|
|
|
|
dpcm_dapm_stream_event(fe, stream, SND_SOC_DAPM_STREAM_START);
|
|
|
|
fe->dpcm[stream].state = SND_SOC_DPCM_STATE_PREPARE;
|
|
|
|
|
|
|
|
out:
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-04-26 15:16:10 +00:00
|
|
|
static int soc_pcm_ioctl(struct snd_pcm_substream *substream,
|
|
|
|
unsigned int cmd, void *arg)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (platform->driver->ops && platform->driver->ops->ioctl)
|
2012-04-26 15:16:10 +00:00
|
|
|
return platform->driver->ops->ioctl(substream, cmd, arg);
|
|
|
|
return snd_pcm_lib_ioctl(substream, cmd, arg);
|
|
|
|
}
|
|
|
|
|
2012-04-25 11:12:51 +00:00
|
|
|
static int dpcm_run_update_shutdown(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
2012-04-25 11:12:52 +00:00
|
|
|
struct snd_pcm_substream *substream =
|
|
|
|
snd_soc_dpcm_get_substream(fe, stream);
|
|
|
|
enum snd_soc_dpcm_trigger trigger = fe->dai_link->trigger[stream];
|
2012-04-25 11:12:51 +00:00
|
|
|
int err;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: runtime %s close on FE %s\n",
|
2012-04-25 11:12:51 +00:00
|
|
|
stream ? "capture" : "playback", fe->dai_link->name);
|
|
|
|
|
2012-04-25 11:12:52 +00:00
|
|
|
if (trigger == SND_SOC_DPCM_TRIGGER_BESPOKE) {
|
|
|
|
/* call bespoke trigger - FE takes care of all BE triggers */
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: bespoke trigger FE %s cmd stop\n",
|
2012-04-25 11:12:52 +00:00
|
|
|
fe->dai_link->name);
|
|
|
|
|
|
|
|
err = soc_pcm_bespoke_trigger(substream, SNDRV_PCM_TRIGGER_STOP);
|
|
|
|
if (err < 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: trigger FE failed %d\n", err);
|
2012-04-25 11:12:52 +00:00
|
|
|
} else {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: trigger FE %s cmd stop\n",
|
2012-04-25 11:12:52 +00:00
|
|
|
fe->dai_link->name);
|
|
|
|
|
|
|
|
err = dpcm_be_dai_trigger(fe, stream, SNDRV_PCM_TRIGGER_STOP);
|
|
|
|
if (err < 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: trigger FE failed %d\n", err);
|
2012-04-25 11:12:52 +00:00
|
|
|
}
|
2012-04-25 11:12:51 +00:00
|
|
|
|
|
|
|
err = dpcm_be_dai_hw_free(fe, stream);
|
|
|
|
if (err < 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: hw_free FE failed %d\n", err);
|
2012-04-25 11:12:51 +00:00
|
|
|
|
|
|
|
err = dpcm_be_dai_shutdown(fe, stream);
|
|
|
|
if (err < 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: shutdown FE failed %d\n", err);
|
2012-04-25 11:12:51 +00:00
|
|
|
|
|
|
|
/* run the stream event for each BE */
|
|
|
|
dpcm_dapm_stream_event(fe, stream, SND_SOC_DAPM_STREAM_NOP);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_run_update_startup(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
2012-04-25 11:12:52 +00:00
|
|
|
struct snd_pcm_substream *substream =
|
|
|
|
snd_soc_dpcm_get_substream(fe, stream);
|
2012-04-25 11:12:51 +00:00
|
|
|
struct snd_soc_dpcm *dpcm;
|
2012-04-25 11:12:52 +00:00
|
|
|
enum snd_soc_dpcm_trigger trigger = fe->dai_link->trigger[stream];
|
2012-04-25 11:12:51 +00:00
|
|
|
int ret;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: runtime %s open on FE %s\n",
|
2012-04-25 11:12:51 +00:00
|
|
|
stream ? "capture" : "playback", fe->dai_link->name);
|
|
|
|
|
|
|
|
/* Only start the BE if the FE is ready */
|
|
|
|
if (fe->dpcm[stream].state == SND_SOC_DPCM_STATE_HW_FREE ||
|
|
|
|
fe->dpcm[stream].state == SND_SOC_DPCM_STATE_CLOSE)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* startup must always be called for new BEs */
|
|
|
|
ret = dpcm_be_dai_startup(fe, stream);
|
2013-01-10 08:59:57 +00:00
|
|
|
if (ret < 0)
|
2012-04-25 11:12:51 +00:00
|
|
|
goto disconnect;
|
|
|
|
|
|
|
|
/* keep going if FE state is > open */
|
|
|
|
if (fe->dpcm[stream].state == SND_SOC_DPCM_STATE_OPEN)
|
|
|
|
return 0;
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
2012-04-25 11:12:51 +00:00
|
|
|
ret = dpcm_be_dai_hw_params(fe, stream);
|
2013-01-10 08:59:57 +00:00
|
|
|
if (ret < 0)
|
2012-04-25 11:12:51 +00:00
|
|
|
goto close;
|
|
|
|
|
|
|
|
/* keep going if FE state is > hw_params */
|
|
|
|
if (fe->dpcm[stream].state == SND_SOC_DPCM_STATE_HW_PARAMS)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
|
|
ret = dpcm_be_dai_prepare(fe, stream);
|
2013-01-10 08:59:57 +00:00
|
|
|
if (ret < 0)
|
2012-04-25 11:12:51 +00:00
|
|
|
goto hw_free;
|
|
|
|
|
|
|
|
/* run the stream event for each BE */
|
|
|
|
dpcm_dapm_stream_event(fe, stream, SND_SOC_DAPM_STREAM_NOP);
|
|
|
|
|
|
|
|
/* keep going if FE state is > prepare */
|
|
|
|
if (fe->dpcm[stream].state == SND_SOC_DPCM_STATE_PREPARE ||
|
|
|
|
fe->dpcm[stream].state == SND_SOC_DPCM_STATE_STOP)
|
|
|
|
return 0;
|
|
|
|
|
2012-04-25 11:12:52 +00:00
|
|
|
if (trigger == SND_SOC_DPCM_TRIGGER_BESPOKE) {
|
|
|
|
/* call trigger on the frontend - FE takes care of all BE triggers */
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: bespoke trigger FE %s cmd start\n",
|
2012-04-25 11:12:52 +00:00
|
|
|
fe->dai_link->name);
|
2012-04-25 11:12:51 +00:00
|
|
|
|
2012-04-25 11:12:52 +00:00
|
|
|
ret = soc_pcm_bespoke_trigger(substream, SNDRV_PCM_TRIGGER_START);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: bespoke trigger FE failed %d\n", ret);
|
2012-04-25 11:12:52 +00:00
|
|
|
goto hw_free;
|
|
|
|
}
|
|
|
|
} else {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: trigger FE %s cmd start\n",
|
2012-04-25 11:12:52 +00:00
|
|
|
fe->dai_link->name);
|
|
|
|
|
|
|
|
ret = dpcm_be_dai_trigger(fe, stream,
|
|
|
|
SNDRV_PCM_TRIGGER_START);
|
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev,"ASoC: trigger FE failed %d\n", ret);
|
2012-04-25 11:12:52 +00:00
|
|
|
goto hw_free;
|
|
|
|
}
|
2012-04-25 11:12:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
hw_free:
|
|
|
|
dpcm_be_dai_hw_free(fe, stream);
|
|
|
|
close:
|
|
|
|
dpcm_be_dai_shutdown(fe, stream);
|
|
|
|
disconnect:
|
|
|
|
/* disconnect any non started BEs */
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START)
|
|
|
|
dpcm->state = SND_SOC_DPCM_LINK_STATE_FREE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_run_new_update(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_BE;
|
|
|
|
ret = dpcm_run_update_startup(fe, stream);
|
|
|
|
if (ret < 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev, "ASoC: failed to startup some BEs\n");
|
2012-04-25 11:12:51 +00:00
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_run_old_update(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_BE;
|
|
|
|
ret = dpcm_run_update_shutdown(fe, stream);
|
|
|
|
if (ret < 0)
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(fe->dev, "ASoC: failed to shutdown some BEs\n");
|
2012-04-25 11:12:51 +00:00
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Called by DAPM mixer/mux changes to update audio routing between PCMs and
|
|
|
|
* any DAI links.
|
|
|
|
*/
|
2013-07-24 13:27:36 +00:00
|
|
|
int soc_dpcm_runtime_update(struct snd_soc_card *card)
|
2012-04-25 11:12:51 +00:00
|
|
|
{
|
|
|
|
int i, old, new, paths;
|
|
|
|
|
|
|
|
mutex_lock_nested(&card->mutex, SND_SOC_CARD_CLASS_RUNTIME);
|
|
|
|
for (i = 0; i < card->num_rtd; i++) {
|
|
|
|
struct snd_soc_dapm_widget_list *list;
|
|
|
|
struct snd_soc_pcm_runtime *fe = &card->rtd[i];
|
|
|
|
|
|
|
|
/* make sure link is FE */
|
|
|
|
if (!fe->dai_link->dynamic)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* only check active links */
|
|
|
|
if (!fe->cpu_dai->active)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* DAPM sync will call this to update DSP paths */
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: DPCM runtime update for FE %s\n",
|
2012-04-25 11:12:51 +00:00
|
|
|
fe->dai_link->name);
|
|
|
|
|
|
|
|
/* skip if FE doesn't have playback capability */
|
|
|
|
if (!fe->cpu_dai->driver->playback.channels_min)
|
|
|
|
goto capture;
|
|
|
|
|
|
|
|
paths = dpcm_path_get(fe, SNDRV_PCM_STREAM_PLAYBACK, &list);
|
|
|
|
if (paths < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_warn(fe->dev, "ASoC: %s no valid %s path\n",
|
2012-04-25 11:12:51 +00:00
|
|
|
fe->dai_link->name, "playback");
|
|
|
|
mutex_unlock(&card->mutex);
|
|
|
|
return paths;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* update any new playback paths */
|
|
|
|
new = dpcm_process_paths(fe, SNDRV_PCM_STREAM_PLAYBACK, &list, 1);
|
|
|
|
if (new) {
|
|
|
|
dpcm_run_new_update(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
dpcm_clear_pending_state(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
dpcm_be_disconnect(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* update any old playback paths */
|
|
|
|
old = dpcm_process_paths(fe, SNDRV_PCM_STREAM_PLAYBACK, &list, 0);
|
|
|
|
if (old) {
|
|
|
|
dpcm_run_old_update(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
dpcm_clear_pending_state(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
dpcm_be_disconnect(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
}
|
|
|
|
|
|
|
|
capture:
|
|
|
|
/* skip if FE doesn't have capture capability */
|
|
|
|
if (!fe->cpu_dai->driver->capture.channels_min)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
paths = dpcm_path_get(fe, SNDRV_PCM_STREAM_CAPTURE, &list);
|
|
|
|
if (paths < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_warn(fe->dev, "ASoC: %s no valid %s path\n",
|
2012-04-25 11:12:51 +00:00
|
|
|
fe->dai_link->name, "capture");
|
|
|
|
mutex_unlock(&card->mutex);
|
|
|
|
return paths;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* update any new capture paths */
|
|
|
|
new = dpcm_process_paths(fe, SNDRV_PCM_STREAM_CAPTURE, &list, 1);
|
|
|
|
if (new) {
|
|
|
|
dpcm_run_new_update(fe, SNDRV_PCM_STREAM_CAPTURE);
|
|
|
|
dpcm_clear_pending_state(fe, SNDRV_PCM_STREAM_CAPTURE);
|
|
|
|
dpcm_be_disconnect(fe, SNDRV_PCM_STREAM_CAPTURE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* update any old capture paths */
|
|
|
|
old = dpcm_process_paths(fe, SNDRV_PCM_STREAM_CAPTURE, &list, 0);
|
|
|
|
if (old) {
|
|
|
|
dpcm_run_old_update(fe, SNDRV_PCM_STREAM_CAPTURE);
|
|
|
|
dpcm_clear_pending_state(fe, SNDRV_PCM_STREAM_CAPTURE);
|
|
|
|
dpcm_be_disconnect(fe, SNDRV_PCM_STREAM_CAPTURE);
|
|
|
|
}
|
|
|
|
|
|
|
|
dpcm_path_put(&list);
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&card->mutex);
|
|
|
|
return 0;
|
|
|
|
}
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
int soc_dpcm_be_digital_mute(struct snd_soc_pcm_runtime *fe, int mute)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
struct list_head *clients =
|
|
|
|
&fe->dpcm[SNDRV_PCM_STREAM_PLAYBACK].be_clients;
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, clients, list_be) {
|
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_soc_dai *dai = be->codec_dai;
|
|
|
|
struct snd_soc_dai_driver *drv = dai->driver;
|
|
|
|
|
|
|
|
if (be->dai_link->ignore_suspend)
|
|
|
|
continue;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: BE digital mute %s\n", be->dai_link->name);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
2013-10-31 00:47:39 +00:00
|
|
|
if (drv->ops && drv->ops->digital_mute && dai->playback_active)
|
|
|
|
drv->ops->digital_mute(dai, mute);
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-05-09 20:46:27 +00:00
|
|
|
static int dpcm_fe_dai_open(struct snd_pcm_substream *fe_substream)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = fe_substream->private_data;
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
struct snd_soc_dapm_widget_list *list;
|
|
|
|
int ret;
|
|
|
|
int stream = fe_substream->stream;
|
|
|
|
|
|
|
|
mutex_lock_nested(&fe->card->mutex, SND_SOC_CARD_CLASS_RUNTIME);
|
|
|
|
fe->dpcm[stream].runtime = fe_substream->runtime;
|
|
|
|
|
|
|
|
if (dpcm_path_get(fe, stream, &list) <= 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(fe->dev, "ASoC: %s no valid %s route\n",
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
fe->dai_link->name, stream ? "capture" : "playback");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* calculate valid and active FE <-> BE dpcms */
|
|
|
|
dpcm_process_paths(fe, stream, &list, 1);
|
|
|
|
|
|
|
|
ret = dpcm_fe_dai_startup(fe_substream);
|
|
|
|
if (ret < 0) {
|
|
|
|
/* clean up all links */
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be)
|
|
|
|
dpcm->state = SND_SOC_DPCM_LINK_STATE_FREE;
|
|
|
|
|
|
|
|
dpcm_be_disconnect(fe, stream);
|
|
|
|
fe->dpcm[stream].runtime = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
dpcm_clear_pending_state(fe, stream);
|
|
|
|
dpcm_path_put(&list);
|
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-05-09 20:46:27 +00:00
|
|
|
static int dpcm_fe_dai_close(struct snd_pcm_substream *fe_substream)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = fe_substream->private_data;
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int stream = fe_substream->stream, ret;
|
|
|
|
|
|
|
|
mutex_lock_nested(&fe->card->mutex, SND_SOC_CARD_CLASS_RUNTIME);
|
|
|
|
ret = dpcm_fe_dai_shutdown(fe_substream);
|
|
|
|
|
|
|
|
/* mark FE's links ready to prune */
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be)
|
|
|
|
dpcm->state = SND_SOC_DPCM_LINK_STATE_FREE;
|
|
|
|
|
|
|
|
dpcm_be_disconnect(fe, stream);
|
|
|
|
|
|
|
|
fe->dpcm[stream].runtime = NULL;
|
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
/* create a new pcm */
|
|
|
|
int soc_new_pcm(struct snd_soc_pcm_runtime *rtd, int num)
|
|
|
|
{
|
|
|
|
struct snd_soc_platform *platform = rtd->platform;
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dai;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_pcm *pcm;
|
|
|
|
char new_name[64];
|
|
|
|
int ret = 0, playback = 0, capture = 0;
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
|
|
|
|
if (cpu_dai->driver->playback.channels_min)
|
|
|
|
playback = 1;
|
|
|
|
if (cpu_dai->driver->capture.channels_min)
|
|
|
|
capture = 1;
|
|
|
|
} else {
|
2013-06-01 22:13:53 +00:00
|
|
|
if (codec_dai->driver->playback.channels_min &&
|
|
|
|
cpu_dai->driver->playback.channels_min)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
playback = 1;
|
2013-06-01 22:13:53 +00:00
|
|
|
if (codec_dai->driver->capture.channels_min &&
|
|
|
|
cpu_dai->driver->capture.channels_min)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
capture = 1;
|
|
|
|
}
|
|
|
|
|
2013-08-29 13:32:13 +00:00
|
|
|
if (rtd->dai_link->playback_only) {
|
|
|
|
playback = 1;
|
|
|
|
capture = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rtd->dai_link->capture_only) {
|
|
|
|
playback = 0;
|
|
|
|
capture = 1;
|
|
|
|
}
|
|
|
|
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
/* create the PCM */
|
|
|
|
if (rtd->dai_link->no_pcm) {
|
|
|
|
snprintf(new_name, sizeof(new_name), "(%s)",
|
|
|
|
rtd->dai_link->stream_name);
|
|
|
|
|
|
|
|
ret = snd_pcm_new_internal(rtd->card->snd_card, new_name, num,
|
|
|
|
playback, capture, &pcm);
|
|
|
|
} else {
|
|
|
|
if (rtd->dai_link->dynamic)
|
|
|
|
snprintf(new_name, sizeof(new_name), "%s (*)",
|
|
|
|
rtd->dai_link->stream_name);
|
|
|
|
else
|
|
|
|
snprintf(new_name, sizeof(new_name), "%s %s-%d",
|
|
|
|
rtd->dai_link->stream_name, codec_dai->name, num);
|
|
|
|
|
|
|
|
ret = snd_pcm_new(rtd->card->snd_card, new_name, num, playback,
|
|
|
|
capture, &pcm);
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
if (ret < 0) {
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_err(rtd->card->dev, "ASoC: can't create pcm for %s\n",
|
2012-07-06 15:54:52 +00:00
|
|
|
rtd->dai_link->name);
|
2011-06-09 13:45:53 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(rtd->card->dev, "ASoC: registered pcm #%d %s\n",num, new_name);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
/* DAPM dai link stream work */
|
|
|
|
INIT_DELAYED_WORK(&rtd->delayed_work, close_delayed_work);
|
|
|
|
|
|
|
|
rtd->pcm = pcm;
|
|
|
|
pcm->private_data = rtd;
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
|
|
|
if (rtd->dai_link->no_pcm) {
|
|
|
|
if (playback)
|
|
|
|
pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream->private_data = rtd;
|
|
|
|
if (capture)
|
|
|
|
pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream->private_data = rtd;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ASoC PCM operations */
|
|
|
|
if (rtd->dai_link->dynamic) {
|
|
|
|
rtd->ops.open = dpcm_fe_dai_open;
|
|
|
|
rtd->ops.hw_params = dpcm_fe_dai_hw_params;
|
|
|
|
rtd->ops.prepare = dpcm_fe_dai_prepare;
|
|
|
|
rtd->ops.trigger = dpcm_fe_dai_trigger;
|
|
|
|
rtd->ops.hw_free = dpcm_fe_dai_hw_free;
|
|
|
|
rtd->ops.close = dpcm_fe_dai_close;
|
|
|
|
rtd->ops.pointer = soc_pcm_pointer;
|
2012-04-26 15:16:10 +00:00
|
|
|
rtd->ops.ioctl = soc_pcm_ioctl;
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
} else {
|
|
|
|
rtd->ops.open = soc_pcm_open;
|
|
|
|
rtd->ops.hw_params = soc_pcm_hw_params;
|
|
|
|
rtd->ops.prepare = soc_pcm_prepare;
|
|
|
|
rtd->ops.trigger = soc_pcm_trigger;
|
|
|
|
rtd->ops.hw_free = soc_pcm_hw_free;
|
|
|
|
rtd->ops.close = soc_pcm_close;
|
|
|
|
rtd->ops.pointer = soc_pcm_pointer;
|
2012-04-26 15:16:10 +00:00
|
|
|
rtd->ops.ioctl = soc_pcm_ioctl;
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
}
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
if (platform->driver->ops) {
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
rtd->ops.ack = platform->driver->ops->ack;
|
|
|
|
rtd->ops.copy = platform->driver->ops->copy;
|
|
|
|
rtd->ops.silence = platform->driver->ops->silence;
|
|
|
|
rtd->ops.page = platform->driver->ops->page;
|
|
|
|
rtd->ops.mmap = platform->driver->ops->mmap;
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (playback)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &rtd->ops);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
if (capture)
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &rtd->ops);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
if (platform->driver->pcm_new) {
|
|
|
|
ret = platform->driver->pcm_new(rtd);
|
|
|
|
if (ret < 0) {
|
2012-09-26 13:25:17 +00:00
|
|
|
dev_err(platform->dev,
|
|
|
|
"ASoC: pcm constructor failed: %d\n",
|
|
|
|
ret);
|
2011-06-09 13:45:53 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pcm->private_free = platform->driver->pcm_free;
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
out:
|
2013-09-30 14:08:15 +00:00
|
|
|
dev_info(rtd->card->dev, "%s <-> %s mapping ok\n", codec_dai->name,
|
2011-06-09 13:45:53 +00:00
|
|
|
cpu_dai->name);
|
|
|
|
return ret;
|
|
|
|
}
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 11:12:49 +00:00
|
|
|
|
|
|
|
/* is the current PCM operation for this FE ? */
|
|
|
|
int snd_soc_dpcm_fe_can_update(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
if (fe->dpcm[stream].runtime_update == SND_SOC_DPCM_UPDATE_FE)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_dpcm_fe_can_update);
|
|
|
|
|
|
|
|
/* is the current PCM operation for this BE ? */
|
|
|
|
int snd_soc_dpcm_be_can_update(struct snd_soc_pcm_runtime *fe,
|
|
|
|
struct snd_soc_pcm_runtime *be, int stream)
|
|
|
|
{
|
|
|
|
if ((fe->dpcm[stream].runtime_update == SND_SOC_DPCM_UPDATE_FE) ||
|
|
|
|
((fe->dpcm[stream].runtime_update == SND_SOC_DPCM_UPDATE_BE) &&
|
|
|
|
be->dpcm[stream].runtime_update))
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_dpcm_be_can_update);
|
|
|
|
|
|
|
|
/* get the substream for this BE */
|
|
|
|
struct snd_pcm_substream *
|
|
|
|
snd_soc_dpcm_get_substream(struct snd_soc_pcm_runtime *be, int stream)
|
|
|
|
{
|
|
|
|
return be->pcm->streams[stream].substream;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_dpcm_get_substream);
|
|
|
|
|
|
|
|
/* get the BE runtime state */
|
|
|
|
enum snd_soc_dpcm_state
|
|
|
|
snd_soc_dpcm_be_get_state(struct snd_soc_pcm_runtime *be, int stream)
|
|
|
|
{
|
|
|
|
return be->dpcm[stream].state;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_dpcm_be_get_state);
|
|
|
|
|
|
|
|
/* set the BE runtime state */
|
|
|
|
void snd_soc_dpcm_be_set_state(struct snd_soc_pcm_runtime *be,
|
|
|
|
int stream, enum snd_soc_dpcm_state state)
|
|
|
|
{
|
|
|
|
be->dpcm[stream].state = state;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_dpcm_be_set_state);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We can only hw_free, stop, pause or suspend a BE DAI if any of it's FE
|
|
|
|
* are not running, paused or suspended for the specified stream direction.
|
|
|
|
*/
|
|
|
|
int snd_soc_dpcm_can_be_free_stop(struct snd_soc_pcm_runtime *fe,
|
|
|
|
struct snd_soc_pcm_runtime *be, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int state;
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &be->dpcm[stream].fe_clients, list_fe) {
|
|
|
|
|
|
|
|
if (dpcm->fe == fe)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
state = dpcm->fe->dpcm[stream].state;
|
|
|
|
if (state == SND_SOC_DPCM_STATE_START ||
|
|
|
|
state == SND_SOC_DPCM_STATE_PAUSED ||
|
|
|
|
state == SND_SOC_DPCM_STATE_SUSPEND)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* it's safe to free/stop this BE DAI */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_dpcm_can_be_free_stop);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We can only change hw params a BE DAI if any of it's FE are not prepared,
|
|
|
|
* running, paused or suspended for the specified stream direction.
|
|
|
|
*/
|
|
|
|
int snd_soc_dpcm_can_be_params(struct snd_soc_pcm_runtime *fe,
|
|
|
|
struct snd_soc_pcm_runtime *be, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int state;
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &be->dpcm[stream].fe_clients, list_fe) {
|
|
|
|
|
|
|
|
if (dpcm->fe == fe)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
state = dpcm->fe->dpcm[stream].state;
|
|
|
|
if (state == SND_SOC_DPCM_STATE_START ||
|
|
|
|
state == SND_SOC_DPCM_STATE_PAUSED ||
|
|
|
|
state == SND_SOC_DPCM_STATE_SUSPEND ||
|
|
|
|
state == SND_SOC_DPCM_STATE_PREPARE)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* it's safe to change hw_params */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_dpcm_can_be_params);
|
2012-04-25 11:12:50 +00:00
|
|
|
|
2012-04-25 11:12:52 +00:00
|
|
|
int snd_soc_platform_trigger(struct snd_pcm_substream *substream,
|
|
|
|
int cmd, struct snd_soc_platform *platform)
|
|
|
|
{
|
2013-10-31 00:47:39 +00:00
|
|
|
if (platform->driver->ops && platform->driver->ops->trigger)
|
2012-04-25 11:12:52 +00:00
|
|
|
return platform->driver->ops->trigger(substream, cmd);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_platform_trigger);
|
|
|
|
|
2012-04-25 11:12:50 +00:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
|
|
|
static char *dpcm_state_string(enum snd_soc_dpcm_state state)
|
|
|
|
{
|
|
|
|
switch (state) {
|
|
|
|
case SND_SOC_DPCM_STATE_NEW:
|
|
|
|
return "new";
|
|
|
|
case SND_SOC_DPCM_STATE_OPEN:
|
|
|
|
return "open";
|
|
|
|
case SND_SOC_DPCM_STATE_HW_PARAMS:
|
|
|
|
return "hw_params";
|
|
|
|
case SND_SOC_DPCM_STATE_PREPARE:
|
|
|
|
return "prepare";
|
|
|
|
case SND_SOC_DPCM_STATE_START:
|
|
|
|
return "start";
|
|
|
|
case SND_SOC_DPCM_STATE_STOP:
|
|
|
|
return "stop";
|
|
|
|
case SND_SOC_DPCM_STATE_SUSPEND:
|
|
|
|
return "suspend";
|
|
|
|
case SND_SOC_DPCM_STATE_PAUSED:
|
|
|
|
return "paused";
|
|
|
|
case SND_SOC_DPCM_STATE_HW_FREE:
|
|
|
|
return "hw_free";
|
|
|
|
case SND_SOC_DPCM_STATE_CLOSE:
|
|
|
|
return "close";
|
|
|
|
}
|
|
|
|
|
|
|
|
return "unknown";
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t dpcm_show_state(struct snd_soc_pcm_runtime *fe,
|
|
|
|
int stream, char *buf, size_t size)
|
|
|
|
{
|
|
|
|
struct snd_pcm_hw_params *params = &fe->dpcm[stream].hw_params;
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
ssize_t offset = 0;
|
|
|
|
|
|
|
|
/* FE state */
|
|
|
|
offset += snprintf(buf + offset, size - offset,
|
|
|
|
"[%s - %s]\n", fe->dai_link->name,
|
|
|
|
stream ? "Capture" : "Playback");
|
|
|
|
|
|
|
|
offset += snprintf(buf + offset, size - offset, "State: %s\n",
|
|
|
|
dpcm_state_string(fe->dpcm[stream].state));
|
|
|
|
|
|
|
|
if ((fe->dpcm[stream].state >= SND_SOC_DPCM_STATE_HW_PARAMS) &&
|
|
|
|
(fe->dpcm[stream].state <= SND_SOC_DPCM_STATE_STOP))
|
|
|
|
offset += snprintf(buf + offset, size - offset,
|
|
|
|
"Hardware Params: "
|
|
|
|
"Format = %s, Channels = %d, Rate = %d\n",
|
|
|
|
snd_pcm_format_name(params_format(params)),
|
|
|
|
params_channels(params),
|
|
|
|
params_rate(params));
|
|
|
|
|
|
|
|
/* BEs state */
|
|
|
|
offset += snprintf(buf + offset, size - offset, "Backends:\n");
|
|
|
|
|
|
|
|
if (list_empty(&fe->dpcm[stream].be_clients)) {
|
|
|
|
offset += snprintf(buf + offset, size - offset,
|
|
|
|
" No active DSP links\n");
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
params = &dpcm->hw_params;
|
|
|
|
|
|
|
|
offset += snprintf(buf + offset, size - offset,
|
|
|
|
"- %s\n", be->dai_link->name);
|
|
|
|
|
|
|
|
offset += snprintf(buf + offset, size - offset,
|
|
|
|
" State: %s\n",
|
|
|
|
dpcm_state_string(be->dpcm[stream].state));
|
|
|
|
|
|
|
|
if ((be->dpcm[stream].state >= SND_SOC_DPCM_STATE_HW_PARAMS) &&
|
|
|
|
(be->dpcm[stream].state <= SND_SOC_DPCM_STATE_STOP))
|
|
|
|
offset += snprintf(buf + offset, size - offset,
|
|
|
|
" Hardware Params: "
|
|
|
|
"Format = %s, Channels = %d, Rate = %d\n",
|
|
|
|
snd_pcm_format_name(params_format(params)),
|
|
|
|
params_channels(params),
|
|
|
|
params_rate(params));
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
return offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t dpcm_state_read_file(struct file *file, char __user *user_buf,
|
|
|
|
size_t count, loff_t *ppos)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = file->private_data;
|
|
|
|
ssize_t out_count = PAGE_SIZE, offset = 0, ret = 0;
|
|
|
|
char *buf;
|
|
|
|
|
|
|
|
buf = kmalloc(out_count, GFP_KERNEL);
|
|
|
|
if (!buf)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (fe->cpu_dai->driver->playback.channels_min)
|
|
|
|
offset += dpcm_show_state(fe, SNDRV_PCM_STREAM_PLAYBACK,
|
|
|
|
buf + offset, out_count - offset);
|
|
|
|
|
|
|
|
if (fe->cpu_dai->driver->capture.channels_min)
|
|
|
|
offset += dpcm_show_state(fe, SNDRV_PCM_STREAM_CAPTURE,
|
|
|
|
buf + offset, out_count - offset);
|
|
|
|
|
2012-04-27 10:33:46 +00:00
|
|
|
ret = simple_read_from_buffer(user_buf, count, ppos, buf, offset);
|
2012-04-25 11:12:50 +00:00
|
|
|
|
2012-04-27 10:33:46 +00:00
|
|
|
kfree(buf);
|
|
|
|
return ret;
|
2012-04-25 11:12:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations dpcm_state_fops = {
|
2012-04-27 10:33:46 +00:00
|
|
|
.open = simple_open,
|
2012-04-25 11:12:50 +00:00
|
|
|
.read = dpcm_state_read_file,
|
|
|
|
.llseek = default_llseek,
|
|
|
|
};
|
|
|
|
|
|
|
|
int soc_dpcm_debugfs_add(struct snd_soc_pcm_runtime *rtd)
|
|
|
|
{
|
2012-05-08 09:33:47 +00:00
|
|
|
if (!rtd->dai_link)
|
|
|
|
return 0;
|
|
|
|
|
2012-04-25 11:12:50 +00:00
|
|
|
rtd->debugfs_dpcm_root = debugfs_create_dir(rtd->dai_link->name,
|
|
|
|
rtd->card->debugfs_card_root);
|
|
|
|
if (!rtd->debugfs_dpcm_root) {
|
|
|
|
dev_dbg(rtd->dev,
|
|
|
|
"ASoC: Failed to create dpcm debugfs directory %s\n",
|
|
|
|
rtd->dai_link->name);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2012-04-27 10:33:46 +00:00
|
|
|
rtd->debugfs_dpcm_state = debugfs_create_file("state", 0444,
|
2012-04-25 11:12:50 +00:00
|
|
|
rtd->debugfs_dpcm_root,
|
|
|
|
rtd, &dpcm_state_fops);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|