2018-07-02 06:22:44 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
|
|
|
//
|
|
|
|
// 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>
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
#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
|
|
|
|
|
2015-08-24 12:16:51 +00:00
|
|
|
/*
|
|
|
|
* snd_soc_dai_stream_valid() - check if a DAI supports the given stream
|
|
|
|
*
|
|
|
|
* Returns true if the DAI supports the indicated stream type.
|
|
|
|
*/
|
|
|
|
static bool snd_soc_dai_stream_valid(struct snd_soc_dai *dai, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_stream *codec_stream;
|
|
|
|
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
codec_stream = &dai->driver->playback;
|
|
|
|
else
|
|
|
|
codec_stream = &dai->driver->capture;
|
|
|
|
|
|
|
|
/* If the codec specifies any rate at all, it supports the stream. */
|
|
|
|
return codec_stream->rates;
|
|
|
|
}
|
|
|
|
|
2014-03-05 12:17:43 +00:00
|
|
|
/**
|
|
|
|
* snd_soc_runtime_activate() - Increment active count for PCM runtime components
|
|
|
|
* @rtd: ASoC PCM runtime that is activated
|
|
|
|
* @stream: Direction of the PCM stream
|
|
|
|
*
|
|
|
|
* Increments the active count for all the DAIs and components attached to a PCM
|
|
|
|
* runtime. Should typically be called when a stream is opened.
|
|
|
|
*
|
|
|
|
* Must be called with the rtd->pcm_mutex being held
|
|
|
|
*/
|
|
|
|
void snd_soc_runtime_activate(struct snd_soc_pcm_runtime *rtd, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
int i;
|
2014-03-05 12:17:43 +00:00
|
|
|
|
|
|
|
lockdep_assert_held(&rtd->pcm_mutex);
|
|
|
|
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
|
|
|
cpu_dai->playback_active++;
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
rtd->codec_dais[i]->playback_active++;
|
2014-03-05 12:17:43 +00:00
|
|
|
} else {
|
|
|
|
cpu_dai->capture_active++;
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
rtd->codec_dais[i]->capture_active++;
|
2014-03-05 12:17:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
cpu_dai->active++;
|
2014-03-05 12:17:47 +00:00
|
|
|
cpu_dai->component->active++;
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
rtd->codec_dais[i]->active++;
|
|
|
|
rtd->codec_dais[i]->component->active++;
|
|
|
|
}
|
2014-03-05 12:17:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* snd_soc_runtime_deactivate() - Decrement active count for PCM runtime components
|
|
|
|
* @rtd: ASoC PCM runtime that is deactivated
|
|
|
|
* @stream: Direction of the PCM stream
|
|
|
|
*
|
|
|
|
* Decrements the active count for all the DAIs and components attached to a PCM
|
|
|
|
* runtime. Should typically be called when a stream is closed.
|
|
|
|
*
|
|
|
|
* Must be called with the rtd->pcm_mutex being held
|
|
|
|
*/
|
|
|
|
void snd_soc_runtime_deactivate(struct snd_soc_pcm_runtime *rtd, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
int i;
|
2014-03-05 12:17:43 +00:00
|
|
|
|
|
|
|
lockdep_assert_held(&rtd->pcm_mutex);
|
|
|
|
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
|
|
|
cpu_dai->playback_active--;
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
rtd->codec_dais[i]->playback_active--;
|
2014-03-05 12:17:43 +00:00
|
|
|
} else {
|
|
|
|
cpu_dai->capture_active--;
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
rtd->codec_dais[i]->capture_active--;
|
2014-03-05 12:17:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
cpu_dai->active--;
|
2014-03-05 12:17:47 +00:00
|
|
|
cpu_dai->component->active--;
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
rtd->codec_dais[i]->component->active--;
|
|
|
|
rtd->codec_dais[i]->active--;
|
|
|
|
}
|
2014-03-05 12:17:43 +00:00
|
|
|
}
|
|
|
|
|
2014-03-05 12:17:42 +00:00
|
|
|
/**
|
|
|
|
* snd_soc_runtime_ignore_pmdown_time() - Check whether to ignore the power down delay
|
|
|
|
* @rtd: The ASoC PCM runtime that should be checked.
|
|
|
|
*
|
|
|
|
* This function checks whether the power down delay should be ignored for a
|
|
|
|
* specific PCM runtime. Returns true if the delay is 0, if it the DAI link has
|
|
|
|
* been configured to ignore the delay, or if none of the components benefits
|
|
|
|
* from having the delay.
|
|
|
|
*/
|
|
|
|
bool snd_soc_runtime_ignore_pmdown_time(struct snd_soc_pcm_runtime *rtd)
|
|
|
|
{
|
2017-10-11 01:38:08 +00:00
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
2014-07-08 21:19:35 +00:00
|
|
|
bool ignore = true;
|
|
|
|
|
2014-03-05 12:17:42 +00:00
|
|
|
if (!rtd->pmdown_time || rtd->dai_link->ignore_pmdown_time)
|
|
|
|
return true;
|
|
|
|
|
2017-10-11 01:38:08 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
2018-01-19 05:21:19 +00:00
|
|
|
ignore &= !component->driver->use_pmdown_time;
|
2017-10-11 01:38:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return ignore;
|
2014-03-05 12:17:42 +00:00
|
|
|
}
|
|
|
|
|
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. */
|
2014-01-17 17:03:55 +00:00
|
|
|
int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir,
|
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 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);
|
|
|
|
|
2017-07-15 06:15:05 +00:00
|
|
|
if ((event == SND_SOC_DAPM_STREAM_STOP) &&
|
|
|
|
(be->dpcm[dir].users >= 1))
|
|
|
|
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
|
|
|
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);
|
|
|
|
|
2015-10-18 13:39:28 +00:00
|
|
|
ret = snd_pcm_hw_constraint_single(substream->runtime,
|
2013-11-13 10:56:24 +00:00
|
|
|
SNDRV_PCM_HW_PARAM_RATE,
|
2015-10-18 13:39:28 +00:00
|
|
|
soc_dai->rate);
|
2013-11-13 10:56:24 +00:00
|
|
|
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);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2015-10-18 13:39:28 +00:00
|
|
|
ret = snd_pcm_hw_constraint_single(substream->runtime,
|
2013-11-13 10:56:24 +00:00
|
|
|
SNDRV_PCM_HW_PARAM_CHANNELS,
|
|
|
|
soc_dai->channels);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(soc_dai->dev,
|
|
|
|
"ASoC: Unable to apply channel symmetry 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->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);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2015-10-18 13:39:28 +00:00
|
|
|
ret = snd_pcm_hw_constraint_single(substream->runtime,
|
2013-11-13 10:56:24 +00:00
|
|
|
SNDRV_PCM_HW_PARAM_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;
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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;
|
2014-07-08 21:19:35 +00:00
|
|
|
unsigned int rate, channels, sample_bits, symmetry, i;
|
2013-11-13 10:56:24 +00:00
|
|
|
|
|
|
|
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 ||
|
|
|
|
rtd->dai_link->symmetric_rates;
|
2014-07-08 21:19:35 +00:00
|
|
|
|
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
symmetry |= rtd->codec_dais[i]->driver->symmetric_rates;
|
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
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 ||
|
|
|
|
rtd->dai_link->symmetric_channels;
|
2014-07-08 21:19:35 +00:00
|
|
|
|
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
symmetry |= rtd->codec_dais[i]->driver->symmetric_channels;
|
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
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 ||
|
|
|
|
rtd->dai_link->symmetric_samplebits;
|
2014-07-08 21:19:35 +00:00
|
|
|
|
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
symmetry |= rtd->codec_dais[i]->driver->symmetric_samplebits;
|
|
|
|
|
2013-11-13 10:56:24 +00:00
|
|
|
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_link *link = rtd->dai_link;
|
2014-07-08 21:19:35 +00:00
|
|
|
unsigned int symmetry, i;
|
2013-11-30 16:38:58 +00:00
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
symmetry = cpu_driver->symmetric_rates || link->symmetric_rates ||
|
|
|
|
cpu_driver->symmetric_channels || link->symmetric_channels ||
|
|
|
|
cpu_driver->symmetric_samplebits || link->symmetric_samplebits;
|
2013-11-30 16:38:58 +00:00
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
symmetry = symmetry ||
|
|
|
|
rtd->codec_dais[i]->driver->symmetric_rates ||
|
|
|
|
rtd->codec_dais[i]->driver->symmetric_channels ||
|
|
|
|
rtd->codec_dais[i]->driver->symmetric_samplebits;
|
|
|
|
|
|
|
|
return symmetry;
|
2013-11-30 16:38:58 +00:00
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
static void soc_pcm_set_msb(struct snd_pcm_substream *substream, int bits)
|
2012-01-16 18:38:51 +00:00
|
|
|
{
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
2014-12-31 16:10:34 +00:00
|
|
|
int ret;
|
2012-01-16 18:38:51 +00:00
|
|
|
|
|
|
|
if (!bits)
|
|
|
|
return;
|
|
|
|
|
2014-12-29 17:43:38 +00:00
|
|
|
ret = snd_pcm_hw_constraint_msbits(substream->runtime, 0, 0, bits);
|
|
|
|
if (ret != 0)
|
|
|
|
dev_warn(rtd->dev, "ASoC: Failed to set MSB %d: %d\n",
|
|
|
|
bits, ret);
|
2012-01-16 18:38:51 +00:00
|
|
|
}
|
|
|
|
|
2014-07-01 07:47:55 +00:00
|
|
|
static void soc_pcm_apply_msb(struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i;
|
2014-07-01 07:47:55 +00:00
|
|
|
unsigned int bits = 0, cpu_bits;
|
|
|
|
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
|
|
|
if (codec_dai->driver->playback.sig_bits == 0) {
|
|
|
|
bits = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
bits = max(codec_dai->driver->playback.sig_bits, bits);
|
|
|
|
}
|
2014-07-01 07:47:55 +00:00
|
|
|
cpu_bits = cpu_dai->driver->playback.sig_bits;
|
|
|
|
} else {
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
2014-10-07 12:33:46 +00:00
|
|
|
if (codec_dai->driver->capture.sig_bits == 0) {
|
2014-07-08 21:19:35 +00:00
|
|
|
bits = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
bits = max(codec_dai->driver->capture.sig_bits, bits);
|
|
|
|
}
|
2014-07-01 07:47:55 +00:00
|
|
|
cpu_bits = cpu_dai->driver->capture.sig_bits;
|
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
soc_pcm_set_msb(substream, bits);
|
|
|
|
soc_pcm_set_msb(substream, cpu_bits);
|
2014-07-01 07:47:55 +00:00
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
static void soc_pcm_init_runtime_hw(struct snd_pcm_substream *substream)
|
2013-05-14 09:05:31 +00:00
|
|
|
{
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_pcm_runtime *runtime = substream->runtime;
|
2013-11-27 08:58:18 +00:00
|
|
|
struct snd_pcm_hardware *hw = &runtime->hw;
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_dai_driver *cpu_dai_drv = rtd->cpu_dai->driver;
|
|
|
|
struct snd_soc_dai_driver *codec_dai_drv;
|
|
|
|
struct snd_soc_pcm_stream *codec_stream;
|
|
|
|
struct snd_soc_pcm_stream *cpu_stream;
|
|
|
|
unsigned int chan_min = 0, chan_max = UINT_MAX;
|
|
|
|
unsigned int rate_min = 0, rate_max = UINT_MAX;
|
|
|
|
unsigned int rates = UINT_MAX;
|
|
|
|
u64 formats = ULLONG_MAX;
|
|
|
|
int i;
|
2013-11-27 08:58:18 +00:00
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
cpu_stream = &cpu_dai_drv->playback;
|
2014-01-06 13:19:16 +00:00
|
|
|
else
|
2014-07-08 21:19:35 +00:00
|
|
|
cpu_stream = &cpu_dai_drv->capture;
|
2013-11-27 08:58:18 +00:00
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
/* first calculate min/max only for CODECs in the DAI link */
|
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
2015-08-24 12:16:51 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip CODECs which don't support the current stream type.
|
|
|
|
* Otherwise, since the rate, channel, and format values will
|
|
|
|
* zero in that case, we would have no usable settings left,
|
|
|
|
* causing the resulting setup to fail.
|
|
|
|
* At least one CODEC should match, otherwise we should have
|
|
|
|
* bailed out on a higher level, since there would be no
|
|
|
|
* CODEC to support the transfer direction in that case.
|
|
|
|
*/
|
|
|
|
if (!snd_soc_dai_stream_valid(rtd->codec_dais[i],
|
|
|
|
substream->stream))
|
|
|
|
continue;
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
codec_dai_drv = rtd->codec_dais[i]->driver;
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
codec_stream = &codec_dai_drv->playback;
|
|
|
|
else
|
|
|
|
codec_stream = &codec_dai_drv->capture;
|
|
|
|
chan_min = max(chan_min, codec_stream->channels_min);
|
|
|
|
chan_max = min(chan_max, codec_stream->channels_max);
|
|
|
|
rate_min = max(rate_min, codec_stream->rate_min);
|
|
|
|
rate_max = min_not_zero(rate_max, codec_stream->rate_max);
|
|
|
|
formats &= codec_stream->formats;
|
|
|
|
rates = snd_pcm_rate_mask_intersect(codec_stream->rates, rates);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* chan min/max cannot be enforced if there are multiple CODEC DAIs
|
|
|
|
* connected to a single CPU DAI, use CPU DAI's directly and let
|
|
|
|
* channel allocation be fixed up later
|
|
|
|
*/
|
|
|
|
if (rtd->num_codecs > 1) {
|
|
|
|
chan_min = cpu_stream->channels_min;
|
|
|
|
chan_max = cpu_stream->channels_max;
|
|
|
|
}
|
|
|
|
|
|
|
|
hw->channels_min = max(chan_min, cpu_stream->channels_min);
|
|
|
|
hw->channels_max = min(chan_max, cpu_stream->channels_max);
|
|
|
|
if (hw->formats)
|
|
|
|
hw->formats &= formats & cpu_stream->formats;
|
|
|
|
else
|
|
|
|
hw->formats = formats & cpu_stream->formats;
|
|
|
|
hw->rates = snd_pcm_rate_mask_intersect(rates, cpu_stream->rates);
|
2013-11-27 08:58:18 +00:00
|
|
|
|
|
|
|
snd_pcm_limit_hw_rates(runtime);
|
|
|
|
|
|
|
|
hw->rate_min = max(hw->rate_min, cpu_stream->rate_min);
|
2014-07-08 21:19:35 +00:00
|
|
|
hw->rate_min = max(hw->rate_min, rate_min);
|
2013-11-27 08:58:18 +00:00
|
|
|
hw->rate_max = min_not_zero(hw->rate_max, cpu_stream->rate_max);
|
2014-07-08 21:19:35 +00:00
|
|
|
hw->rate_max = min_not_zero(hw->rate_max, rate_max);
|
2013-05-14 09:05:31 +00:00
|
|
|
}
|
|
|
|
|
2018-06-19 15:22:09 +00:00
|
|
|
static int soc_pcm_components_close(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_soc_component *last)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
|
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (component == last)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->close)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
component->driver->ops->close(substream);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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
|
2018-04-24 15:39:02 +00:00
|
|
|
* startup for the cpu DAI, component, machine and codec DAI.
|
2011-06-09 13:45:53 +00:00
|
|
|
*/
|
|
|
|
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;
|
2017-08-08 06:18:10 +00:00
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
2011-06-09 13:45:53 +00:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
const char *codec_dai_name = "multicodec";
|
2018-06-19 15:22:09 +00:00
|
|
|
int i, ret = 0;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
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);
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
pinctrl_pm_select_default_state(rtd->codec_dais[i]->dev);
|
2017-08-08 06:18:10 +00:00
|
|
|
|
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
pm_runtime_get_sync(component->dev);
|
|
|
|
}
|
2011-12-03 20:14:31 +00:00
|
|
|
|
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 */
|
2017-09-25 01:38:54 +00:00
|
|
|
if (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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->open)
|
|
|
|
continue;
|
|
|
|
|
2018-06-19 15:22:09 +00:00
|
|
|
ret = component->driver->ops->open(substream);
|
|
|
|
if (ret < 0) {
|
2017-10-11 01:37:23 +00:00
|
|
|
dev_err(component->dev,
|
|
|
|
"ASoC: can't open component %s: %d\n",
|
2018-06-19 15:22:09 +00:00
|
|
|
component->name, ret);
|
|
|
|
goto component_err;
|
2017-10-11 01:37:23 +00:00
|
|
|
}
|
|
|
|
}
|
2018-06-19 15:22:09 +00:00
|
|
|
component = NULL;
|
2017-10-11 01:37:23 +00:00
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
2017-09-25 01:38:54 +00:00
|
|
|
if (codec_dai->driver->ops->startup) {
|
2014-07-08 21:19:35 +00:00
|
|
|
ret = codec_dai->driver->ops->startup(substream,
|
|
|
|
codec_dai);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(codec_dai->dev,
|
|
|
|
"ASoC: can't open codec %s: %d\n",
|
|
|
|
codec_dai->name, ret);
|
|
|
|
goto codec_dai_err;
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
2014-07-08 21:19:35 +00:00
|
|
|
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
codec_dai->tx_mask = 0;
|
|
|
|
else
|
|
|
|
codec_dai->rx_mask = 0;
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
2017-09-26 00:40:42 +00:00
|
|
|
if (rtd->dai_link->ops->startup) {
|
2011-06-09 13:45:53 +00:00
|
|
|
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 */
|
2014-07-08 21:19:35 +00:00
|
|
|
soc_pcm_init_runtime_hw(substream);
|
|
|
|
|
|
|
|
if (rtd->num_codecs == 1)
|
|
|
|
codec_dai_name = rtd->codec_dai->name;
|
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;
|
|
|
|
if (!runtime->hw.rates) {
|
2012-11-19 14:39:15 +00:00
|
|
|
printk(KERN_ERR "ASoC: %s <-> %s No matching rates\n",
|
2014-07-08 21:19:35 +00:00
|
|
|
codec_dai_name, cpu_dai->name);
|
2011-06-09 13:45:53 +00:00
|
|
|
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",
|
2014-07-08 21:19:35 +00:00
|
|
|
codec_dai_name, cpu_dai->name);
|
2011-06-09 13:45:53 +00:00
|
|
|
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",
|
2014-07-08 21:19:35 +00:00
|
|
|
codec_dai_name, cpu_dai->name);
|
2011-06-09 13:45:53 +00:00
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
|
2014-07-01 07:47:55 +00:00
|
|
|
soc_pcm_apply_msb(substream);
|
2012-01-16 18:38:51 +00:00
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
if (rtd->codec_dais[i]->active) {
|
|
|
|
ret = soc_pcm_apply_symmetry(substream,
|
|
|
|
rtd->codec_dais[i]);
|
|
|
|
if (ret != 0)
|
|
|
|
goto config_err;
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
pr_debug("ASoC: %s <-> %s info:\n",
|
2014-07-08 21:19:35 +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:
|
2014-03-05 12:17:43 +00:00
|
|
|
|
|
|
|
snd_soc_runtime_activate(rtd, substream->stream);
|
|
|
|
|
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:
|
2017-09-26 00:40:42 +00:00
|
|
|
if (rtd->dai_link->ops->shutdown)
|
2011-06-09 13:45:53 +00:00
|
|
|
rtd->dai_link->ops->shutdown(substream);
|
|
|
|
|
|
|
|
machine_err:
|
2014-07-08 21:19:35 +00:00
|
|
|
i = rtd->num_codecs;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
codec_dai_err:
|
2014-07-08 21:19:35 +00:00
|
|
|
while (--i >= 0) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
|
|
|
if (codec_dai->driver->ops->shutdown)
|
|
|
|
codec_dai->driver->ops->shutdown(substream, codec_dai);
|
|
|
|
}
|
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
component_err:
|
2018-06-19 15:22:09 +00:00
|
|
|
soc_pcm_components_close(substream, component);
|
2017-10-11 01:37:23 +00:00
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
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
|
|
|
|
2017-08-08 06:18:10 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
pm_runtime_mark_last_busy(component->dev);
|
|
|
|
pm_runtime_put_autosuspend(component->dev);
|
2016-01-05 11:44:49 +00:00
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
if (!rtd->codec_dais[i]->active)
|
|
|
|
pinctrl_pm_select_sleep_state(rtd->codec_dais[i]->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 (!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);
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dais[0];
|
2011-06-09 13:45:53 +00:00
|
|
|
|
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
|
2018-04-24 15:39:02 +00:00
|
|
|
* freed here. The cpu DAI, codec DAI, machine and components are also
|
2011-06-09 13:45:53 +00:00
|
|
|
* 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;
|
2017-08-08 06:18:10 +00:00
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
2011-06-09 13:45:53 +00:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
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
|
|
|
|
2014-03-05 12:17:43 +00:00
|
|
|
snd_soc_runtime_deactivate(rtd, substream->stream);
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2011-08-29 09:15:14 +00:00
|
|
|
/* clear the corresponding DAIs rate when inactive */
|
|
|
|
if (!cpu_dai->active)
|
|
|
|
cpu_dai->rate = 0;
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
|
|
|
if (!codec_dai->active)
|
|
|
|
codec_dai->rate = 0;
|
|
|
|
}
|
2011-08-17 07:20:01 +00:00
|
|
|
|
2014-10-15 07:04:59 +00:00
|
|
|
snd_soc_dai_digital_mute(cpu_dai, 1, substream->stream);
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
if (cpu_dai->driver->ops->shutdown)
|
|
|
|
cpu_dai->driver->ops->shutdown(substream, cpu_dai);
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
|
|
|
if (codec_dai->driver->ops->shutdown)
|
|
|
|
codec_dai->driver->ops->shutdown(substream, codec_dai);
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2017-09-26 00:40:42 +00:00
|
|
|
if (rtd->dai_link->ops->shutdown)
|
2011-06-09 13:45:53 +00:00
|
|
|
rtd->dai_link->ops->shutdown(substream);
|
|
|
|
|
2018-06-19 15:22:09 +00:00
|
|
|
soc_pcm_components_close(substream, NULL);
|
2017-10-11 01:37:23 +00:00
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
2014-03-05 12:17:42 +00:00
|
|
|
if (snd_soc_runtime_ignore_pmdown_time(rtd)) {
|
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
|
|
|
|
2017-08-08 06:18:10 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
2016-01-05 11:44:49 +00:00
|
|
|
|
2017-08-08 06:18:10 +00:00
|
|
|
pm_runtime_mark_last_busy(component->dev);
|
|
|
|
pm_runtime_put_autosuspend(component->dev);
|
2016-01-05 11:44:49 +00:00
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
if (!rtd->codec_dais[i]->active)
|
|
|
|
pinctrl_pm_select_sleep_state(rtd->codec_dais[i]->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 (!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;
|
2017-10-11 01:37:23 +00:00
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
2011-06-09 13:45:53 +00:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i, ret = 0;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
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
|
|
|
|
2017-09-26 00:40:42 +00:00
|
|
|
if (rtd->dai_link->ops->prepare) {
|
2011-06-09 13:45:53 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->prepare)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = component->driver->ops->prepare(substream);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(component->dev,
|
|
|
|
"ASoC: platform prepare error: %d\n", ret);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
2017-09-25 01:38:54 +00:00
|
|
|
if (codec_dai->driver->ops->prepare) {
|
2014-07-08 21:19:35 +00:00
|
|
|
ret = codec_dai->driver->ops->prepare(substream,
|
|
|
|
codec_dai);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(codec_dai->dev,
|
2014-12-23 09:04:41 +00:00
|
|
|
"ASoC: codec DAI prepare error: %d\n",
|
|
|
|
ret);
|
2014-07-08 21:19:35 +00:00
|
|
|
goto out;
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-09-25 01:38:54 +00:00
|
|
|
if (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) {
|
2014-12-23 09:04:41 +00:00
|
|
|
dev_err(cpu_dai->dev,
|
|
|
|
"ASoC: cpu DAI prepare error: %d\n", 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
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++)
|
|
|
|
snd_soc_dai_digital_mute(rtd->codec_dais[i], 0,
|
|
|
|
substream->stream);
|
2014-10-15 07:04:59 +00:00
|
|
|
snd_soc_dai_digital_mute(cpu_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;
|
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
static void soc_pcm_codec_params_fixup(struct snd_pcm_hw_params *params,
|
|
|
|
unsigned int mask)
|
|
|
|
{
|
|
|
|
struct snd_interval *interval;
|
|
|
|
int channels = hweight_long(mask);
|
|
|
|
|
|
|
|
interval = hw_param_interval(params, SNDRV_PCM_HW_PARAM_CHANNELS);
|
|
|
|
interval->min = channels;
|
|
|
|
interval->max = channels;
|
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:38 +00:00
|
|
|
int soc_dai_hw_params(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_pcm_hw_params *params,
|
|
|
|
struct snd_soc_dai *dai)
|
|
|
|
{
|
2018-07-02 15:59:54 +00:00
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
2014-07-08 21:19:38 +00:00
|
|
|
int ret;
|
|
|
|
|
2018-07-02 15:59:54 +00:00
|
|
|
/* perform any topology hw_params fixups before DAI */
|
|
|
|
if (rtd->dai_link->be_hw_params_fixup) {
|
|
|
|
ret = rtd->dai_link->be_hw_params_fixup(rtd, params);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(rtd->dev,
|
|
|
|
"ASoC: hw_params topology fixup failed %d\n",
|
|
|
|
ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-09-25 01:38:54 +00:00
|
|
|
if (dai->driver->ops->hw_params) {
|
2014-07-08 21:19:38 +00:00
|
|
|
ret = dai->driver->ops->hw_params(substream, params, dai);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dai->dev, "ASoC: can't set %s hw params: %d\n",
|
|
|
|
dai->name, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-06-19 15:22:09 +00:00
|
|
|
static int soc_pcm_components_hw_free(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_soc_component *last)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
|
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (component == last)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->hw_free)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
component->driver->ops->hw_free(substream);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
/*
|
|
|
|
* 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;
|
2017-10-11 01:37:23 +00:00
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
2011-06-09 13:45:53 +00:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2018-06-19 15:22:09 +00:00
|
|
|
int i, ret = 0;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2011-06-09 16:04:39 +00:00
|
|
|
mutex_lock_nested(&rtd->pcm_mutex, rtd->pcm_subclass);
|
2017-09-26 00:40:42 +00:00
|
|
|
if (rtd->dai_link->ops->hw_params) {
|
2011-06-09 13:45:53 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dais[i];
|
|
|
|
struct snd_pcm_hw_params codec_params;
|
|
|
|
|
2015-08-24 12:16:51 +00:00
|
|
|
/*
|
|
|
|
* Skip CODECs which don't support the current stream type,
|
|
|
|
* the idea being that if a CODEC is not used for the currently
|
|
|
|
* set up transfer direction, it should not need to be
|
|
|
|
* configured, especially since the configuration used might
|
|
|
|
* not even be supported by that CODEC. There may be cases
|
|
|
|
* however where a CODEC needs to be set up although it is
|
|
|
|
* actually not being used for the transfer, e.g. if a
|
|
|
|
* capture-only CODEC is acting as an LRCLK and/or BCLK master
|
|
|
|
* for the DAI link including a playback-only CODEC.
|
|
|
|
* If this becomes necessary, we will have to augment the
|
|
|
|
* machine driver setup with information on how to act, so
|
|
|
|
* we can do the right thing here.
|
|
|
|
*/
|
|
|
|
if (!snd_soc_dai_stream_valid(codec_dai, substream->stream))
|
|
|
|
continue;
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
/* copy params for each codec */
|
|
|
|
codec_params = *params;
|
|
|
|
|
|
|
|
/* fixup params based on TDM slot masks */
|
|
|
|
if (codec_dai->tx_mask)
|
|
|
|
soc_pcm_codec_params_fixup(&codec_params,
|
|
|
|
codec_dai->tx_mask);
|
|
|
|
if (codec_dai->rx_mask)
|
|
|
|
soc_pcm_codec_params_fixup(&codec_params,
|
|
|
|
codec_dai->rx_mask);
|
|
|
|
|
2014-07-08 21:19:38 +00:00
|
|
|
ret = soc_dai_hw_params(substream, &codec_params, codec_dai);
|
|
|
|
if(ret < 0)
|
2011-06-09 13:45:53 +00:00
|
|
|
goto codec_err;
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
codec_dai->rate = params_rate(&codec_params);
|
|
|
|
codec_dai->channels = params_channels(&codec_params);
|
|
|
|
codec_dai->sample_bits = snd_pcm_format_physical_width(
|
|
|
|
params_format(&codec_params));
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:38 +00:00
|
|
|
ret = soc_dai_hw_params(substream, params, cpu_dai);
|
|
|
|
if (ret < 0)
|
|
|
|
goto interface_err;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->hw_params)
|
|
|
|
continue;
|
|
|
|
|
2018-06-19 15:22:09 +00:00
|
|
|
ret = component->driver->ops->hw_params(substream, params);
|
|
|
|
if (ret < 0) {
|
2017-10-11 01:37:23 +00:00
|
|
|
dev_err(component->dev,
|
|
|
|
"ASoC: %s hw params failed: %d\n",
|
2018-06-19 15:22:09 +00:00
|
|
|
component->name, ret);
|
|
|
|
goto component_err;
|
2017-10-11 01:37:23 +00:00
|
|
|
}
|
|
|
|
}
|
2018-06-19 15:22:09 +00:00
|
|
|
component = NULL;
|
2017-10-11 01:37:23 +00:00
|
|
|
|
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));
|
|
|
|
|
2017-09-20 06:25:30 +00:00
|
|
|
ret = soc_pcm_params_symmetry(substream, params);
|
|
|
|
if (ret)
|
2017-10-11 01:37:23 +00:00
|
|
|
goto component_err;
|
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;
|
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
component_err:
|
2018-06-19 15:22:09 +00:00
|
|
|
soc_pcm_components_hw_free(substream, component);
|
2017-10-11 01:37:23 +00:00
|
|
|
|
2017-09-25 01:38:54 +00:00
|
|
|
if (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:
|
2014-07-08 21:19:35 +00:00
|
|
|
i = rtd->num_codecs;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
codec_err:
|
2014-07-08 21:19:35 +00:00
|
|
|
while (--i >= 0) {
|
|
|
|
struct snd_soc_dai *codec_dai = rtd->codec_dais[i];
|
2017-09-25 01:38:54 +00:00
|
|
|
if (codec_dai->driver->ops->hw_free)
|
2014-07-08 21:19:35 +00:00
|
|
|
codec_dai->driver->ops->hw_free(substream, codec_dai);
|
|
|
|
codec_dai->rate = 0;
|
|
|
|
}
|
|
|
|
|
2017-09-26 00:40:42 +00:00
|
|
|
if (rtd->dai_link->ops->hw_free)
|
2011-06-09 13:45:53 +00:00
|
|
|
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_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2013-12-04 03:18:36 +00:00
|
|
|
bool playback = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
|
2014-07-08 21:19:35 +00:00
|
|
|
int i;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
|
|
|
if (codec_dai->active == 1) {
|
|
|
|
codec_dai->rate = 0;
|
|
|
|
codec_dai->channels = 0;
|
|
|
|
codec_dai->sample_bits = 0;
|
|
|
|
}
|
2013-11-20 10:37:09 +00:00
|
|
|
}
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
/* apply codec digital mute */
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
if ((playback && rtd->codec_dais[i]->playback_active == 1) ||
|
|
|
|
(!playback && rtd->codec_dais[i]->capture_active == 1))
|
|
|
|
snd_soc_dai_digital_mute(rtd->codec_dais[i], 1,
|
|
|
|
substream->stream);
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
/* free any machine hw params */
|
2017-09-26 00:40:42 +00:00
|
|
|
if (rtd->dai_link->ops->hw_free)
|
2011-06-09 13:45:53 +00:00
|
|
|
rtd->dai_link->ops->hw_free(substream);
|
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
/* free any component resources */
|
2018-06-19 15:22:09 +00:00
|
|
|
soc_pcm_components_hw_free(substream, NULL);
|
2017-10-11 01:37:23 +00:00
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
/* now free hw params for the DAIs */
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
2017-09-25 01:38:54 +00:00
|
|
|
if (codec_dai->driver->ops->hw_free)
|
2014-07-08 21:19:35 +00:00
|
|
|
codec_dai->driver->ops->hw_free(substream, codec_dai);
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2017-09-25 01:38:54 +00:00
|
|
|
if (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;
|
2017-10-11 01:37:23 +00:00
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
2011-06-09 13:45:53 +00:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i, ret;
|
|
|
|
|
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
2017-09-25 01:38:54 +00:00
|
|
|
if (codec_dai->driver->ops->trigger) {
|
2014-07-08 21:19:35 +00:00
|
|
|
ret = codec_dai->driver->ops->trigger(substream,
|
|
|
|
cmd, codec_dai);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->trigger)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = component->driver->ops->trigger(substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-09-25 01:38:54 +00:00
|
|
|
if (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;
|
|
|
|
}
|
2014-04-28 12:17:52 +00:00
|
|
|
|
2017-09-26 00:40:42 +00:00
|
|
|
if (rtd->dai_link->ops->trigger) {
|
2014-04-28 12:17:52 +00:00
|
|
|
ret = rtd->dai_link->ops->trigger(substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
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_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i, ret;
|
|
|
|
|
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
2017-09-25 01:38:54 +00:00
|
|
|
if (codec_dai->driver->ops->bespoke_trigger) {
|
2014-07-08 21:19:35 +00:00
|
|
|
ret = codec_dai->driver->ops->bespoke_trigger(substream,
|
|
|
|
cmd, codec_dai);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
2012-04-25 11:12:52 +00:00
|
|
|
}
|
|
|
|
|
2017-09-25 01:38:54 +00:00
|
|
|
if (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
|
2018-04-24 15:39:02 +00:00
|
|
|
* If cpu_dai, codec_dai, component driver has the delay callback, then
|
2011-06-09 13:45:53 +00:00
|
|
|
* 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;
|
2017-10-11 01:37:23 +00:00
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
2011-06-09 13:45:53 +00:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2011-06-09 13:45:53 +00:00
|
|
|
struct snd_pcm_runtime *runtime = substream->runtime;
|
|
|
|
snd_pcm_uframes_t offset = 0;
|
|
|
|
snd_pcm_sframes_t delay = 0;
|
2014-07-08 21:19:35 +00:00
|
|
|
snd_pcm_sframes_t codec_delay = 0;
|
|
|
|
int i;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
2018-08-01 10:07:33 +00:00
|
|
|
/* clearing the previous total delay */
|
|
|
|
runtime->delay = 0;
|
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->pointer)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* FIXME: use 1st pointer */
|
|
|
|
offset = component->driver->ops->pointer(substream);
|
|
|
|
break;
|
|
|
|
}
|
2018-08-01 10:07:33 +00:00
|
|
|
/* base delay if assigned in pointer callback */
|
|
|
|
delay = runtime->delay;
|
2017-10-11 01:37:23 +00:00
|
|
|
|
2017-09-25 01:38:54 +00:00
|
|
|
if (cpu_dai->driver->ops->delay)
|
2011-06-09 13:45:53 +00:00
|
|
|
delay += cpu_dai->driver->ops->delay(substream, cpu_dai);
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
2017-09-25 01:38:54 +00:00
|
|
|
if (codec_dai->driver->ops->delay)
|
2014-07-08 21:19:35 +00:00
|
|
|
codec_delay = max(codec_delay,
|
|
|
|
codec_dai->driver->ops->delay(substream,
|
|
|
|
codec_dai));
|
|
|
|
}
|
|
|
|
delay += codec_delay;
|
2011-06-09 13:45:53 +00:00
|
|
|
|
|
|
|
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
|
2015-04-09 08:52:38 +00:00
|
|
|
if (fe->debugfs_dpcm_root)
|
|
|
|
dpcm->debugfs_state = debugfs_create_u32(be->dai_link->name, 0644,
|
|
|
|
fe->debugfs_dpcm_root, &dpcm->state);
|
2012-04-25 11:12:50 +00:00
|
|
|
#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 */
|
2014-01-17 17:03:55 +00:00
|
|
|
void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream)
|
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, *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;
|
2015-11-18 07:34:11 +00:00
|
|
|
int i;
|
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
|
|
|
|
2018-03-14 20:43:51 +00:00
|
|
|
dev_dbg(card->dev, "ASoC: find BE for widget %s\n", widget->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
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
2015-11-18 07:34:11 +00:00
|
|
|
list_for_each_entry(be, &card->rtd_list, list) {
|
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-06-05 18:26:59 +00:00
|
|
|
if (!be->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
2018-03-14 20:43:51 +00:00
|
|
|
dev_dbg(card->dev, "ASoC: try BE : %s\n",
|
|
|
|
be->cpu_dai->playback_widget ?
|
|
|
|
be->cpu_dai->playback_widget->name : "(not set)");
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
if (be->cpu_dai->playback_widget == widget)
|
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 be;
|
2014-07-08 21:19:35 +00:00
|
|
|
|
2015-11-18 07:34:11 +00:00
|
|
|
for (i = 0; i < be->num_codecs; i++) {
|
|
|
|
struct snd_soc_dai *dai = be->codec_dais[i];
|
2014-07-08 21:19:35 +00:00
|
|
|
if (dai->playback_widget == widget)
|
|
|
|
return be;
|
|
|
|
}
|
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 {
|
|
|
|
|
2015-11-18 07:34:11 +00:00
|
|
|
list_for_each_entry(be, &card->rtd_list, list) {
|
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-06-05 18:26:59 +00:00
|
|
|
if (!be->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
2018-03-14 20:43:51 +00:00
|
|
|
dev_dbg(card->dev, "ASoC: try BE %s\n",
|
|
|
|
be->cpu_dai->capture_widget ?
|
|
|
|
be->cpu_dai->capture_widget->name : "(not set)");
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
if (be->cpu_dai->capture_widget == widget)
|
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 be;
|
2014-07-08 21:19:35 +00:00
|
|
|
|
2015-11-18 07:34:11 +00:00
|
|
|
for (i = 0; i < be->num_codecs; i++) {
|
|
|
|
struct snd_soc_dai *dai = be->codec_dais[i];
|
2014-07-08 21:19:35 +00:00
|
|
|
if (dai->capture_widget == widget)
|
|
|
|
return be;
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-14 20:43:51 +00:00
|
|
|
/* dai link name and stream name set correctly ? */
|
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 *
|
2014-04-24 12:01:45 +00:00
|
|
|
dai_get_widget(struct snd_soc_dai *dai, int stream)
|
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 (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
2014-04-24 12:01:45 +00:00
|
|
|
return dai->playback_widget;
|
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
|
2014-04-24 12:01:45 +00:00
|
|
|
return dai->capture_widget;
|
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 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;
|
|
|
|
}
|
|
|
|
|
2016-05-13 16:03:56 +00:00
|
|
|
static bool dpcm_end_walk_at_be(struct snd_soc_dapm_widget *widget,
|
|
|
|
enum snd_soc_dapm_direction dir)
|
|
|
|
{
|
|
|
|
struct snd_soc_card *card = widget->dapm->card;
|
|
|
|
struct snd_soc_pcm_runtime *rtd;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (dir == SND_SOC_DAPM_DIR_OUT) {
|
|
|
|
list_for_each_entry(rtd, &card->rtd_list, list) {
|
|
|
|
if (!rtd->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (rtd->cpu_dai->playback_widget == widget)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
for (i = 0; i < rtd->num_codecs; ++i) {
|
|
|
|
struct snd_soc_dai *dai = rtd->codec_dais[i];
|
|
|
|
if (dai->playback_widget == widget)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else { /* SND_SOC_DAPM_DIR_IN */
|
|
|
|
list_for_each_entry(rtd, &card->rtd_list, list) {
|
|
|
|
if (!rtd->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (rtd->cpu_dai->capture_widget == widget)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
for (i = 0; i < rtd->num_codecs; ++i) {
|
|
|
|
struct snd_soc_dai *dai = rtd->codec_dais[i];
|
|
|
|
if (dai->capture_widget == widget)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-01-17 17:03:55 +00:00
|
|
|
int dpcm_path_get(struct snd_soc_pcm_runtime *fe,
|
2015-07-26 17:04:59 +00:00
|
|
|
int stream, struct snd_soc_dapm_widget_list **list)
|
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_dai *cpu_dai = fe->cpu_dai;
|
|
|
|
int paths;
|
|
|
|
|
|
|
|
/* get number of valid DAI paths and their widgets */
|
2016-05-13 16:03:55 +00:00
|
|
|
paths = snd_soc_dapm_dai_get_connected_widgets(cpu_dai, stream, list,
|
2016-05-13 16:03:56 +00:00
|
|
|
dpcm_end_walk_at_be);
|
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-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");
|
|
|
|
|
|
|
|
return paths;
|
|
|
|
}
|
|
|
|
|
|
|
|
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) {
|
2014-07-08 21:19:35 +00:00
|
|
|
unsigned int i;
|
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 CPU DAI widget for this BE */
|
2014-04-24 12:01:45 +00:00
|
|
|
widget = dai_get_widget(dpcm->be->cpu_dai, stream);
|
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
|
|
|
|
|
|
|
/* 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 */
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < dpcm->be->num_codecs; i++) {
|
|
|
|
struct snd_soc_dai *dai = dpcm->be->codec_dais[i];
|
|
|
|
widget = dai_get_widget(dai, stream);
|
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
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
/* prune the BE if it's no longer in our active list */
|
|
|
|
if (widget && widget_in_list(list, widget))
|
|
|
|
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
|
|
|
|
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:
|
2015-07-06 02:02:10 +00:00
|
|
|
if (stream != SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
continue;
|
|
|
|
break;
|
2013-06-05 18:36:11 +00:00
|
|
|
case snd_soc_dapm_dai_out:
|
2015-07-06 02:02:10 +00:00
|
|
|
if (stream != SNDRV_PCM_STREAM_CAPTURE)
|
|
|
|
continue;
|
2013-06-05 18:36:11 +00:00
|
|
|
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 */
|
2014-01-17 17:03:55 +00:00
|
|
|
if (!fe->dpcm[stream].runtime && !fe->fe_compr)
|
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;
|
|
|
|
|
|
|
|
/* 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.
|
|
|
|
*/
|
2014-01-17 17:03:55 +00:00
|
|
|
int dpcm_process_paths(struct snd_soc_pcm_runtime *fe,
|
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 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);
|
|
|
|
}
|
|
|
|
|
2014-01-17 17:03:55 +00:00
|
|
|
void dpcm_clear_pending_state(struct snd_soc_pcm_runtime *fe, int stream)
|
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;
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-17 17:03:55 +00:00
|
|
|
int dpcm_be_dai_startup(struct snd_soc_pcm_runtime *fe, int stream)
|
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 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,
|
2018-07-05 10:13:48 +00:00
|
|
|
struct snd_soc_pcm_stream *stream)
|
2014-01-06 13:19:06 +00:00
|
|
|
{
|
|
|
|
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)
|
2018-07-05 10:13:48 +00:00
|
|
|
runtime->hw.formats &= stream->formats;
|
2014-01-06 13:19:07 +00:00
|
|
|
else
|
2018-07-05 10:13:48 +00:00
|
|
|
runtime->hw.formats = stream->formats;
|
2014-01-06 13:19:06 +00:00
|
|
|
runtime->hw.rates = stream->rates;
|
|
|
|
}
|
|
|
|
|
2018-07-05 10:13:48 +00:00
|
|
|
static void dpcm_runtime_merge_format(struct snd_pcm_substream *substream,
|
|
|
|
u64 *formats)
|
2015-05-12 02:03:33 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int stream = substream->stream;
|
|
|
|
|
|
|
|
if (!fe->dai_link->dpcm_merged_format)
|
2018-07-05 10:13:48 +00:00
|
|
|
return;
|
2015-05-12 02:03:33 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* It returns merged BE codec format
|
|
|
|
* if FE want to use it (= dpcm_merged_format)
|
|
|
|
*/
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_soc_dai_driver *codec_dai_drv;
|
|
|
|
struct snd_soc_pcm_stream *codec_stream;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < be->num_codecs; i++) {
|
2018-06-27 15:36:38 +00:00
|
|
|
/*
|
|
|
|
* Skip CODECs which don't support the current stream
|
|
|
|
* type. See soc_pcm_init_runtime_hw() for more details
|
|
|
|
*/
|
|
|
|
if (!snd_soc_dai_stream_valid(be->codec_dais[i],
|
|
|
|
stream))
|
|
|
|
continue;
|
|
|
|
|
2015-05-12 02:03:33 +00:00
|
|
|
codec_dai_drv = be->codec_dais[i]->driver;
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
codec_stream = &codec_dai_drv->playback;
|
|
|
|
else
|
|
|
|
codec_stream = &codec_dai_drv->capture;
|
|
|
|
|
2018-07-05 10:13:48 +00:00
|
|
|
*formats &= codec_stream->formats;
|
2015-05-12 02:03:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-07-05 10:13:48 +00:00
|
|
|
static void dpcm_runtime_merge_chan(struct snd_pcm_substream *substream,
|
|
|
|
unsigned int *channels_min,
|
|
|
|
unsigned int *channels_max)
|
2018-06-20 09:25:20 +00:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int stream = substream->stream;
|
|
|
|
|
|
|
|
if (!fe->dai_link->dpcm_merged_chan)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It returns merged BE codec channel;
|
|
|
|
* if FE want to use it (= dpcm_merged_chan)
|
|
|
|
*/
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
2018-06-27 09:48:18 +00:00
|
|
|
struct snd_soc_dai_driver *cpu_dai_drv = be->cpu_dai->driver;
|
2018-06-20 09:25:20 +00:00
|
|
|
struct snd_soc_dai_driver *codec_dai_drv;
|
|
|
|
struct snd_soc_pcm_stream *codec_stream;
|
2018-06-27 09:48:18 +00:00
|
|
|
struct snd_soc_pcm_stream *cpu_stream;
|
|
|
|
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
cpu_stream = &cpu_dai_drv->playback;
|
|
|
|
else
|
|
|
|
cpu_stream = &cpu_dai_drv->capture;
|
|
|
|
|
|
|
|
*channels_min = max(*channels_min, cpu_stream->channels_min);
|
|
|
|
*channels_max = min(*channels_max, cpu_stream->channels_max);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* chan min/max cannot be enforced if there are multiple CODEC
|
|
|
|
* DAIs connected to a single CPU DAI, use CPU DAI's directly
|
|
|
|
*/
|
|
|
|
if (be->num_codecs == 1) {
|
|
|
|
codec_dai_drv = be->codec_dais[0]->driver;
|
2018-06-20 09:25:20 +00:00
|
|
|
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
codec_stream = &codec_dai_drv->playback;
|
|
|
|
else
|
|
|
|
codec_stream = &codec_dai_drv->capture;
|
|
|
|
|
|
|
|
*channels_min = max(*channels_min,
|
|
|
|
codec_stream->channels_min);
|
|
|
|
*channels_max = min(*channels_max,
|
|
|
|
codec_stream->channels_max);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-07-05 10:13:49 +00:00
|
|
|
static void dpcm_runtime_merge_rate(struct snd_pcm_substream *substream,
|
|
|
|
unsigned int *rates,
|
|
|
|
unsigned int *rate_min,
|
|
|
|
unsigned int *rate_max)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int stream = substream->stream;
|
|
|
|
|
|
|
|
if (!fe->dai_link->dpcm_merged_rate)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It returns merged BE codec channel;
|
|
|
|
* if FE want to use it (= dpcm_merged_chan)
|
|
|
|
*/
|
|
|
|
|
|
|
|
list_for_each_entry(dpcm, &fe->dpcm[stream].be_clients, list_be) {
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_soc_dai_driver *cpu_dai_drv = be->cpu_dai->driver;
|
|
|
|
struct snd_soc_dai_driver *codec_dai_drv;
|
|
|
|
struct snd_soc_pcm_stream *codec_stream;
|
|
|
|
struct snd_soc_pcm_stream *cpu_stream;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
cpu_stream = &cpu_dai_drv->playback;
|
|
|
|
else
|
|
|
|
cpu_stream = &cpu_dai_drv->capture;
|
|
|
|
|
|
|
|
*rate_min = max(*rate_min, cpu_stream->rate_min);
|
|
|
|
*rate_max = min_not_zero(*rate_max, cpu_stream->rate_max);
|
|
|
|
*rates = snd_pcm_rate_mask_intersect(*rates, cpu_stream->rates);
|
|
|
|
|
|
|
|
for (i = 0; i < be->num_codecs; i++) {
|
|
|
|
/*
|
|
|
|
* Skip CODECs which don't support the current stream
|
|
|
|
* type. See soc_pcm_init_runtime_hw() for more details
|
|
|
|
*/
|
|
|
|
if (!snd_soc_dai_stream_valid(be->codec_dais[i],
|
|
|
|
stream))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
codec_dai_drv = be->codec_dais[i]->driver;
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
codec_stream = &codec_dai_drv->playback;
|
|
|
|
else
|
|
|
|
codec_stream = &codec_dai_drv->capture;
|
|
|
|
|
|
|
|
*rate_min = max(*rate_min, codec_stream->rate_min);
|
|
|
|
*rate_max = min_not_zero(*rate_max,
|
|
|
|
codec_stream->rate_max);
|
|
|
|
*rates = snd_pcm_rate_mask_intersect(*rates,
|
|
|
|
codec_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)
|
2018-07-05 10:13:48 +00:00
|
|
|
dpcm_init_runtime_hw(runtime, &cpu_dai_drv->playback);
|
2014-01-06 13:19:06 +00:00
|
|
|
else
|
2018-07-05 10:13:48 +00:00
|
|
|
dpcm_init_runtime_hw(runtime, &cpu_dai_drv->capture);
|
2018-06-20 09:25:20 +00:00
|
|
|
|
2018-07-05 10:13:48 +00:00
|
|
|
dpcm_runtime_merge_format(substream, &runtime->hw.formats);
|
|
|
|
dpcm_runtime_merge_chan(substream, &runtime->hw.channels_min,
|
|
|
|
&runtime->hw.channels_max);
|
2018-07-05 10:13:49 +00:00
|
|
|
dpcm_runtime_merge_rate(substream, &runtime->hw.rates,
|
|
|
|
&runtime->hw.rate_min, &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
|
|
|
}
|
|
|
|
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
static int dpcm_fe_dai_do_trigger(struct snd_pcm_substream *substream, int cmd);
|
|
|
|
|
|
|
|
/* Set FE's runtime_update state; the state is protected via PCM stream lock
|
|
|
|
* for avoiding the race with trigger callback.
|
|
|
|
* If the state is unset and a trigger is pending while the previous operation,
|
|
|
|
* process the pending trigger action here.
|
|
|
|
*/
|
|
|
|
static void dpcm_set_fe_update_state(struct snd_soc_pcm_runtime *fe,
|
|
|
|
int stream, enum snd_soc_dpcm_update state)
|
|
|
|
{
|
|
|
|
struct snd_pcm_substream *substream =
|
|
|
|
snd_soc_dpcm_get_substream(fe, stream);
|
|
|
|
|
|
|
|
snd_pcm_stream_lock_irq(substream);
|
|
|
|
if (state == SND_SOC_DPCM_UPDATE_NO && fe->dpcm[stream].trigger_pending) {
|
|
|
|
dpcm_fe_dai_do_trigger(substream,
|
|
|
|
fe->dpcm[stream].trigger_pending - 1);
|
|
|
|
fe->dpcm[stream].trigger_pending = 0;
|
|
|
|
}
|
|
|
|
fe->dpcm[stream].runtime_update = state;
|
|
|
|
snd_pcm_stream_unlock_irq(substream);
|
|
|
|
}
|
|
|
|
|
2015-12-11 03:33:51 +00:00
|
|
|
static int dpcm_apply_symmetry(struct snd_pcm_substream *fe_substream,
|
|
|
|
int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
struct snd_soc_pcm_runtime *fe = fe_substream->private_data;
|
|
|
|
struct snd_soc_dai *fe_cpu_dai = fe->cpu_dai;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
/* apply symmetry for FE */
|
|
|
|
if (soc_pcm_has_symmetry(fe_substream))
|
|
|
|
fe_substream->runtime->hw.info |= SNDRV_PCM_INFO_JOINT_DUPLEX;
|
|
|
|
|
|
|
|
/* Symmetry only applies if we've got an active stream. */
|
|
|
|
if (fe_cpu_dai->active) {
|
|
|
|
err = soc_pcm_apply_symmetry(fe_substream, fe_cpu_dai);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* apply symmetry for BE */
|
|
|
|
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);
|
|
|
|
struct snd_soc_pcm_runtime *rtd = be_substream->private_data;
|
|
|
|
int i;
|
|
|
|
|
2016-09-06 08:47:55 +00:00
|
|
|
if (rtd->dai_link->be_hw_params_fixup)
|
|
|
|
continue;
|
|
|
|
|
2015-12-11 03:33:51 +00:00
|
|
|
if (soc_pcm_has_symmetry(be_substream))
|
|
|
|
be_substream->runtime->hw.info |= SNDRV_PCM_INFO_JOINT_DUPLEX;
|
|
|
|
|
|
|
|
/* Symmetry only applies if we've got an active stream. */
|
|
|
|
if (rtd->cpu_dai->active) {
|
2018-05-28 02:18:19 +00:00
|
|
|
err = soc_pcm_apply_symmetry(fe_substream,
|
|
|
|
rtd->cpu_dai);
|
2015-12-11 03:33:51 +00:00
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
if (rtd->codec_dais[i]->active) {
|
2018-05-28 02:18:19 +00:00
|
|
|
err = soc_pcm_apply_symmetry(fe_substream,
|
2015-12-11 03:33:51 +00:00
|
|
|
rtd->codec_dais[i]);
|
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
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;
|
|
|
|
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_FE);
|
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 = 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);
|
|
|
|
|
2015-12-11 03:33:51 +00:00
|
|
|
ret = dpcm_apply_symmetry(fe_substream, stream);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(fe->dev, "ASoC: failed to apply dpcm symmetry %d\n",
|
|
|
|
ret);
|
|
|
|
goto unwind;
|
|
|
|
}
|
|
|
|
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
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;
|
|
|
|
|
|
|
|
unwind:
|
|
|
|
dpcm_be_dai_startup_unwind(fe, fe_substream->stream);
|
|
|
|
be_err:
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
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;
|
|
|
|
}
|
|
|
|
|
2014-01-17 17:03:55 +00:00
|
|
|
int dpcm_be_dai_shutdown(struct snd_soc_pcm_runtime *fe, int stream)
|
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;
|
|
|
|
|
|
|
|
/* 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) &&
|
2018-05-28 02:18:18 +00:00
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_OPEN)) {
|
|
|
|
soc_pcm_hw_free(be_substream);
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_HW_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
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: close BE %s\n",
|
2016-09-26 08:29:31 +00:00
|
|
|
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
|
|
|
|
|
|
|
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;
|
|
|
|
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_FE);
|
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
|
|
|
|
|
|
|
/* 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;
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
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;
|
|
|
|
}
|
|
|
|
|
2014-01-17 17:03:55 +00:00
|
|
|
int dpcm_be_dai_hw_free(struct snd_soc_pcm_runtime *fe, int stream)
|
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;
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
|
2014-12-03 02:13:43 +00:00
|
|
|
/* do not free hw if this BE is used by other FE */
|
|
|
|
if (be->dpcm[stream].users > 1)
|
|
|
|
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->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) &&
|
2016-02-01 16:56:40 +00:00
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND))
|
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;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: hw_free BE %s\n",
|
2016-09-26 08:29:31 +00:00
|
|
|
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
|
|
|
|
|
|
|
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);
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_FE);
|
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-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;
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
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
|
|
|
|
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-01-17 17:03:55 +00:00
|
|
|
int dpcm_be_dai_hw_params(struct snd_soc_pcm_runtime *fe, int stream)
|
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;
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-21 01:47:12 +00:00
|
|
|
/* 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;
|
|
|
|
|
|
|
|
dev_dbg(be->dev, "ASoC: hw_params BE %s\n",
|
2016-09-26 08:29:31 +00:00
|
|
|
be->dai_link->name);
|
2016-01-21 01:47:12 +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
|
|
|
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);
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_FE);
|
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
|
|
|
|
|
|
|
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:
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
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
|
|
|
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",
|
2016-09-26 08:29:31 +00:00
|
|
|
dpcm->be->dai_link->name, 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
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2014-01-17 17:03:55 +00:00
|
|
|
int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream,
|
2012-05-09 20:46:27 +00:00
|
|
|
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:
|
2014-05-12 12:12:05 +00:00
|
|
|
if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START)
|
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;
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
static int dpcm_fe_dai_do_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:
|
|
|
|
fe->dpcm[stream].state = SND_SOC_DPCM_STATE_STOP;
|
|
|
|
break;
|
2017-01-01 06:44:39 +00:00
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
|
|
|
|
fe->dpcm[stream].state = SND_SOC_DPCM_STATE_PAUSED;
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_NO;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
static int dpcm_fe_dai_trigger(struct snd_pcm_substream *substream, int cmd)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
int stream = substream->stream;
|
|
|
|
|
|
|
|
/* if FE's runtime_update is already set, we're in race;
|
|
|
|
* process this trigger later at exit
|
|
|
|
*/
|
|
|
|
if (fe->dpcm[stream].runtime_update != SND_SOC_DPCM_UPDATE_NO) {
|
|
|
|
fe->dpcm[stream].trigger_pending = cmd + 1;
|
|
|
|
return 0; /* delayed, assuming it's successful */
|
|
|
|
}
|
|
|
|
|
|
|
|
/* we're alone, let's trigger */
|
|
|
|
return dpcm_fe_dai_do_trigger(substream, cmd);
|
|
|
|
}
|
|
|
|
|
2014-01-17 17:03:55 +00:00
|
|
|
int dpcm_be_dai_prepare(struct snd_soc_pcm_runtime *fe, int stream)
|
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;
|
|
|
|
|
|
|
|
if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) &&
|
2015-10-28 02:15:34 +00:00
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND))
|
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;
|
|
|
|
|
2012-11-19 14:39:15 +00:00
|
|
|
dev_dbg(be->dev, "ASoC: prepare BE %s\n",
|
2016-09-26 08:29:31 +00:00
|
|
|
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
|
|
|
|
|
|
|
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
|
|
|
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_FE);
|
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
|
|
|
|
|
|
|
/* 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:
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
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
|
|
|
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;
|
2017-10-11 01:37:23 +00:00
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
2012-04-26 15:16:10 +00:00
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->ioctl)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* FIXME: use 1st ioctl */
|
|
|
|
return component->driver->ops->ioctl(substream, cmd, arg);
|
|
|
|
}
|
|
|
|
|
2012-04-26 15:16:10 +00:00
|
|
|
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;
|
|
|
|
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_BE);
|
2012-04-25 11:12:51 +00:00
|
|
|
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");
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
2012-04-25 11:12:51 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dpcm_run_old_update(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_BE);
|
2012-04-25 11:12:51 +00:00
|
|
|
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");
|
ASoC: dpcm: Fix race between FE/BE updates and trigger
DPCM can update the FE/BE connection states totally asynchronously
from the FE's PCM state. Most of FE/BE state changes are protected by
mutex, so that they won't race, but there are still some actions that
are uncovered. For example, suppose to switch a BE while a FE's
stream is running. This would call soc_dpcm_runtime_update(), which
sets FE's runtime_update flag, then sets up and starts BEs, and clears
FE's runtime_update flag again.
When a device emits XRUN during this operation, the PCM core triggers
snd_pcm_stop(XRUN). Since the trigger action is an atomic ops, this
isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
It eventually updates and clears FE's runtime_update flag while
soc_dpcm_runtime_update() is running concurrently, and it results in
confusion.
Usually, for avoiding such a race, we take a lock. There is a PCM
stream lock for that purpose. However, as already mentioned, the
trigger action is atomic, and we can't take the lock for the whole
soc_dpcm_runtime_update() or other operations that include the lengthy
jobs like hw_params or prepare.
This patch provides an alternative solution. This adds a way to defer
the conflicting trigger callback to be executed at the end of FE/BE
state changes. For doing it, two things are introduced:
- Each runtime_update state change of FEs is protected via PCM stream
lock.
- The FE's trigger callback checks the runtime_update flag. If it's
not set, the trigger action is executed there. If set, mark the
pending trigger action and returns immediately.
- At the exit of runtime_update state change, it checks whether the
pending trigger is present. If yes, it executes the trigger action
at this point.
Reported-and-tested-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
2014-11-04 15:52:28 +00:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
2012-04-25 11:12:51 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
static int soc_dpcm_fe_runtime_update(struct snd_soc_pcm_runtime *fe, int new)
|
2012-04-25 11:12:51 +00:00
|
|
|
{
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
struct snd_soc_dapm_widget_list *list;
|
|
|
|
int count, paths;
|
2012-04-25 11:12:51 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
if (!fe->dai_link->dynamic)
|
|
|
|
return 0;
|
2012-04-25 11:12:51 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
/* only check active links */
|
|
|
|
if (!fe->cpu_dai->active)
|
|
|
|
return 0;
|
2012-04-25 11:12:51 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
/* DAPM sync will call this to update DSP paths */
|
|
|
|
dev_dbg(fe->dev, "ASoC: DPCM %s runtime update for FE %s\n",
|
|
|
|
new ? "new" : "old", fe->dai_link->name);
|
2012-04-25 11:12:51 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
/* skip if FE doesn't have playback capability */
|
|
|
|
if (!fe->cpu_dai->driver->playback.channels_min ||
|
|
|
|
!fe->codec_dai->driver->playback.channels_min)
|
|
|
|
goto capture;
|
2012-04-25 11:12:51 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
/* skip if FE isn't currently playing */
|
|
|
|
if (!fe->cpu_dai->playback_active || !fe->codec_dai->playback_active)
|
|
|
|
goto capture;
|
2012-04-25 11:12:51 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
paths = dpcm_path_get(fe, SNDRV_PCM_STREAM_PLAYBACK, &list);
|
|
|
|
if (paths < 0) {
|
|
|
|
dev_warn(fe->dev, "ASoC: %s no valid %s path\n",
|
|
|
|
fe->dai_link->name, "playback");
|
|
|
|
return paths;
|
|
|
|
}
|
2012-04-25 11:12:51 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
/* update any playback paths */
|
|
|
|
count = dpcm_process_paths(fe, SNDRV_PCM_STREAM_PLAYBACK, &list, new);
|
|
|
|
if (count) {
|
|
|
|
if (new)
|
|
|
|
dpcm_run_new_update(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
else
|
2012-04-25 11:12:51 +00:00
|
|
|
dpcm_run_old_update(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
dpcm_clear_pending_state(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
dpcm_be_disconnect(fe, SNDRV_PCM_STREAM_PLAYBACK);
|
|
|
|
}
|
|
|
|
|
|
|
|
dpcm_path_put(&list);
|
|
|
|
|
2012-04-25 11:12:51 +00:00
|
|
|
capture:
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
/* skip if FE doesn't have capture capability */
|
|
|
|
if (!fe->cpu_dai->driver->capture.channels_min ||
|
|
|
|
!fe->codec_dai->driver->capture.channels_min)
|
|
|
|
return 0;
|
2014-11-17 08:02:57 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
/* skip if FE isn't currently capturing */
|
|
|
|
if (!fe->cpu_dai->capture_active || !fe->codec_dai->capture_active)
|
|
|
|
return 0;
|
2012-04-25 11:12:51 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
paths = dpcm_path_get(fe, SNDRV_PCM_STREAM_CAPTURE, &list);
|
|
|
|
if (paths < 0) {
|
|
|
|
dev_warn(fe->dev, "ASoC: %s no valid %s path\n",
|
|
|
|
fe->dai_link->name, "capture");
|
|
|
|
return paths;
|
|
|
|
}
|
2012-04-25 11:12:51 +00:00
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
/* update any old capture paths */
|
|
|
|
count = dpcm_process_paths(fe, SNDRV_PCM_STREAM_CAPTURE, &list, new);
|
|
|
|
if (count) {
|
|
|
|
if (new)
|
2012-04-25 11:12:51 +00:00
|
|
|
dpcm_run_new_update(fe, SNDRV_PCM_STREAM_CAPTURE);
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
else
|
2012-04-25 11:12:51 +00:00
|
|
|
dpcm_run_old_update(fe, SNDRV_PCM_STREAM_CAPTURE);
|
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
dpcm_clear_pending_state(fe, SNDRV_PCM_STREAM_CAPTURE);
|
|
|
|
dpcm_be_disconnect(fe, SNDRV_PCM_STREAM_CAPTURE);
|
2012-04-25 11:12:51 +00:00
|
|
|
}
|
|
|
|
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
dpcm_path_put(&list);
|
|
|
|
|
2012-04-25 11:12:51 +00:00
|
|
|
return 0;
|
|
|
|
}
|
ASoC: dpcm: improve runtime update predictability
As it is, dpcm_runtime_update() performs the old path and new path
update of a frontend before going on to the next frontend DAI.
Depending the order of the FEs within the rtd list, the result of
the update might be different.
For example:
* Frontend A connected to backend C, with a 48kHz playback
* Frontend B connected to backend D, with a 44.1kHz playback
* FE A appears before FE B in the rtd list of the card.
If we reparent BE C to FE B (disconnecting BE D):
* old path update of FE A will run first, and BE C will get hw_free()
and shutdown()
* new path update of FE B will run after and BE C, which is stopped,
so it will be configured at 44.1kHz, as expected
If we reparent BE D to FE A (disconnecting BE C):
* new path update of FE A will run first but since BE D is still running
at 44.1kHz, it won't be reconfigured (no call to startup() or
hw_params())
* old path update of FE B runs after, nothing happens
* In this case, we end up with a BE playing at 44.1kHz a stream which is
supposed to be played at 48Khz (too slow)
To improve this situation, this patch performs all the FE old paths update
before going on to update the new paths. With this, the result should
no longer depend on the order of the FE within the card rtd list.
Please note that there might be a small performance penalty since
dpcm_process_paths() is called twice per stream direction.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-06-26 10:07:25 +00:00
|
|
|
|
|
|
|
/* Called by DAPM mixer/mux changes to update audio routing between PCMs and
|
|
|
|
* any DAI links.
|
|
|
|
*/
|
|
|
|
int soc_dpcm_runtime_update(struct snd_soc_card *card)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
mutex_lock_nested(&card->mutex, SND_SOC_CARD_CLASS_RUNTIME);
|
|
|
|
/* shutdown all old paths first */
|
|
|
|
list_for_each_entry(fe, &card->rtd_list, list) {
|
|
|
|
ret = soc_dpcm_fe_runtime_update(fe, 0);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* bring new paths up */
|
|
|
|
list_for_each_entry(fe, &card->rtd_list, list) {
|
|
|
|
ret = soc_dpcm_fe_runtime_update(fe, 1);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
mutex_unlock(&card->mutex);
|
|
|
|
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
|
|
|
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;
|
2014-07-08 21:19:35 +00:00
|
|
|
int i;
|
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->dai_link->ignore_suspend)
|
|
|
|
continue;
|
|
|
|
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < be->num_codecs; i++) {
|
|
|
|
struct snd_soc_dai *dai = be->codec_dais[i];
|
|
|
|
struct snd_soc_dai_driver *drv = dai->driver;
|
|
|
|
|
|
|
|
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
|
|
|
|
2014-07-08 21:19:35 +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;
|
|
|
|
|
2014-09-10 09:54:07 +00:00
|
|
|
ret = dpcm_path_get(fe, stream, &list);
|
|
|
|
if (ret < 0) {
|
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
return ret;
|
|
|
|
} else if (ret == 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;
|
|
|
|
}
|
|
|
|
|
2017-08-25 10:04:07 +00:00
|
|
|
static void soc_pcm_private_free(struct snd_pcm *pcm)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = pcm->private_data;
|
2017-09-26 01:00:53 +00:00
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
|
2018-01-24 05:18:46 +00:00
|
|
|
/* need to sync the delayed work before releasing resources */
|
|
|
|
flush_delayed_work(&rtd->delayed_work);
|
2017-09-26 01:00:53 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
2017-08-25 10:04:07 +00:00
|
|
|
|
2018-05-08 03:19:49 +00:00
|
|
|
if (component->driver->pcm_free)
|
|
|
|
component->driver->pcm_free(pcm);
|
2017-09-26 01:00:53 +00:00
|
|
|
}
|
2017-08-25 10:04:07 +00:00
|
|
|
}
|
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
static int soc_rtdcom_ack(struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
|
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->ack)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* FIXME. it returns 1st ask now */
|
|
|
|
return component->driver->ops->ack(substream);
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int soc_rtdcom_copy_user(struct snd_pcm_substream *substream, int channel,
|
|
|
|
unsigned long pos, void __user *buf,
|
|
|
|
unsigned long bytes)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
|
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->copy_user)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* FIXME. it returns 1st copy now */
|
|
|
|
return component->driver->ops->copy_user(substream, channel,
|
|
|
|
pos, buf, bytes);
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int soc_rtdcom_copy_kernel(struct snd_pcm_substream *substream, int channel,
|
|
|
|
unsigned long pos, void *buf, unsigned long bytes)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
|
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->copy_kernel)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* FIXME. it returns 1st copy now */
|
|
|
|
return component->driver->ops->copy_kernel(substream, channel,
|
|
|
|
pos, buf, bytes);
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int soc_rtdcom_fill_silence(struct snd_pcm_substream *substream, int channel,
|
|
|
|
unsigned long pos, unsigned long bytes)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
|
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->fill_silence)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* FIXME. it returns 1st silence now */
|
|
|
|
return component->driver->ops->fill_silence(substream, channel,
|
|
|
|
pos, bytes);
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct page *soc_rtdcom_page(struct snd_pcm_substream *substream,
|
|
|
|
unsigned long offset)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct page *page;
|
|
|
|
|
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->page)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* FIXME. it returns 1st page now */
|
|
|
|
page = component->driver->ops->page(substream, offset);
|
|
|
|
if (page)
|
|
|
|
return page;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int soc_rtdcom_mmap(struct snd_pcm_substream *substream,
|
|
|
|
struct vm_area_struct *vma)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
|
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
|
|
|
if (!component->driver->ops ||
|
|
|
|
!component->driver->ops->mmap)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* FIXME. it returns 1st mmap now */
|
|
|
|
return component->driver->ops->mmap(substream, vma);
|
|
|
|
}
|
|
|
|
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2011-06-09 13:45:53 +00:00
|
|
|
/* create a new pcm */
|
|
|
|
int soc_new_pcm(struct snd_soc_pcm_runtime *rtd, int num)
|
|
|
|
{
|
2014-07-08 21:19:35 +00:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2011-06-09 13:45:53 +00:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2017-09-26 01:00:53 +00:00
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct snd_soc_rtdcom_list *rtdcom;
|
2011-06-09 13:45:53 +00:00
|
|
|
struct snd_pcm *pcm;
|
|
|
|
char new_name[64];
|
|
|
|
int ret = 0, playback = 0, capture = 0;
|
2014-07-08 21:19:35 +00:00
|
|
|
int i;
|
2011-06-09 13:45:53 +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
|
|
|
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
|
2014-01-07 17:51:42 +00:00
|
|
|
playback = rtd->dai_link->dpcm_playback;
|
|
|
|
capture = rtd->dai_link->dpcm_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
|
|
|
} else {
|
2014-07-08 21:19:35 +00:00
|
|
|
for (i = 0; i < rtd->num_codecs; i++) {
|
|
|
|
codec_dai = rtd->codec_dais[i];
|
|
|
|
if (codec_dai->driver->playback.channels_min)
|
|
|
|
playback = 1;
|
|
|
|
if (codec_dai->driver->capture.channels_min)
|
|
|
|
capture = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
capture = capture && cpu_dai->driver->capture.channels_min;
|
|
|
|
playback = playback && 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
|
|
|
}
|
|
|
|
|
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",
|
2014-07-08 21:19:35 +00:00
|
|
|
rtd->dai_link->stream_name,
|
|
|
|
(rtd->num_codecs > 1) ?
|
|
|
|
"multicodec" : rtd->codec_dai->name, num);
|
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 = 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);
|
|
|
|
|
2015-02-12 04:29:53 +00:00
|
|
|
pcm->nonatomic = rtd->dai_link->nonatomic;
|
2011-06-09 13:45:53 +00:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2017-10-11 01:37:23 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
const struct snd_pcm_ops *ops = rtdcom->component->driver->ops;
|
|
|
|
|
|
|
|
if (!ops)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (ops->ack)
|
|
|
|
rtd->ops.ack = soc_rtdcom_ack;
|
|
|
|
if (ops->copy_user)
|
|
|
|
rtd->ops.copy_user = soc_rtdcom_copy_user;
|
|
|
|
if (ops->copy_kernel)
|
|
|
|
rtd->ops.copy_kernel = soc_rtdcom_copy_kernel;
|
|
|
|
if (ops->fill_silence)
|
|
|
|
rtd->ops.fill_silence = soc_rtdcom_fill_silence;
|
|
|
|
if (ops->page)
|
|
|
|
rtd->ops.page = soc_rtdcom_page;
|
|
|
|
if (ops->mmap)
|
|
|
|
rtd->ops.mmap = soc_rtdcom_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
|
|
|
|
2017-09-26 01:00:53 +00:00
|
|
|
for_each_rtdcom(rtd, rtdcom) {
|
|
|
|
component = rtdcom->component;
|
|
|
|
|
2018-05-08 03:19:49 +00:00
|
|
|
if (!component->driver->pcm_new)
|
2017-09-26 01:00:53 +00:00
|
|
|
continue;
|
|
|
|
|
2018-05-08 03:19:49 +00:00
|
|
|
ret = component->driver->pcm_new(rtd);
|
2017-07-12 15:55:29 +00:00
|
|
|
if (ret < 0) {
|
2017-09-26 01:00:53 +00:00
|
|
|
dev_err(component->dev,
|
2017-07-12 15:55:29 +00:00
|
|
|
"ASoC: pcm constructor failed: %d\n",
|
|
|
|
ret);
|
|
|
|
return ret;
|
2011-06-09 13:45:53 +00:00
|
|
|
}
|
|
|
|
}
|
2017-07-12 15:55:29 +00:00
|
|
|
|
2017-08-25 10:04:07 +00:00
|
|
|
pcm->private_free = soc_pcm_private_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:
|
2014-07-08 21:19:35 +00:00
|
|
|
dev_info(rtd->card->dev, "%s <-> %s mapping ok\n",
|
|
|
|
(rtd->num_codecs > 1) ? "multicodec" : rtd->codec_dai->name,
|
|
|
|
cpu_dai->name);
|
2011-06-09 13:45:53 +00:00
|
|
|
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
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_FS
|
2016-11-22 10:29:14 +00:00
|
|
|
static const char *dpcm_state_string(enum snd_soc_dpcm_state state)
|
2012-04-25 11:12:50 +00:00
|
|
|
{
|
|
|
|
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,
|
|
|
|
};
|
|
|
|
|
2015-04-09 08:52:37 +00:00
|
|
|
void soc_dpcm_debugfs_add(struct snd_soc_pcm_runtime *rtd)
|
2012-04-25 11:12:50 +00:00
|
|
|
{
|
2012-05-08 09:33:47 +00:00
|
|
|
if (!rtd->dai_link)
|
2015-04-09 08:52:37 +00:00
|
|
|
return;
|
2012-05-08 09:33:47 +00:00
|
|
|
|
2015-04-09 08:52:38 +00:00
|
|
|
if (!rtd->card->debugfs_card_root)
|
|
|
|
return;
|
2012-05-08 09:33:47 +00:00
|
|
|
|
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);
|
2015-04-09 08:52:37 +00:00
|
|
|
return;
|
2012-04-25 11:12:50 +00:00
|
|
|
}
|
|
|
|
|
2017-07-29 14:40:55 +00:00
|
|
|
debugfs_create_file("state", 0444, rtd->debugfs_dpcm_root,
|
|
|
|
rtd, &dpcm_state_fops);
|
2012-04-25 11:12:50 +00:00
|
|
|
}
|
|
|
|
#endif
|