2018-07-02 13:22:44 +07: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 20:45:53 +07: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 13:57:31 +07:00
|
|
|
#include <linux/pinctrl/consumer.h>
|
2011-12-04 03:14:31 +07:00
|
|
|
#include <linux/pm_runtime.h>
|
2011-06-09 20:45:53 +07: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 18:12:49 +07:00
|
|
|
#include <linux/export.h>
|
2012-04-25 18:12:50 +07:00
|
|
|
#include <linux/debugfs.h>
|
2011-06-09 20:45:53 +07: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 18:12:49 +07:00
|
|
|
#include <sound/soc-dpcm.h>
|
2011-06-09 20:45:53 +07: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 18:12:49 +07:00
|
|
|
#define DPCM_MAX_BE_USERS 8
|
|
|
|
|
2020-01-22 07:44:35 +07:00
|
|
|
static int soc_rtd_startup(struct snd_soc_pcm_runtime *rtd,
|
|
|
|
struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
if (rtd->dai_link->ops &&
|
|
|
|
rtd->dai_link->ops->startup)
|
|
|
|
return rtd->dai_link->ops->startup(substream);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-01-22 07:44:40 +07:00
|
|
|
static void soc_rtd_shutdown(struct snd_soc_pcm_runtime *rtd,
|
|
|
|
struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
if (rtd->dai_link->ops &&
|
|
|
|
rtd->dai_link->ops->shutdown)
|
|
|
|
rtd->dai_link->ops->shutdown(substream);
|
|
|
|
}
|
|
|
|
|
2020-01-22 07:44:44 +07:00
|
|
|
static int soc_rtd_prepare(struct snd_soc_pcm_runtime *rtd,
|
|
|
|
struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
if (rtd->dai_link->ops &&
|
|
|
|
rtd->dai_link->ops->prepare)
|
|
|
|
return rtd->dai_link->ops->prepare(substream);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-01-22 07:44:48 +07:00
|
|
|
static int soc_rtd_hw_params(struct snd_soc_pcm_runtime *rtd,
|
|
|
|
struct snd_pcm_substream *substream,
|
|
|
|
struct snd_pcm_hw_params *params)
|
|
|
|
{
|
|
|
|
if (rtd->dai_link->ops &&
|
|
|
|
rtd->dai_link->ops->hw_params)
|
|
|
|
return rtd->dai_link->ops->hw_params(substream, params);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-01-22 07:44:52 +07:00
|
|
|
static void soc_rtd_hw_free(struct snd_soc_pcm_runtime *rtd,
|
|
|
|
struct snd_pcm_substream *substream)
|
|
|
|
{
|
|
|
|
if (rtd->dai_link->ops &&
|
|
|
|
rtd->dai_link->ops->hw_free)
|
|
|
|
rtd->dai_link->ops->hw_free(substream);
|
|
|
|
}
|
|
|
|
|
2020-01-22 07:44:56 +07:00
|
|
|
static int soc_rtd_trigger(struct snd_soc_pcm_runtime *rtd,
|
|
|
|
struct snd_pcm_substream *substream,
|
|
|
|
int cmd)
|
|
|
|
{
|
|
|
|
if (rtd->dai_link->ops &&
|
|
|
|
rtd->dai_link->ops->trigger)
|
|
|
|
return rtd->dai_link->ops->trigger(substream, cmd);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-03-05 19:17:43 +07: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.
|
|
|
|
*
|
2019-08-13 17:45:32 +07:00
|
|
|
* Must be called with the rtd->card->pcm_mutex being held
|
2014-03-05 19:17:43 +07:00
|
|
|
*/
|
|
|
|
void snd_soc_runtime_activate(struct snd_soc_pcm_runtime *rtd, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2018-09-03 09:12:56 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
int i;
|
2014-03-05 19:17:43 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
lockdep_assert_held(&rtd->card->pcm_mutex);
|
2014-03-05 19:17:43 +07:00
|
|
|
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
|
|
|
cpu_dai->playback_active++;
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
|
|
|
codec_dai->playback_active++;
|
2014-03-05 19:17:43 +07:00
|
|
|
} else {
|
|
|
|
cpu_dai->capture_active++;
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
|
|
|
codec_dai->capture_active++;
|
2014-03-05 19:17:43 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
cpu_dai->active++;
|
2014-03-05 19:17:47 +07:00
|
|
|
cpu_dai->component->active++;
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
|
|
|
codec_dai->active++;
|
|
|
|
codec_dai->component->active++;
|
2014-07-09 04:19:35 +07:00
|
|
|
}
|
2014-03-05 19:17:43 +07: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.
|
|
|
|
*
|
2019-08-13 17:45:32 +07:00
|
|
|
* Must be called with the rtd->card->pcm_mutex being held
|
2014-03-05 19:17:43 +07:00
|
|
|
*/
|
|
|
|
void snd_soc_runtime_deactivate(struct snd_soc_pcm_runtime *rtd, int stream)
|
|
|
|
{
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2018-09-03 09:12:56 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
int i;
|
2014-03-05 19:17:43 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
lockdep_assert_held(&rtd->card->pcm_mutex);
|
2014-03-05 19:17:43 +07:00
|
|
|
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
|
|
|
cpu_dai->playback_active--;
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
|
|
|
codec_dai->playback_active--;
|
2014-03-05 19:17:43 +07:00
|
|
|
} else {
|
|
|
|
cpu_dai->capture_active--;
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
|
|
|
codec_dai->capture_active--;
|
2014-03-05 19:17:43 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
cpu_dai->active--;
|
2014-03-05 19:17:47 +07:00
|
|
|
cpu_dai->component->active--;
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
|
|
|
codec_dai->component->active--;
|
|
|
|
codec_dai->active--;
|
2014-07-09 04:19:35 +07:00
|
|
|
}
|
2014-03-05 19:17:43 +07:00
|
|
|
}
|
|
|
|
|
2014-03-05 19:17:42 +07: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 08:38:08 +07:00
|
|
|
struct snd_soc_component *component;
|
2014-07-09 04:19:35 +07:00
|
|
|
bool ignore = true;
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
int i;
|
2014-07-09 04:19:35 +07:00
|
|
|
|
2014-03-05 19:17:42 +07:00
|
|
|
if (!rtd->pmdown_time || rtd->dai_link->ignore_pmdown_time)
|
|
|
|
return true;
|
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component)
|
2018-01-19 12:21:19 +07:00
|
|
|
ignore &= !component->driver->use_pmdown_time;
|
2017-10-11 08:38:08 +07:00
|
|
|
|
|
|
|
return ignore;
|
2014-03-05 19:17:42 +07:00
|
|
|
}
|
|
|
|
|
2013-05-14 16:05:30 +07: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 18:12:49 +07:00
|
|
|
/* DPCM stream event, send event to FE and all active BEs. */
|
2014-01-18 00:03:55 +07: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 18:12:49 +07:00
|
|
|
int event)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, dir, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
be->dai_link->name, event, dir);
|
|
|
|
|
2017-07-15 13:15:05 +07: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 18:12:49 +07:00
|
|
|
snd_soc_dapm_stream_event(be, dir, event);
|
|
|
|
}
|
|
|
|
|
|
|
|
snd_soc_dapm_stream_event(fe, dir, event);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-08-29 16:15:14 +07:00
|
|
|
static int soc_pcm_apply_symmetry(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_soc_dai *soc_dai)
|
2011-06-09 20:45:53 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
int ret;
|
|
|
|
|
2013-11-13 17:56:24 +07: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 20:39:28 +07:00
|
|
|
ret = snd_pcm_hw_constraint_single(substream->runtime,
|
2013-11-13 17:56:24 +07:00
|
|
|
SNDRV_PCM_HW_PARAM_RATE,
|
2015-10-18 20:39:28 +07:00
|
|
|
soc_dai->rate);
|
2013-11-13 17:56:24 +07:00
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(soc_dai->dev,
|
|
|
|
"ASoC: Unable to apply rate constraint: %d\n",
|
|
|
|
ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2013-11-13 17:56:24 +07: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 20:45:53 +07:00
|
|
|
|
2015-10-18 20:39:28 +07:00
|
|
|
ret = snd_pcm_hw_constraint_single(substream->runtime,
|
2013-11-13 17:56:24 +07: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 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
2013-11-13 17:56:24 +07: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 20:45:53 +07:00
|
|
|
|
2015-10-18 20:39:28 +07:00
|
|
|
ret = snd_pcm_hw_constraint_single(substream->runtime,
|
2013-11-13 17:56:24 +07: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 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-11-13 17:56:24 +07: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;
|
2018-09-03 09:12:56 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
unsigned int rate, channels, sample_bits, symmetry, i;
|
2013-11-13 17:56:24 +07: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-09 04:19:35 +07:00
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
|
|
|
symmetry |= codec_dai->driver->symmetric_rates;
|
2014-07-09 04:19:35 +07:00
|
|
|
|
2013-11-13 17:56:24 +07: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 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
2013-11-13 17:56:24 +07:00
|
|
|
symmetry = cpu_dai->driver->symmetric_channels ||
|
|
|
|
rtd->dai_link->symmetric_channels;
|
2014-07-09 04:19:35 +07:00
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
|
|
|
symmetry |= codec_dai->driver->symmetric_channels;
|
2014-07-09 04:19:35 +07:00
|
|
|
|
2013-11-13 17:56:24 +07: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 20:45:53 +07:00
|
|
|
|
2013-11-13 17:56:24 +07:00
|
|
|
symmetry = cpu_dai->driver->symmetric_samplebits ||
|
|
|
|
rtd->dai_link->symmetric_samplebits;
|
2014-07-09 04:19:35 +07:00
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
|
|
|
symmetry |= codec_dai->driver->symmetric_samplebits;
|
2014-07-09 04:19:35 +07:00
|
|
|
|
2013-11-13 17:56:24 +07: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 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-11-30 23:38:58 +07: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;
|
2018-09-03 09:12:56 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
unsigned int symmetry, i;
|
2013-11-30 23:38:58 +07:00
|
|
|
|
2014-07-09 04:19:35 +07: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 23:38:58 +07:00
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
2014-07-09 04:19:35 +07:00
|
|
|
symmetry = symmetry ||
|
2018-09-03 09:12:56 +07:00
|
|
|
codec_dai->driver->symmetric_rates ||
|
|
|
|
codec_dai->driver->symmetric_channels ||
|
|
|
|
codec_dai->driver->symmetric_samplebits;
|
2014-07-09 04:19:35 +07:00
|
|
|
|
|
|
|
return symmetry;
|
2013-11-30 23:38:58 +07:00
|
|
|
}
|
|
|
|
|
2014-07-09 04:19:35 +07:00
|
|
|
static void soc_pcm_set_msb(struct snd_pcm_substream *substream, int bits)
|
2012-01-17 01:38:51 +07:00
|
|
|
{
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
2014-12-31 23:10:34 +07:00
|
|
|
int ret;
|
2012-01-17 01:38:51 +07:00
|
|
|
|
|
|
|
if (!bits)
|
|
|
|
return;
|
|
|
|
|
2014-12-30 00:43:38 +07: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-17 01:38:51 +07:00
|
|
|
}
|
|
|
|
|
2014-07-01 14:47:55 +07: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-09 04:19:35 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i;
|
2014-07-01 14:47:55 +07:00
|
|
|
unsigned int bits = 0, cpu_bits;
|
|
|
|
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2014-07-09 04:19:35 +07:00
|
|
|
if (codec_dai->driver->playback.sig_bits == 0) {
|
|
|
|
bits = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
bits = max(codec_dai->driver->playback.sig_bits, bits);
|
|
|
|
}
|
2014-07-01 14:47:55 +07:00
|
|
|
cpu_bits = cpu_dai->driver->playback.sig_bits;
|
|
|
|
} else {
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2014-10-07 19:33:46 +07:00
|
|
|
if (codec_dai->driver->capture.sig_bits == 0) {
|
2014-07-09 04:19:35 +07:00
|
|
|
bits = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
bits = max(codec_dai->driver->capture.sig_bits, bits);
|
|
|
|
}
|
2014-07-01 14:47:55 +07:00
|
|
|
cpu_bits = cpu_dai->driver->capture.sig_bits;
|
|
|
|
}
|
|
|
|
|
2014-07-09 04:19:35 +07:00
|
|
|
soc_pcm_set_msb(substream, bits);
|
|
|
|
soc_pcm_set_msb(substream, cpu_bits);
|
2014-07-01 14:47:55 +07:00
|
|
|
}
|
|
|
|
|
2014-07-09 04:19:35 +07:00
|
|
|
static void soc_pcm_init_runtime_hw(struct snd_pcm_substream *substream)
|
2013-05-14 16:05:31 +07:00
|
|
|
{
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_pcm_runtime *runtime = substream->runtime;
|
2013-11-27 15:58:18 +07:00
|
|
|
struct snd_pcm_hardware *hw = &runtime->hw;
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
2018-09-03 09:12:56 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
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 15:58:18 +07:00
|
|
|
|
2014-07-09 04:19:35 +07:00
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
cpu_stream = &cpu_dai_drv->playback;
|
2014-01-06 20:19:16 +07:00
|
|
|
else
|
2014-07-09 04:19:35 +07:00
|
|
|
cpu_stream = &cpu_dai_drv->capture;
|
2013-11-27 15:58:18 +07:00
|
|
|
|
2014-07-09 04:19:35 +07:00
|
|
|
/* first calculate min/max only for CODECs in the DAI link */
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2015-08-24 19:16:51 +07: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.
|
|
|
|
*/
|
2018-09-03 09:12:56 +07:00
|
|
|
if (!snd_soc_dai_stream_valid(codec_dai,
|
2015-08-24 19:16:51 +07:00
|
|
|
substream->stream))
|
|
|
|
continue;
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
codec_dai_drv = codec_dai->driver;
|
2014-07-09 04:19:35 +07:00
|
|
|
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 15:58:18 +07:00
|
|
|
|
|
|
|
snd_pcm_limit_hw_rates(runtime);
|
|
|
|
|
|
|
|
hw->rate_min = max(hw->rate_min, cpu_stream->rate_min);
|
2014-07-09 04:19:35 +07:00
|
|
|
hw->rate_min = max(hw->rate_min, rate_min);
|
2013-11-27 15:58:18 +07:00
|
|
|
hw->rate_max = min_not_zero(hw->rate_max, cpu_stream->rate_max);
|
2014-07-09 04:19:35 +07:00
|
|
|
hw->rate_max = min_not_zero(hw->rate_max, rate_max);
|
2013-05-14 16:05:31 +07:00
|
|
|
}
|
|
|
|
|
2019-05-13 14:08:33 +07:00
|
|
|
static int soc_pcm_components_open(struct snd_pcm_substream *substream,
|
|
|
|
struct snd_soc_component **last)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_component *component;
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
int i, ret = 0;
|
2019-05-13 14:08:33 +07:00
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
2019-05-13 14:08:33 +07:00
|
|
|
*last = component;
|
|
|
|
|
2019-07-26 11:49:54 +07:00
|
|
|
ret = snd_soc_component_module_get_when_open(component);
|
|
|
|
if (ret < 0) {
|
2019-05-13 14:08:33 +07:00
|
|
|
dev_err(component->dev,
|
|
|
|
"ASoC: can't get module %s\n",
|
|
|
|
component->name);
|
2019-07-26 11:49:54 +07:00
|
|
|
return ret;
|
2019-05-13 14:08:33 +07:00
|
|
|
}
|
|
|
|
|
2019-07-26 11:50:01 +07:00
|
|
|
ret = snd_soc_component_open(component, substream);
|
2019-05-13 14:08:33 +07:00
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(component->dev,
|
|
|
|
"ASoC: can't open component %s: %d\n",
|
|
|
|
component->name, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
*last = NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-06-19 22:22:09 +07: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_component *component;
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
int i, ret = 0;
|
2018-06-19 22:22:09 +07:00
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
2018-06-19 22:22:09 +07:00
|
|
|
if (component == last)
|
|
|
|
break;
|
|
|
|
|
2019-07-26 11:50:07 +07:00
|
|
|
ret |= snd_soc_component_close(component, substream);
|
2019-07-26 11:49:54 +07:00
|
|
|
snd_soc_component_module_put_when_close(component);
|
2018-06-19 22:22:09 +07:00
|
|
|
}
|
|
|
|
|
2019-07-26 11:50:07 +07:00
|
|
|
return ret;
|
2018-06-19 22:22:09 +07:00
|
|
|
}
|
|
|
|
|
2011-06-09 20:45:53 +07: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 22:39:02 +07:00
|
|
|
* startup for the cpu DAI, component, machine and codec DAI.
|
2011-06-09 20:45:53 +07: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 13:18:10 +07:00
|
|
|
struct snd_soc_component *component;
|
2011-06-09 20:45:53 +07:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
const char *codec_dai_name = "multicodec";
|
2018-06-19 22:22:09 +07:00
|
|
|
int i, ret = 0;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2020-01-10 09:36:13 +07:00
|
|
|
for_each_rtd_components(rtd, i, component)
|
|
|
|
pinctrl_pm_select_default_state(component->dev);
|
2017-08-08 13:18:10 +07:00
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component)
|
2017-08-08 13:18:10 +07:00
|
|
|
pm_runtime_get_sync(component->dev);
|
2011-12-04 03:14:31 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_lock_nested(&rtd->card->pcm_mutex, rtd->card->pcm_subclass);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
|
|
|
/* startup the audio subsystem */
|
2019-07-22 08:33:32 +07:00
|
|
|
ret = snd_soc_dai_startup(cpu_dai, substream);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(cpu_dai->dev, "ASoC: can't open interface %s: %d\n",
|
|
|
|
cpu_dai->name, ret);
|
|
|
|
goto out;
|
2011-06-09 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
2019-05-13 14:08:33 +07:00
|
|
|
ret = soc_pcm_components_open(substream, &component);
|
|
|
|
if (ret < 0)
|
|
|
|
goto component_err;
|
2017-10-11 08:37:23 +07:00
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2019-07-22 08:33:32 +07:00
|
|
|
ret = snd_soc_dai_startup(codec_dai, substream);
|
|
|
|
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 20:45:53 +07:00
|
|
|
}
|
2014-07-09 04:19:35 +07:00
|
|
|
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
codec_dai->tx_mask = 0;
|
|
|
|
else
|
|
|
|
codec_dai->rx_mask = 0;
|
2011-06-09 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
2020-01-22 07:44:35 +07:00
|
|
|
ret = soc_rtd_startup(rtd, substream);
|
|
|
|
if (ret < 0) {
|
|
|
|
pr_err("ASoC: %s startup failed: %d\n",
|
|
|
|
rtd->dai_link->name, ret);
|
|
|
|
goto machine_err;
|
2011-06-09 20:45:53 +07: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 18:12:49 +07: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 20:45:53 +07:00
|
|
|
/* Check that the codec and cpu DAIs are compatible */
|
2014-07-09 04:19:35 +07:00
|
|
|
soc_pcm_init_runtime_hw(substream);
|
|
|
|
|
|
|
|
if (rtd->num_codecs == 1)
|
|
|
|
codec_dai_name = rtd->codec_dai->name;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2013-11-30 23:38:58 +07:00
|
|
|
if (soc_pcm_has_symmetry(substream))
|
|
|
|
runtime->hw.info |= SNDRV_PCM_INFO_JOINT_DUPLEX;
|
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
ret = -EINVAL;
|
|
|
|
if (!runtime->hw.rates) {
|
2012-11-19 21:39:15 +07:00
|
|
|
printk(KERN_ERR "ASoC: %s <-> %s No matching rates\n",
|
2014-07-09 04:19:35 +07:00
|
|
|
codec_dai_name, cpu_dai->name);
|
2011-06-09 20:45:53 +07:00
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
if (!runtime->hw.formats) {
|
2012-11-19 21:39:15 +07:00
|
|
|
printk(KERN_ERR "ASoC: %s <-> %s No matching formats\n",
|
2014-07-09 04:19:35 +07:00
|
|
|
codec_dai_name, cpu_dai->name);
|
2011-06-09 20:45:53 +07:00
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
if (!runtime->hw.channels_min || !runtime->hw.channels_max ||
|
|
|
|
runtime->hw.channels_min > runtime->hw.channels_max) {
|
2012-11-19 21:39:15 +07:00
|
|
|
printk(KERN_ERR "ASoC: %s <-> %s No matching channels\n",
|
2014-07-09 04:19:35 +07:00
|
|
|
codec_dai_name, cpu_dai->name);
|
2011-06-09 20:45:53 +07:00
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
|
2014-07-01 14:47:55 +07:00
|
|
|
soc_pcm_apply_msb(substream);
|
2012-01-17 01:38:51 +07:00
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
/* Symmetry only applies if we've already got an active stream. */
|
2011-08-29 16:15:14 +07:00
|
|
|
if (cpu_dai->active) {
|
|
|
|
ret = soc_pcm_apply_symmetry(substream, cpu_dai);
|
|
|
|
if (ret != 0)
|
|
|
|
goto config_err;
|
|
|
|
}
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
|
|
|
if (codec_dai->active) {
|
|
|
|
ret = soc_pcm_apply_symmetry(substream, codec_dai);
|
2014-07-09 04:19:35 +07:00
|
|
|
if (ret != 0)
|
|
|
|
goto config_err;
|
|
|
|
}
|
2011-06-09 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
2012-11-19 21:39:15 +07:00
|
|
|
pr_debug("ASoC: %s <-> %s info:\n",
|
2014-07-09 04:19:35 +07:00
|
|
|
codec_dai_name, cpu_dai->name);
|
2012-11-19 21:39:15 +07: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 20:45:53 +07:00
|
|
|
runtime->hw.channels_max);
|
2012-11-19 21:39:15 +07:00
|
|
|
pr_debug("ASoC: min rate %d max rate %d\n", runtime->hw.rate_min,
|
2011-06-09 20:45:53 +07: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 18:12:49 +07:00
|
|
|
dynamic:
|
2014-03-05 19:17:43 +07:00
|
|
|
|
|
|
|
snd_soc_runtime_activate(rtd, substream->stream);
|
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_unlock(&rtd->card->pcm_mutex);
|
2011-06-09 20:45:53 +07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
config_err:
|
2020-01-22 07:44:40 +07:00
|
|
|
soc_rtd_shutdown(rtd, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
|
|
|
machine_err:
|
2014-07-09 04:19:35 +07:00
|
|
|
i = rtd->num_codecs;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
|
|
|
codec_dai_err:
|
2019-07-22 08:33:39 +07:00
|
|
|
for_each_rtd_codec_dai_rollback(rtd, i, codec_dai)
|
|
|
|
snd_soc_dai_shutdown(codec_dai, substream);
|
2014-07-09 04:19:35 +07:00
|
|
|
|
2017-10-11 08:37:23 +07:00
|
|
|
component_err:
|
2018-06-19 22:22:09 +07:00
|
|
|
soc_pcm_components_close(substream, component);
|
2019-05-13 14:08:33 +07:00
|
|
|
|
2019-07-22 08:33:39 +07:00
|
|
|
snd_soc_dai_shutdown(cpu_dai, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
out:
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_unlock(&rtd->card->pcm_mutex);
|
2011-12-04 03:14:31 +07:00
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
2017-08-08 13:18:10 +07:00
|
|
|
pm_runtime_mark_last_busy(component->dev);
|
|
|
|
pm_runtime_put_autosuspend(component->dev);
|
2016-01-05 18:44:49 +07:00
|
|
|
}
|
|
|
|
|
2020-01-10 09:36:13 +07:00
|
|
|
for_each_rtd_components(rtd, i, component)
|
|
|
|
if (!component->active)
|
|
|
|
pinctrl_pm_select_sleep_state(component->dev);
|
2011-12-04 03:14:31 +07:00
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-12-04 00:30:07 +07:00
|
|
|
static void codec2codec_close_delayed_work(struct snd_soc_pcm_runtime *rtd)
|
2019-07-25 23:59:47 +07:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Currently nothing to do for c2c links
|
|
|
|
* Since c2c links are internal nodes in the DAPM graph and
|
|
|
|
* don't interface with the outside world or application layer
|
|
|
|
* we don't have to do any special handling on close.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
/*
|
|
|
|
* Called by ALSA when a PCM substream is closed. Private data can be
|
2018-04-24 22:39:02 +07:00
|
|
|
* freed here. The cpu DAI, codec DAI, machine and components are also
|
2011-06-09 20:45:53 +07:00
|
|
|
* shutdown.
|
|
|
|
*/
|
2011-06-09 23:04:59 +07:00
|
|
|
static int soc_pcm_close(struct snd_pcm_substream *substream)
|
2011-06-09 20:45:53 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
2017-08-08 13:18:10 +07:00
|
|
|
struct snd_soc_component *component;
|
2011-06-09 20:45:53 +07:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_lock_nested(&rtd->card->pcm_mutex, rtd->card->pcm_subclass);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2014-03-05 19:17:43 +07:00
|
|
|
snd_soc_runtime_deactivate(rtd, substream->stream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2011-08-29 16:15:14 +07:00
|
|
|
/* clear the corresponding DAIs rate when inactive */
|
|
|
|
if (!cpu_dai->active)
|
|
|
|
cpu_dai->rate = 0;
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2014-07-09 04:19:35 +07:00
|
|
|
if (!codec_dai->active)
|
|
|
|
codec_dai->rate = 0;
|
|
|
|
}
|
2011-08-17 14:20:01 +07:00
|
|
|
|
2014-10-15 14:04:59 +07:00
|
|
|
snd_soc_dai_digital_mute(cpu_dai, 1, substream->stream);
|
|
|
|
|
2019-07-22 08:33:39 +07:00
|
|
|
snd_soc_dai_shutdown(cpu_dai, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-07-22 08:33:39 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
|
|
|
snd_soc_dai_shutdown(codec_dai, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2020-01-22 07:44:40 +07:00
|
|
|
soc_rtd_shutdown(rtd, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2018-06-19 22:22:09 +07:00
|
|
|
soc_pcm_components_close(substream, NULL);
|
2017-10-11 08:37:23 +07:00
|
|
|
|
2020-01-10 09:36:23 +07:00
|
|
|
snd_soc_dapm_stream_stop(rtd, substream->stream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_unlock(&rtd->card->pcm_mutex);
|
2011-12-04 03:14:31 +07:00
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
2017-08-08 13:18:10 +07:00
|
|
|
pm_runtime_mark_last_busy(component->dev);
|
|
|
|
pm_runtime_put_autosuspend(component->dev);
|
2016-01-05 18:44:49 +07:00
|
|
|
}
|
|
|
|
|
2020-01-10 09:36:13 +07:00
|
|
|
for_each_rtd_components(rtd, i, component)
|
|
|
|
if (!component->active)
|
|
|
|
pinctrl_pm_select_sleep_state(component->dev);
|
2011-12-04 03:14:31 +07:00
|
|
|
|
2011-06-09 20:45:53 +07: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 08:37:23 +07:00
|
|
|
struct snd_soc_component *component;
|
2011-06-09 20:45:53 +07:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i, ret = 0;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_lock_nested(&rtd->card->pcm_mutex, rtd->card->pcm_subclass);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2020-01-22 07:44:44 +07:00
|
|
|
ret = soc_rtd_prepare(rtd, substream);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(rtd->card->dev,
|
|
|
|
"ASoC: machine prepare error: %d\n", ret);
|
|
|
|
goto out;
|
2011-06-09 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
2019-07-26 11:50:13 +07:00
|
|
|
ret = snd_soc_component_prepare(component, substream);
|
2017-10-11 08:37:23 +07:00
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(component->dev,
|
|
|
|
"ASoC: platform prepare error: %d\n", ret);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2019-07-22 08:33:45 +07:00
|
|
|
ret = snd_soc_dai_prepare(codec_dai, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
if (ret < 0) {
|
2019-07-22 08:33:45 +07:00
|
|
|
dev_err(codec_dai->dev,
|
|
|
|
"ASoC: codec DAI prepare error: %d\n",
|
|
|
|
ret);
|
2011-06-09 20:45:53 +07:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-07-22 08:33:45 +07:00
|
|
|
ret = snd_soc_dai_prepare(cpu_dai, substream);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(cpu_dai->dev,
|
|
|
|
"ASoC: cpu DAI prepare error: %d\n", ret);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
/* 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-14 01:23:05 +07:00
|
|
|
rtd->pop_wait) {
|
|
|
|
rtd->pop_wait = 0;
|
2011-06-09 20:45:53 +07:00
|
|
|
cancel_delayed_work(&rtd->delayed_work);
|
|
|
|
}
|
|
|
|
|
2012-03-07 23:32:59 +07:00
|
|
|
snd_soc_dapm_stream_event(rtd, substream->stream,
|
|
|
|
SND_SOC_DAPM_STREAM_START);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai)
|
|
|
|
snd_soc_dai_digital_mute(codec_dai, 0,
|
2014-07-09 04:19:35 +07:00
|
|
|
substream->stream);
|
2014-10-15 14:04:59 +07:00
|
|
|
snd_soc_dai_digital_mute(cpu_dai, 0, substream->stream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
|
|
|
out:
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_unlock(&rtd->card->pcm_mutex);
|
2011-06-09 20:45:53 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-07-09 04:19:35 +07: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;
|
|
|
|
}
|
|
|
|
|
2018-06-19 22:22:09 +07: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_component *component;
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
int i, ret = 0;
|
2018-06-19 22:22:09 +07:00
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
2018-06-19 22:22:09 +07:00
|
|
|
if (component == last)
|
|
|
|
break;
|
|
|
|
|
2019-07-26 11:50:24 +07:00
|
|
|
ret |= snd_soc_component_hw_free(component, substream);
|
2018-06-19 22:22:09 +07:00
|
|
|
}
|
|
|
|
|
2019-07-26 11:50:24 +07:00
|
|
|
return ret;
|
2018-06-19 22:22:09 +07:00
|
|
|
}
|
|
|
|
|
2011-06-09 20:45:53 +07: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 08:37:23 +07:00
|
|
|
struct snd_soc_component *component;
|
2011-06-09 20:45:53 +07:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2018-09-03 09:12:56 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2018-06-19 22:22:09 +07:00
|
|
|
int i, ret = 0;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_lock_nested(&rtd->card->pcm_mutex, rtd->card->pcm_subclass);
|
2019-11-12 17:46:42 +07:00
|
|
|
|
|
|
|
ret = soc_pcm_params_symmetry(substream, params);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
|
2020-01-22 07:44:48 +07:00
|
|
|
ret = soc_rtd_hw_params(rtd, substream, params);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(rtd->card->dev,
|
|
|
|
"ASoC: machine hw_params failed: %d\n", ret);
|
|
|
|
goto out;
|
2011-06-09 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_pcm_hw_params codec_params;
|
|
|
|
|
2015-08-24 19:16:51 +07: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-09 04:19:35 +07:00
|
|
|
/* copy params for each codec */
|
|
|
|
codec_params = *params;
|
|
|
|
|
|
|
|
/* fixup params based on TDM slot masks */
|
ASoC:soc-pcm:fix a codec fixup issue in TDM case
On HDaudio platforms, if playback is started when capture is working,
there is no audible output.
This can be root-caused to the use of the rx|tx_mask to store an HDaudio
stream tag.
If capture is stared before playback, rx_mask would be non-zero on HDaudio
platform, then the channel number of playback, which is in the same codec
dai with the capture, would be changed by soc_pcm_codec_params_fixup based
on the tx_mask at first, then overwritten by this function based on rx_mask
at last.
According to the author of tx|rx_mask, tx_mask is for playback and rx_mask
is for capture. And stream direction is checked at all other references of
tx|rx_mask in ASoC, so here should be an error. This patch checks stream
direction for tx|rx_mask for fixup function.
This issue would affect not only HDaudio+ASoC, but also I2S codecs if the
channel number based on rx_mask is not equal to the one for tx_mask. It could
be rarely reproduecd because most drivers in kernel set the same channel number
to tx|rx_mask or rx_mask is zero.
Tested on all platforms using stream_tag & HDaudio and intel I2S platforms.
Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-03-08 15:38:57 +07:00
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK &&
|
|
|
|
codec_dai->tx_mask)
|
2014-07-09 04:19:35 +07:00
|
|
|
soc_pcm_codec_params_fixup(&codec_params,
|
|
|
|
codec_dai->tx_mask);
|
ASoC:soc-pcm:fix a codec fixup issue in TDM case
On HDaudio platforms, if playback is started when capture is working,
there is no audible output.
This can be root-caused to the use of the rx|tx_mask to store an HDaudio
stream tag.
If capture is stared before playback, rx_mask would be non-zero on HDaudio
platform, then the channel number of playback, which is in the same codec
dai with the capture, would be changed by soc_pcm_codec_params_fixup based
on the tx_mask at first, then overwritten by this function based on rx_mask
at last.
According to the author of tx|rx_mask, tx_mask is for playback and rx_mask
is for capture. And stream direction is checked at all other references of
tx|rx_mask in ASoC, so here should be an error. This patch checks stream
direction for tx|rx_mask for fixup function.
This issue would affect not only HDaudio+ASoC, but also I2S codecs if the
channel number based on rx_mask is not equal to the one for tx_mask. It could
be rarely reproduecd because most drivers in kernel set the same channel number
to tx|rx_mask or rx_mask is zero.
Tested on all platforms using stream_tag & HDaudio and intel I2S platforms.
Signed-off-by: Rander Wang <rander.wang@linux.intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-03-08 15:38:57 +07:00
|
|
|
|
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_CAPTURE &&
|
|
|
|
codec_dai->rx_mask)
|
2014-07-09 04:19:35 +07:00
|
|
|
soc_pcm_codec_params_fixup(&codec_params,
|
|
|
|
codec_dai->rx_mask);
|
|
|
|
|
2019-07-22 08:33:04 +07:00
|
|
|
ret = snd_soc_dai_hw_params(codec_dai, substream,
|
|
|
|
&codec_params);
|
2014-07-09 04:19:38 +07:00
|
|
|
if(ret < 0)
|
2011-06-09 20:45:53 +07:00
|
|
|
goto codec_err;
|
|
|
|
|
2014-07-09 04:19:35 +07: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));
|
2019-01-31 20:30:18 +07:00
|
|
|
|
|
|
|
snd_soc_dapm_update_dai(substream, &codec_params, codec_dai);
|
2011-06-09 20:45:53 +07:00
|
|
|
}
|
|
|
|
|
2019-07-22 08:33:04 +07:00
|
|
|
ret = snd_soc_dai_hw_params(cpu_dai, substream, params);
|
2014-07-09 04:19:38 +07:00
|
|
|
if (ret < 0)
|
|
|
|
goto interface_err;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-05-13 14:07:43 +07:00
|
|
|
/* store the parameters for each DAIs */
|
|
|
|
cpu_dai->rate = params_rate(params);
|
|
|
|
cpu_dai->channels = params_channels(params);
|
|
|
|
cpu_dai->sample_bits =
|
|
|
|
snd_pcm_format_physical_width(params_format(params));
|
|
|
|
|
|
|
|
snd_soc_dapm_update_dai(substream, params, cpu_dai);
|
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
2019-07-26 11:50:19 +07:00
|
|
|
ret = snd_soc_component_hw_params(component, substream, params);
|
2018-06-19 22:22:09 +07:00
|
|
|
if (ret < 0) {
|
2017-10-11 08:37:23 +07:00
|
|
|
dev_err(component->dev,
|
|
|
|
"ASoC: %s hw params failed: %d\n",
|
2018-06-19 22:22:09 +07:00
|
|
|
component->name, ret);
|
|
|
|
goto component_err;
|
2017-10-11 08:37:23 +07:00
|
|
|
}
|
|
|
|
}
|
2018-06-19 22:22:09 +07:00
|
|
|
component = NULL;
|
2017-10-11 08:37:23 +07:00
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
out:
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_unlock(&rtd->card->pcm_mutex);
|
2011-06-09 20:45:53 +07:00
|
|
|
return ret;
|
|
|
|
|
2017-10-11 08:37:23 +07:00
|
|
|
component_err:
|
2018-06-19 22:22:09 +07:00
|
|
|
soc_pcm_components_hw_free(substream, component);
|
2017-10-11 08:37:23 +07:00
|
|
|
|
2019-07-22 08:33:19 +07:00
|
|
|
snd_soc_dai_hw_free(cpu_dai, substream);
|
2019-05-13 14:07:52 +07:00
|
|
|
cpu_dai->rate = 0;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
|
|
|
interface_err:
|
2014-07-09 04:19:35 +07:00
|
|
|
i = rtd->num_codecs;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
|
|
|
codec_err:
|
2018-09-18 08:28:30 +07:00
|
|
|
for_each_rtd_codec_dai_rollback(rtd, i, codec_dai) {
|
2019-04-29 16:47:50 +07:00
|
|
|
if (!snd_soc_dai_stream_valid(codec_dai, substream->stream))
|
|
|
|
continue;
|
|
|
|
|
2019-07-22 08:33:19 +07:00
|
|
|
snd_soc_dai_hw_free(codec_dai, substream);
|
2014-07-09 04:19:35 +07:00
|
|
|
codec_dai->rate = 0;
|
|
|
|
}
|
|
|
|
|
2020-01-22 07:44:52 +07:00
|
|
|
soc_rtd_hw_free(rtd, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_unlock(&rtd->card->pcm_mutex);
|
2011-06-09 20:45:53 +07: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-09 04:19:35 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2013-12-04 10:18:36 +07:00
|
|
|
bool playback = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
|
2014-07-09 04:19:35 +07:00
|
|
|
int i;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_lock_nested(&rtd->card->pcm_mutex, rtd->card->pcm_subclass);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2013-11-20 17:37:09 +07: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;
|
|
|
|
}
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2014-07-09 04:19:35 +07:00
|
|
|
if (codec_dai->active == 1) {
|
|
|
|
codec_dai->rate = 0;
|
|
|
|
codec_dai->channels = 0;
|
|
|
|
codec_dai->sample_bits = 0;
|
|
|
|
}
|
2013-11-20 17:37:09 +07:00
|
|
|
}
|
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
/* apply codec digital mute */
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
|
|
|
if ((playback && codec_dai->playback_active == 1) ||
|
|
|
|
(!playback && codec_dai->capture_active == 1))
|
|
|
|
snd_soc_dai_digital_mute(codec_dai, 1,
|
2014-07-09 04:19:35 +07:00
|
|
|
substream->stream);
|
|
|
|
}
|
2011-06-09 20:45:53 +07:00
|
|
|
|
|
|
|
/* free any machine hw params */
|
2020-01-22 07:44:52 +07:00
|
|
|
soc_rtd_hw_free(rtd, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2017-10-11 08:37:23 +07:00
|
|
|
/* free any component resources */
|
2018-06-19 22:22:09 +07:00
|
|
|
soc_pcm_components_hw_free(substream, NULL);
|
2017-10-11 08:37:23 +07:00
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
/* now free hw params for the DAIs */
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2019-04-29 16:47:50 +07:00
|
|
|
if (!snd_soc_dai_stream_valid(codec_dai, substream->stream))
|
|
|
|
continue;
|
|
|
|
|
2019-07-22 08:33:19 +07:00
|
|
|
snd_soc_dai_hw_free(codec_dai, substream);
|
2014-07-09 04:19:35 +07:00
|
|
|
}
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-07-22 08:33:19 +07:00
|
|
|
snd_soc_dai_hw_free(cpu_dai, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-08-13 17:45:32 +07:00
|
|
|
mutex_unlock(&rtd->card->pcm_mutex);
|
2011-06-09 20:45:53 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-09-27 14:16:46 +07:00
|
|
|
static int soc_pcm_trigger_start(struct snd_pcm_substream *substream, int cmd)
|
2011-06-09 20:45:53 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
2017-10-11 08:37:23 +07:00
|
|
|
struct snd_soc_component *component;
|
2011-06-09 20:45:53 +07:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i, ret;
|
|
|
|
|
2020-01-22 07:44:56 +07:00
|
|
|
ret = soc_rtd_trigger(rtd, substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
2019-07-26 11:50:29 +07:00
|
|
|
ret = snd_soc_component_trigger(component, substream, cmd);
|
2017-10-11 08:37:23 +07:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-09-23 21:22:57 +07:00
|
|
|
ret = snd_soc_dai_trigger(cpu_dai, substream, cmd);
|
2019-07-22 08:33:51 +07:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
2014-04-28 19:17:52 +07:00
|
|
|
|
2019-09-27 14:16:46 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
|
|
|
ret = snd_soc_dai_trigger(codec_dai, substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int soc_pcm_trigger_stop(struct snd_pcm_substream *substream, int cmd)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_component *component;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i, ret;
|
|
|
|
|
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
|
|
|
ret = snd_soc_dai_trigger(codec_dai, substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = snd_soc_dai_trigger(cpu_dai, substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
2019-09-27 14:16:46 +07:00
|
|
|
ret = snd_soc_component_trigger(component, substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-01-22 07:44:56 +07:00
|
|
|
ret = soc_rtd_trigger(rtd, substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
2014-04-28 19:17:52 +07:00
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-09-27 14:16:46 +07:00
|
|
|
static int soc_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case SNDRV_PCM_TRIGGER_START:
|
|
|
|
case SNDRV_PCM_TRIGGER_RESUME:
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
|
|
|
|
ret = soc_pcm_trigger_start(substream, cmd);
|
|
|
|
break;
|
|
|
|
case SNDRV_PCM_TRIGGER_STOP:
|
|
|
|
case SNDRV_PCM_TRIGGER_SUSPEND:
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
|
|
|
|
ret = soc_pcm_trigger_stop(substream, cmd);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-05-10 03:46:27 +07:00
|
|
|
static int soc_pcm_bespoke_trigger(struct snd_pcm_substream *substream,
|
|
|
|
int cmd)
|
2012-04-25 18:12:52 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *rtd = substream->private_data;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
|
|
|
int i, ret;
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2019-07-22 08:33:56 +07:00
|
|
|
ret = snd_soc_dai_bespoke_trigger(codec_dai, substream, cmd);
|
2012-04-25 18:12:52 +07:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
2019-07-22 08:33:56 +07:00
|
|
|
|
2019-09-23 21:22:57 +07:00
|
|
|
ret = snd_soc_dai_bespoke_trigger(cpu_dai, substream, cmd);
|
2019-07-22 08:33:56 +07:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2012-04-25 18:12:52 +07:00
|
|
|
return 0;
|
|
|
|
}
|
2011-06-09 20:45:53 +07:00
|
|
|
/*
|
|
|
|
* soc level wrapper for pointer callback
|
2018-04-24 22:39:02 +07:00
|
|
|
* If cpu_dai, codec_dai, component driver has the delay callback, then
|
2011-06-09 20:45:53 +07: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;
|
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2011-06-09 20:45:53 +07:00
|
|
|
struct snd_pcm_runtime *runtime = substream->runtime;
|
|
|
|
snd_pcm_uframes_t offset = 0;
|
|
|
|
snd_pcm_sframes_t delay = 0;
|
2014-07-09 04:19:35 +07:00
|
|
|
snd_pcm_sframes_t codec_delay = 0;
|
|
|
|
int i;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2018-08-01 17:07:33 +07:00
|
|
|
/* clearing the previous total delay */
|
|
|
|
runtime->delay = 0;
|
|
|
|
|
2019-07-26 11:51:47 +07:00
|
|
|
offset = snd_soc_pcm_component_pointer(substream);
|
2017-10-11 08:37:23 +07:00
|
|
|
|
2018-08-01 17:07:33 +07:00
|
|
|
/* base delay if assigned in pointer callback */
|
|
|
|
delay = runtime->delay;
|
2017-10-11 08:37:23 +07:00
|
|
|
|
2019-07-22 08:34:09 +07:00
|
|
|
delay += snd_soc_dai_delay(cpu_dai, substream);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2019-07-22 08:34:09 +07:00
|
|
|
codec_delay = max(codec_delay,
|
|
|
|
snd_soc_dai_delay(codec_dai, substream));
|
2014-07-09 04:19:35 +07:00
|
|
|
}
|
|
|
|
delay += codec_delay;
|
2011-06-09 20:45:53 +07: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 18:12:49 +07: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;
|
2019-03-08 12:05:53 +07:00
|
|
|
unsigned long flags;
|
2019-11-07 20:48:33 +07:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
2019-10-06 04:22:02 +07:00
|
|
|
char *name;
|
2019-11-07 20:48:33 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
/* only add new dpcms */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
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;
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_lock_irqsave(&fe->card->dpcm_lock, flags);
|
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 18:12:49 +07:00
|
|
|
list_add(&dpcm->list_be, &fe->dpcm[stream].be_clients);
|
|
|
|
list_add(&dpcm->list_fe, &be->dpcm[stream].fe_clients);
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_unlock_irqrestore(&fe->card->dpcm_lock, flags);
|
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 18:12:49 +07:00
|
|
|
|
2013-09-30 21:08:15 +07: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 18:12:49 +07:00
|
|
|
stream ? "capture" : "playback", fe->dai_link->name,
|
|
|
|
stream ? "<-" : "->", be->dai_link->name);
|
|
|
|
|
2012-04-25 18:12:50 +07:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
2019-10-06 04:22:02 +07:00
|
|
|
name = kasprintf(GFP_KERNEL, "%s:%s", be->dai_link->name,
|
|
|
|
stream ? "capture" : "playback");
|
|
|
|
if (name) {
|
|
|
|
dpcm->debugfs_state = debugfs_create_dir(name,
|
|
|
|
fe->debugfs_dpcm_root);
|
|
|
|
debugfs_create_u32("state", 0644, dpcm->debugfs_state,
|
|
|
|
&dpcm->state);
|
|
|
|
kfree(name);
|
|
|
|
}
|
2012-04-25 18:12:50 +07: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 18:12:49 +07: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);
|
|
|
|
|
2018-09-18 08:30:54 +07:00
|
|
|
for_each_dpcm_fe(be, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
if (dpcm->fe == fe)
|
|
|
|
continue;
|
|
|
|
|
2013-09-30 21:08:15 +07: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 18:12:49 +07: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-18 00:03:55 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm, *d;
|
2019-03-08 12:05:53 +07:00
|
|
|
unsigned long flags;
|
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 18:12:49 +07:00
|
|
|
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be_safe(fe, stream, dpcm, d) {
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
stream ? "capture" : "playback",
|
|
|
|
dpcm->be->dai_link->name);
|
|
|
|
|
|
|
|
if (dpcm->state != SND_SOC_DPCM_LINK_STATE_FREE)
|
|
|
|
continue;
|
|
|
|
|
2013-09-30 21:08:15 +07: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 18:12:49 +07: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 18:12:50 +07:00
|
|
|
#ifdef CONFIG_DEBUG_FS
|
2019-07-31 20:17:15 +07:00
|
|
|
debugfs_remove_recursive(dpcm->debugfs_state);
|
2012-04-25 18:12:50 +07:00
|
|
|
#endif
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_lock_irqsave(&fe->card->dpcm_lock, flags);
|
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 18:12:49 +07:00
|
|
|
list_del(&dpcm->list_be);
|
|
|
|
list_del(&dpcm->list_fe);
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_unlock_irqrestore(&fe->card->dpcm_lock, flags);
|
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 18:12:49 +07:00
|
|
|
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;
|
2018-09-18 08:28:04 +07:00
|
|
|
struct snd_soc_dai *dai;
|
2015-11-18 14:34:11 +07: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 18:12:49 +07:00
|
|
|
|
2018-03-15 03:43:51 +07: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 18:12:49 +07:00
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
|
2018-09-18 08:29:35 +07:00
|
|
|
for_each_card_rtds(card, 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 18:12:49 +07:00
|
|
|
|
2012-06-06 01:26:59 +07:00
|
|
|
if (!be->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
2018-03-15 03:43:51 +07: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-09 04:19:35 +07: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 18:12:49 +07:00
|
|
|
return be;
|
2014-07-09 04:19:35 +07:00
|
|
|
|
2018-09-18 08:28:04 +07:00
|
|
|
for_each_rtd_codec_dai(be, i, dai) {
|
2014-07-09 04:19:35 +07: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 18:12:49 +07:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
|
2018-09-18 08:29:35 +07:00
|
|
|
for_each_card_rtds(card, 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 18:12:49 +07:00
|
|
|
|
2012-06-06 01:26:59 +07:00
|
|
|
if (!be->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
2018-03-15 03:43:51 +07: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-09 04:19:35 +07: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 18:12:49 +07:00
|
|
|
return be;
|
2014-07-09 04:19:35 +07:00
|
|
|
|
2018-09-18 08:28:04 +07:00
|
|
|
for_each_rtd_codec_dai(be, i, dai) {
|
2014-07-09 04:19:35 +07: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 18:12:49 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-15 03:43:51 +07:00
|
|
|
/* dai link name and stream name set correctly ? */
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
stream ? "capture" : "playback", widget->name);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct snd_soc_dapm_widget *
|
2014-04-24 19:01:45 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
2014-04-24 19:01:45 +07: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 18:12:49 +07:00
|
|
|
else
|
2014-04-24 19:01:45 +07: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 18:12:49 +07: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 23:03:56 +07: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;
|
2018-09-03 09:12:56 +07:00
|
|
|
struct snd_soc_dai *dai;
|
2016-05-13 23:03:56 +07:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (dir == SND_SOC_DAPM_DIR_OUT) {
|
2018-09-18 08:29:35 +07:00
|
|
|
for_each_card_rtds(card, rtd) {
|
2016-05-13 23:03:56 +07:00
|
|
|
if (!rtd->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (rtd->cpu_dai->playback_widget == widget)
|
|
|
|
return true;
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, dai) {
|
2016-05-13 23:03:56 +07:00
|
|
|
if (dai->playback_widget == widget)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else { /* SND_SOC_DAPM_DIR_IN */
|
2018-09-18 08:29:35 +07:00
|
|
|
for_each_card_rtds(card, rtd) {
|
2016-05-13 23:03:56 +07:00
|
|
|
if (!rtd->dai_link->no_pcm)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (rtd->cpu_dai->capture_widget == widget)
|
|
|
|
return true;
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, dai) {
|
2016-05-13 23:03:56 +07:00
|
|
|
if (dai->capture_widget == widget)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-01-18 00:03:55 +07:00
|
|
|
int dpcm_path_get(struct snd_soc_pcm_runtime *fe,
|
2015-07-27 00:04:59 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_dai *cpu_dai = fe->cpu_dai;
|
|
|
|
int paths;
|
|
|
|
|
|
|
|
/* get number of valid DAI paths and their widgets */
|
2016-05-13 23:03:55 +07:00
|
|
|
paths = snd_soc_dapm_dai_get_connected_widgets(cpu_dai, stream, list,
|
2016-05-13 23:03:56 +07: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 18:12:49 +07:00
|
|
|
|
2012-11-19 21:39:15 +07: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 18:12:49 +07: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;
|
2018-09-18 08:28:04 +07:00
|
|
|
struct snd_soc_dai *dai;
|
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 18:12:49 +07:00
|
|
|
int prune = 0;
|
2019-10-15 10:59:38 +07:00
|
|
|
int do_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 18:12:49 +07:00
|
|
|
|
|
|
|
/* Destroy any old FE <--> BE connections */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
2014-07-09 04:19:35 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
/* is there a valid CPU DAI widget for this BE */
|
2014-04-24 19:01:45 +07: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 18:12:49 +07: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 */
|
2019-10-15 10:59:38 +07:00
|
|
|
do_prune = 1;
|
2018-09-18 08:28:04 +07:00
|
|
|
for_each_rtd_codec_dai(dpcm->be, i, dai) {
|
2014-07-09 04:19:35 +07:00
|
|
|
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 18:12:49 +07:00
|
|
|
|
2014-07-09 04:19:35 +07:00
|
|
|
/* prune the BE if it's no longer in our active list */
|
|
|
|
if (widget && widget_in_list(list, widget))
|
2019-10-15 10:59:38 +07:00
|
|
|
do_prune = 0;
|
2014-07-09 04:19:35 +07:00
|
|
|
}
|
2019-10-15 10:59:38 +07:00
|
|
|
if (!do_prune)
|
|
|
|
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 18:12:49 +07:00
|
|
|
|
2012-11-19 21:39:15 +07: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 18:12:49 +07: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 21:39:15 +07: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 18:12:49 +07: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-06 01:36:11 +07:00
|
|
|
switch (list->widgets[i]->id) {
|
|
|
|
case snd_soc_dapm_dai_in:
|
2015-07-06 09:02:10 +07:00
|
|
|
if (stream != SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
continue;
|
|
|
|
break;
|
2013-06-06 01:36:11 +07:00
|
|
|
case snd_soc_dapm_dai_out:
|
2015-07-06 09:02:10 +07:00
|
|
|
if (stream != SNDRV_PCM_STREAM_CAPTURE)
|
|
|
|
continue;
|
2013-06-06 01:36:11 +07: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 18:12:49 +07:00
|
|
|
continue;
|
2013-06-06 01:36:11 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
/* is there a valid BE rtd for this widget */
|
|
|
|
be = dpcm_get_be(card, list->widgets[i], stream);
|
|
|
|
if (!be) {
|
2012-11-19 21:39:15 +07: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 18:12:49 +07: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-18 00:03:55 +07: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 18:12:49 +07:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/* newly connected FE and BE */
|
|
|
|
err = dpcm_be_connect(fe, be, stream);
|
|
|
|
if (err < 0) {
|
2012-11-19 21:39:15 +07: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 18:12:49 +07: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 21:39:15 +07: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 18:12:49 +07:00
|
|
|
return new;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the corresponding BE DAIs that source or sink audio to this
|
|
|
|
* FE substream.
|
|
|
|
*/
|
2014-01-18 00:03:55 +07: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 18:12:49 +07: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-18 00:03:55 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
2019-03-08 12:05:53 +07:00
|
|
|
unsigned long flags;
|
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 18:12:49 +07:00
|
|
|
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_lock_irqsave(&fe->card->dpcm_lock, flags);
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm)
|
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 18:12:49 +07:00
|
|
|
dpcm->be->dpcm[stream].runtime_update =
|
|
|
|
SND_SOC_DPCM_UPDATE_NO;
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_unlock_irqrestore(&fe->card->dpcm_lock, flags);
|
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 18:12:49 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
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 */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
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 21:39:15 +07: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 18:12:49 +07: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-18 00:03:55 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int err, count = 0;
|
|
|
|
|
|
|
|
/* only startup BE DAIs that are either sinks or sources to this FE DAI */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
|
|
|
|
2013-10-31 22:09:20 +07: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 18:12:49 +07: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 21:39:15 +07: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 18:12:49 +07: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 22:09:20 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
be_substream->runtime = be->dpcm[stream].runtime;
|
|
|
|
err = soc_pcm_open(be_substream);
|
|
|
|
if (err < 0) {
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
be->dpcm[stream].users--;
|
|
|
|
if (be->dpcm[stream].users < 0)
|
2012-11-19 21:39:15 +07: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 18:12:49 +07: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 */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be_rollback(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
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 21:39:15 +07: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 18:12:49 +07: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 20:19:06 +07:00
|
|
|
static void dpcm_init_runtime_hw(struct snd_pcm_runtime *runtime,
|
2018-07-05 17:13:48 +07:00
|
|
|
struct snd_soc_pcm_stream *stream)
|
2014-01-06 20:19:06 +07:00
|
|
|
{
|
|
|
|
runtime->hw.rate_min = stream->rate_min;
|
2018-08-27 20:26:47 +07:00
|
|
|
runtime->hw.rate_max = min_not_zero(stream->rate_max, UINT_MAX);
|
2014-01-06 20:19:06 +07:00
|
|
|
runtime->hw.channels_min = stream->channels_min;
|
|
|
|
runtime->hw.channels_max = stream->channels_max;
|
2014-01-06 20:19:07 +07:00
|
|
|
if (runtime->hw.formats)
|
2018-07-05 17:13:48 +07:00
|
|
|
runtime->hw.formats &= stream->formats;
|
2014-01-06 20:19:07 +07:00
|
|
|
else
|
2018-07-05 17:13:48 +07:00
|
|
|
runtime->hw.formats = stream->formats;
|
2014-01-06 20:19:06 +07:00
|
|
|
runtime->hw.rates = stream->rates;
|
|
|
|
}
|
|
|
|
|
2018-07-05 17:13:48 +07:00
|
|
|
static void dpcm_runtime_merge_format(struct snd_pcm_substream *substream,
|
|
|
|
u64 *formats)
|
2015-05-12 09:03:33 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
2018-09-18 08:28:04 +07:00
|
|
|
struct snd_soc_dai *dai;
|
2015-05-12 09:03:33 +07:00
|
|
|
int stream = substream->stream;
|
|
|
|
|
|
|
|
if (!fe->dai_link->dpcm_merged_format)
|
2018-07-05 17:13:48 +07:00
|
|
|
return;
|
2015-05-12 09:03:33 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* It returns merged BE codec format
|
|
|
|
* if FE want to use it (= dpcm_merged_format)
|
|
|
|
*/
|
|
|
|
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
2015-05-12 09:03:33 +07:00
|
|
|
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;
|
|
|
|
|
2018-09-18 08:28:04 +07:00
|
|
|
for_each_rtd_codec_dai(be, i, dai) {
|
2018-06-27 22:36:38 +07:00
|
|
|
/*
|
|
|
|
* Skip CODECs which don't support the current stream
|
|
|
|
* type. See soc_pcm_init_runtime_hw() for more details
|
|
|
|
*/
|
2018-09-18 08:28:04 +07:00
|
|
|
if (!snd_soc_dai_stream_valid(dai, stream))
|
2018-06-27 22:36:38 +07:00
|
|
|
continue;
|
|
|
|
|
2018-09-18 08:28:04 +07:00
|
|
|
codec_dai_drv = dai->driver;
|
2015-05-12 09:03:33 +07:00
|
|
|
if (stream == SNDRV_PCM_STREAM_PLAYBACK)
|
|
|
|
codec_stream = &codec_dai_drv->playback;
|
|
|
|
else
|
|
|
|
codec_stream = &codec_dai_drv->capture;
|
|
|
|
|
2018-07-05 17:13:48 +07:00
|
|
|
*formats &= codec_stream->formats;
|
2015-05-12 09:03:33 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-07-05 17:13:48 +07:00
|
|
|
static void dpcm_runtime_merge_chan(struct snd_pcm_substream *substream,
|
|
|
|
unsigned int *channels_min,
|
|
|
|
unsigned int *channels_max)
|
2018-06-20 16:25:20 +07: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)
|
|
|
|
*/
|
|
|
|
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
2018-06-20 16:25:20 +07:00
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
2018-06-27 16:48:18 +07:00
|
|
|
struct snd_soc_dai_driver *cpu_dai_drv = be->cpu_dai->driver;
|
2018-06-20 16:25:20 +07:00
|
|
|
struct snd_soc_dai_driver *codec_dai_drv;
|
|
|
|
struct snd_soc_pcm_stream *codec_stream;
|
2018-06-27 16:48:18 +07: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 16:25:20 +07: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 17:13:49 +07: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)
|
|
|
|
*/
|
|
|
|
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
2018-07-05 17:13:49 +07:00
|
|
|
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;
|
2018-09-18 08:28:04 +07:00
|
|
|
struct snd_soc_dai *dai;
|
2018-07-05 17:13:49 +07:00
|
|
|
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);
|
|
|
|
|
2018-09-18 08:28:04 +07:00
|
|
|
for_each_rtd_codec_dai(be, i, dai) {
|
2018-07-05 17:13:49 +07:00
|
|
|
/*
|
|
|
|
* Skip CODECs which don't support the current stream
|
|
|
|
* type. See soc_pcm_init_runtime_hw() for more details
|
|
|
|
*/
|
2018-09-18 08:28:04 +07:00
|
|
|
if (!snd_soc_dai_stream_valid(dai, stream))
|
2018-07-05 17:13:49 +07:00
|
|
|
continue;
|
|
|
|
|
2018-09-18 08:28:04 +07:00
|
|
|
codec_dai_drv = dai->driver;
|
2018-07-05 17:13:49 +07:00
|
|
|
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-10 03:46:27 +07: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 18:12:49 +07: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 20:19:06 +07:00
|
|
|
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
|
2018-07-05 17:13:48 +07:00
|
|
|
dpcm_init_runtime_hw(runtime, &cpu_dai_drv->playback);
|
2014-01-06 20:19:06 +07:00
|
|
|
else
|
2018-07-05 17:13:48 +07:00
|
|
|
dpcm_init_runtime_hw(runtime, &cpu_dai_drv->capture);
|
2018-06-20 16:25:20 +07:00
|
|
|
|
2018-07-05 17:13:48 +07: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 17:13:49 +07: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 18:12:49 +07: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 22:52:28 +07: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 10:33:51 +07: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 */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
2015-12-11 10:33:51 +07:00
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
|
|
|
struct snd_pcm_substream *be_substream =
|
|
|
|
snd_soc_dpcm_get_substream(be, stream);
|
2019-04-01 20:03:54 +07:00
|
|
|
struct snd_soc_pcm_runtime *rtd;
|
2018-09-03 09:12:56 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2015-12-11 10:33:51 +07:00
|
|
|
int i;
|
|
|
|
|
2019-04-01 20:03:54 +07:00
|
|
|
/* A backend may not have the requested substream */
|
|
|
|
if (!be_substream)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
rtd = be_substream->private_data;
|
2016-09-06 15:47:55 +07:00
|
|
|
if (rtd->dai_link->be_hw_params_fixup)
|
|
|
|
continue;
|
|
|
|
|
2015-12-11 10:33:51 +07: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 09:18:19 +07:00
|
|
|
err = soc_pcm_apply_symmetry(fe_substream,
|
|
|
|
rtd->cpu_dai);
|
2015-12-11 10:33:51 +07:00
|
|
|
if (err < 0)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
|
|
|
if (codec_dai->active) {
|
2018-05-28 09:18:19 +07:00
|
|
|
err = soc_pcm_apply_symmetry(fe_substream,
|
2018-09-03 09:12:56 +07:00
|
|
|
codec_dai);
|
2015-12-11 10:33:51 +07:00
|
|
|
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 18:12:49 +07: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 22:52:28 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
ret = dpcm_be_dai_startup(fe, fe_substream->stream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
goto be_err;
|
|
|
|
}
|
|
|
|
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
/* start the DAI frontend */
|
|
|
|
ret = soc_pcm_open(fe_substream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 21:39:15 +07: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 18:12:49 +07: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 10:33:51 +07: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 22:52:28 +07: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 18:12:49 +07: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 22:52:28 +07: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 18:12:49 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-01-18 00:03:55 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
|
|
|
|
/* only shutdown BEs that are either sinks or sources to this FE DAI */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
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 21:39:15 +07: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 18:12:49 +07: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 09:18:18 +07: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 18:12:49 +07:00
|
|
|
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(be->dev, "ASoC: close BE %s\n",
|
2016-09-26 15:29:31 +07: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 18:12:49 +07: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 22:52:28 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
/* shutdown the BEs */
|
|
|
|
dpcm_be_dai_shutdown(fe, substream->stream);
|
|
|
|
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
/* now shutdown the frontend */
|
|
|
|
soc_pcm_close(substream);
|
|
|
|
|
|
|
|
/* run the stream event for each BE */
|
2020-01-10 09:36:56 +07:00
|
|
|
snd_soc_dapm_stream_stop(fe, 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 18:12:49 +07:00
|
|
|
|
|
|
|
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 22:52:28 +07: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 18:12:49 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-01-18 00:03:55 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
|
|
|
|
/* only hw_params backends that are either sinks or sources
|
|
|
|
* to this frontend DAI */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
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 09:13:43 +07: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 18:12:49 +07: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 10:36:02 +07:00
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED) &&
|
2016-02-01 23:56:40 +07: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 18:12:49 +07:00
|
|
|
continue;
|
|
|
|
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(be->dev, "ASoC: hw_free BE %s\n",
|
2016-09-26 15:29:31 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
soc_pcm_hw_free(be_substream);
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_HW_FREE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-05-10 03:46:27 +07: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 18:12:49 +07: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 22:52:28 +07: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 18:12:49 +07:00
|
|
|
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
/* call hw_free on the frontend */
|
|
|
|
err = soc_pcm_hw_free(substream);
|
|
|
|
if (err < 0)
|
2012-11-19 21:39:15 +07: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 18:12:49 +07: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 22:52:28 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-01-18 00:03:55 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int ret;
|
|
|
|
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
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 21:39:15 +07: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 18:12:49 +07:00
|
|
|
ret);
|
|
|
|
goto unwind;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-19 08:53:12 +07:00
|
|
|
/* copy the fixed-up hw params for BE dai */
|
|
|
|
memcpy(&be->dpcm[stream].hw_params, &dpcm->hw_params,
|
|
|
|
sizeof(struct snd_pcm_hw_params));
|
|
|
|
|
2016-01-21 08:47:12 +07: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 15:29:31 +07:00
|
|
|
be->dai_link->name);
|
2016-01-21 08:47:12 +07: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 18:12:49 +07:00
|
|
|
ret = soc_pcm_hw_params(be_substream, &dpcm->hw_params);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(dpcm->be->dev,
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
goto unwind;
|
|
|
|
}
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_HW_PARAMS;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
unwind:
|
|
|
|
/* disable any enabled and non active backends */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be_rollback(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
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-10 03:46:27 +07: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 18:12:49 +07: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 22:52:28 +07: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 18:12:49 +07: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 21:39:15 +07: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 18:12:49 +07:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2012-11-19 21:39:15 +07: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 18:12:49 +07: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 21:39:15 +07: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 18:12:49 +07: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 22:52:28 +07: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 18:12:49 +07: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 21:39:15 +07:00
|
|
|
dev_dbg(dpcm->be->dev, "ASoC: trigger BE %s cmd %d\n",
|
2016-09-26 15:29:31 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
ret = soc_pcm_trigger(substream, cmd);
|
|
|
|
if (ret < 0)
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-01-18 00:03:55 +07:00
|
|
|
int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream,
|
2012-05-10 03:46:27 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int ret = 0;
|
|
|
|
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
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 19:12:05 +07: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 18:12:49 +07: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: pcm: update FE/BE trigger order based on the command
Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST
determine the order in which FE DAI and BE DAI are triggered.
In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is
triggered before the BE DAI and in the case of
SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before
the FE DAI. And this order remains the same irrespective of the
trigger command.
In the case of the SOF driver, during playback, the FW
expects the BE DAI to be triggered before the FE DAI during
the START trigger. The BE DAI trigger handles the starting of
Link DMA and so it must be started before the FE DAI is started
to prevent xruns during pause/release. This can be addressed
by setting the trigger order for the FE dai link to
SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger,
the FW expects the FE DAI to be triggered before the BE DAI.
Retaining the same order during the START and STOP commands,
results in FW error as the DAI component in the FW is still
active.
The issue can be fixed by mirroring the trigger order of
FE and BE DAI's during the START and STOP trigger. So, with the
trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be
trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME
and the BE DAI will be triggered first during the
STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order
set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered
first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands
and the FE DAI will be triggered first during the
SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-05 05:48:11 +07:00
|
|
|
static int dpcm_dai_trigger_fe_be(struct snd_pcm_substream *substream,
|
|
|
|
int cmd, bool fe_first)
|
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* call trigger on the frontend before the backend. */
|
|
|
|
if (fe_first) {
|
|
|
|
dev_dbg(fe->dev, "ASoC: pre trigger FE %s cmd %d\n",
|
|
|
|
fe->dai_link->name, cmd);
|
|
|
|
|
|
|
|
ret = soc_pcm_trigger(substream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = dpcm_be_dai_trigger(fe, substream->stream, cmd);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* call trigger on the frontend after the backend. */
|
|
|
|
ret = dpcm_be_dai_trigger(fe, substream->stream, cmd);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
dev_dbg(fe->dev, "ASoC: post trigger FE %s cmd %d\n",
|
|
|
|
fe->dai_link->name, cmd);
|
|
|
|
|
|
|
|
ret = soc_pcm_trigger(substream, cmd);
|
|
|
|
|
|
|
|
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 22:52:28 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_pcm_runtime *fe = substream->private_data;
|
ASoC: pcm: update FE/BE trigger order based on the command
Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST
determine the order in which FE DAI and BE DAI are triggered.
In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is
triggered before the BE DAI and in the case of
SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before
the FE DAI. And this order remains the same irrespective of the
trigger command.
In the case of the SOF driver, during playback, the FW
expects the BE DAI to be triggered before the FE DAI during
the START trigger. The BE DAI trigger handles the starting of
Link DMA and so it must be started before the FE DAI is started
to prevent xruns during pause/release. This can be addressed
by setting the trigger order for the FE dai link to
SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger,
the FW expects the FE DAI to be triggered before the BE DAI.
Retaining the same order during the START and STOP commands,
results in FW error as the DAI component in the FW is still
active.
The issue can be fixed by mirroring the trigger order of
FE and BE DAI's during the START and STOP trigger. So, with the
trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be
trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME
and the BE DAI will be triggered first during the
STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order
set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered
first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands
and the FE DAI will be triggered first during the
SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-05 05:48:11 +07:00
|
|
|
int stream = substream->stream;
|
|
|
|
int ret = 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 18:12:49 +07:00
|
|
|
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:
|
ASoC: pcm: update FE/BE trigger order based on the command
Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST
determine the order in which FE DAI and BE DAI are triggered.
In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is
triggered before the BE DAI and in the case of
SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before
the FE DAI. And this order remains the same irrespective of the
trigger command.
In the case of the SOF driver, during playback, the FW
expects the BE DAI to be triggered before the FE DAI during
the START trigger. The BE DAI trigger handles the starting of
Link DMA and so it must be started before the FE DAI is started
to prevent xruns during pause/release. This can be addressed
by setting the trigger order for the FE dai link to
SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger,
the FW expects the FE DAI to be triggered before the BE DAI.
Retaining the same order during the START and STOP commands,
results in FW error as the DAI component in the FW is still
active.
The issue can be fixed by mirroring the trigger order of
FE and BE DAI's during the START and STOP trigger. So, with the
trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be
trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME
and the BE DAI will be triggered first during the
STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order
set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered
first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands
and the FE DAI will be triggered first during the
SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-05 05:48:11 +07:00
|
|
|
switch (cmd) {
|
|
|
|
case SNDRV_PCM_TRIGGER_START:
|
|
|
|
case SNDRV_PCM_TRIGGER_RESUME:
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
|
|
|
|
ret = dpcm_dai_trigger_fe_be(substream, cmd, true);
|
|
|
|
break;
|
|
|
|
case SNDRV_PCM_TRIGGER_STOP:
|
|
|
|
case SNDRV_PCM_TRIGGER_SUSPEND:
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
|
|
|
|
ret = dpcm_dai_trigger_fe_be(substream, cmd, false);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
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 18:12:49 +07:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case SND_SOC_DPCM_TRIGGER_POST:
|
ASoC: pcm: update FE/BE trigger order based on the command
Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST
determine the order in which FE DAI and BE DAI are triggered.
In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is
triggered before the BE DAI and in the case of
SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before
the FE DAI. And this order remains the same irrespective of the
trigger command.
In the case of the SOF driver, during playback, the FW
expects the BE DAI to be triggered before the FE DAI during
the START trigger. The BE DAI trigger handles the starting of
Link DMA and so it must be started before the FE DAI is started
to prevent xruns during pause/release. This can be addressed
by setting the trigger order for the FE dai link to
SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger,
the FW expects the FE DAI to be triggered before the BE DAI.
Retaining the same order during the START and STOP commands,
results in FW error as the DAI component in the FW is still
active.
The issue can be fixed by mirroring the trigger order of
FE and BE DAI's during the START and STOP trigger. So, with the
trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be
trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME
and the BE DAI will be triggered first during the
STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order
set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered
first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands
and the FE DAI will be triggered first during the
SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-05 05:48:11 +07:00
|
|
|
switch (cmd) {
|
|
|
|
case SNDRV_PCM_TRIGGER_START:
|
|
|
|
case SNDRV_PCM_TRIGGER_RESUME:
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
|
|
|
|
ret = dpcm_dai_trigger_fe_be(substream, cmd, false);
|
|
|
|
break;
|
|
|
|
case SNDRV_PCM_TRIGGER_STOP:
|
|
|
|
case SNDRV_PCM_TRIGGER_SUSPEND:
|
|
|
|
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
|
|
|
|
ret = dpcm_dai_trigger_fe_be(substream, cmd, true);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
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 18:12:49 +07:00
|
|
|
}
|
|
|
|
break;
|
2012-04-25 18:12:52 +07:00
|
|
|
case SND_SOC_DPCM_TRIGGER_BESPOKE:
|
|
|
|
/* bespoke trigger() - handles both FE and BEs */
|
|
|
|
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(fe->dev, "ASoC: bespoke trigger FE %s cmd %d\n",
|
2012-04-25 18:12:52 +07:00
|
|
|
fe->dai_link->name, cmd);
|
|
|
|
|
|
|
|
ret = soc_pcm_bespoke_trigger(substream, cmd);
|
|
|
|
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 18:12:49 +07:00
|
|
|
default:
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
fe->dai_link->name);
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
ASoC: pcm: update FE/BE trigger order based on the command
Currently, the trigger orders SND_SOC_DPCM_TRIGGER_PRE/POST
determine the order in which FE DAI and BE DAI are triggered.
In the case of SND_SOC_DPCM_TRIGGER_PRE, the FE DAI is
triggered before the BE DAI and in the case of
SND_SOC_DPCM_TRIGGER_POST, the BE DAI is triggered before
the FE DAI. And this order remains the same irrespective of the
trigger command.
In the case of the SOF driver, during playback, the FW
expects the BE DAI to be triggered before the FE DAI during
the START trigger. The BE DAI trigger handles the starting of
Link DMA and so it must be started before the FE DAI is started
to prevent xruns during pause/release. This can be addressed
by setting the trigger order for the FE dai link to
SND_SOC_DPCM_TRIGGER_POST. But during the STOP trigger,
the FW expects the FE DAI to be triggered before the BE DAI.
Retaining the same order during the START and STOP commands,
results in FW error as the DAI component in the FW is still
active.
The issue can be fixed by mirroring the trigger order of
FE and BE DAI's during the START and STOP trigger. So, with the
trigger order set to SND_SOC_DPCM_TRIGGER_PRE, the FE DAI will be
trigger first during SNDRV_PCM_TRIGGER_START/STOP/RESUME
and the BE DAI will be triggered first during the
STOP/SUSPEND/PAUSE commands. Conversely, with the trigger order
set to SND_SOC_DPCM_TRIGGER_POST, the BE DAI will be triggered
first during the SNDRV_PCM_TRIGGER_START/STOP/RESUME commands
and the FE DAI will be triggered first during the
SNDRV_PCM_TRIGGER_STOP/SUSPEND/PAUSE commands.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191104224812.3393-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-05 05:48:11 +07:00
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(fe->dev, "ASoC: trigger FE cmd: %d failed: %d\n",
|
|
|
|
cmd, ret);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
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 18:12:49 +07:00
|
|
|
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 13:44:39 +07: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 18:12:49 +07: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 22:52:28 +07: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-18 00:03:55 +07: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 18:12:49 +07:00
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
|
|
|
int ret = 0;
|
|
|
|
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
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 09:15:34 +07:00
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP) &&
|
2019-05-08 09:32:41 +07:00
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND) &&
|
|
|
|
(be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED))
|
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE and FE link management.
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 18:12:49 +07:00
|
|
|
continue;
|
|
|
|
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(be->dev, "ASoC: prepare BE %s\n",
|
2016-09-26 15:29:31 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
ret = soc_pcm_prepare(be_substream);
|
|
|
|
if (ret < 0) {
|
2012-11-19 21:39:15 +07: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 18:12:49 +07:00
|
|
|
ret);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
be->dpcm[stream].state = SND_SOC_DPCM_STATE_PREPARE;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-05-10 03:46:27 +07: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 18:12:49 +07: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 21:39:15 +07: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 18:12:49 +07: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 22:52:28 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
/* there is no point preparing this FE if there are no BEs */
|
|
|
|
if (list_empty(&fe->dpcm[stream].be_clients)) {
|
2012-11-19 21:39:15 +07: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 18:12:49 +07: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 21:39:15 +07: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 18:12:49 +07: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 22:52:28 +07: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 18:12:49 +07:00
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-04-25 18:12:51 +07:00
|
|
|
static int dpcm_run_update_shutdown(struct snd_soc_pcm_runtime *fe, int stream)
|
|
|
|
{
|
2012-04-25 18:12:52 +07: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 18:12:51 +07:00
|
|
|
int err;
|
|
|
|
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(fe->dev, "ASoC: runtime %s close on FE %s\n",
|
2012-04-25 18:12:51 +07:00
|
|
|
stream ? "capture" : "playback", fe->dai_link->name);
|
|
|
|
|
2012-04-25 18:12:52 +07:00
|
|
|
if (trigger == SND_SOC_DPCM_TRIGGER_BESPOKE) {
|
|
|
|
/* call bespoke trigger - FE takes care of all BE triggers */
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(fe->dev, "ASoC: bespoke trigger FE %s cmd stop\n",
|
2012-04-25 18:12:52 +07:00
|
|
|
fe->dai_link->name);
|
|
|
|
|
|
|
|
err = soc_pcm_bespoke_trigger(substream, SNDRV_PCM_TRIGGER_STOP);
|
|
|
|
if (err < 0)
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_err(fe->dev,"ASoC: trigger FE failed %d\n", err);
|
2012-04-25 18:12:52 +07:00
|
|
|
} else {
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(fe->dev, "ASoC: trigger FE %s cmd stop\n",
|
2012-04-25 18:12:52 +07:00
|
|
|
fe->dai_link->name);
|
|
|
|
|
|
|
|
err = dpcm_be_dai_trigger(fe, stream, SNDRV_PCM_TRIGGER_STOP);
|
|
|
|
if (err < 0)
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_err(fe->dev,"ASoC: trigger FE failed %d\n", err);
|
2012-04-25 18:12:52 +07:00
|
|
|
}
|
2012-04-25 18:12:51 +07:00
|
|
|
|
|
|
|
err = dpcm_be_dai_hw_free(fe, stream);
|
|
|
|
if (err < 0)
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_err(fe->dev,"ASoC: hw_free FE failed %d\n", err);
|
2012-04-25 18:12:51 +07:00
|
|
|
|
|
|
|
err = dpcm_be_dai_shutdown(fe, stream);
|
|
|
|
if (err < 0)
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_err(fe->dev,"ASoC: shutdown FE failed %d\n", err);
|
2012-04-25 18:12:51 +07: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 18:12:52 +07:00
|
|
|
struct snd_pcm_substream *substream =
|
|
|
|
snd_soc_dpcm_get_substream(fe, stream);
|
2012-04-25 18:12:51 +07:00
|
|
|
struct snd_soc_dpcm *dpcm;
|
2012-04-25 18:12:52 +07:00
|
|
|
enum snd_soc_dpcm_trigger trigger = fe->dai_link->trigger[stream];
|
2012-04-25 18:12:51 +07:00
|
|
|
int ret;
|
2019-03-08 12:05:53 +07:00
|
|
|
unsigned long flags;
|
2012-04-25 18:12:51 +07:00
|
|
|
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(fe->dev, "ASoC: runtime %s open on FE %s\n",
|
2012-04-25 18:12:51 +07: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 15:59:57 +07:00
|
|
|
if (ret < 0)
|
2012-04-25 18:12:51 +07: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 18:12:49 +07:00
|
|
|
|
2012-04-25 18:12:51 +07:00
|
|
|
ret = dpcm_be_dai_hw_params(fe, stream);
|
2013-01-10 15:59:57 +07:00
|
|
|
if (ret < 0)
|
2012-04-25 18:12:51 +07: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 15:59:57 +07:00
|
|
|
if (ret < 0)
|
2012-04-25 18:12:51 +07: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 18:12:52 +07:00
|
|
|
if (trigger == SND_SOC_DPCM_TRIGGER_BESPOKE) {
|
|
|
|
/* call trigger on the frontend - FE takes care of all BE triggers */
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(fe->dev, "ASoC: bespoke trigger FE %s cmd start\n",
|
2012-04-25 18:12:52 +07:00
|
|
|
fe->dai_link->name);
|
2012-04-25 18:12:51 +07:00
|
|
|
|
2012-04-25 18:12:52 +07:00
|
|
|
ret = soc_pcm_bespoke_trigger(substream, SNDRV_PCM_TRIGGER_START);
|
|
|
|
if (ret < 0) {
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_err(fe->dev,"ASoC: bespoke trigger FE failed %d\n", ret);
|
2012-04-25 18:12:52 +07:00
|
|
|
goto hw_free;
|
|
|
|
}
|
|
|
|
} else {
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(fe->dev, "ASoC: trigger FE %s cmd start\n",
|
2012-04-25 18:12:52 +07:00
|
|
|
fe->dai_link->name);
|
|
|
|
|
|
|
|
ret = dpcm_be_dai_trigger(fe, stream,
|
|
|
|
SNDRV_PCM_TRIGGER_START);
|
|
|
|
if (ret < 0) {
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_err(fe->dev,"ASoC: trigger FE failed %d\n", ret);
|
2012-04-25 18:12:52 +07:00
|
|
|
goto hw_free;
|
|
|
|
}
|
2012-04-25 18:12:51 +07: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 */
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_lock_irqsave(&fe->card->dpcm_lock, flags);
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
2012-04-25 18:12:51 +07:00
|
|
|
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;
|
|
|
|
}
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_unlock_irqrestore(&fe->card->dpcm_lock, flags);
|
2012-04-25 18:12:51 +07:00
|
|
|
|
|
|
|
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 22:52:28 +07:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_BE);
|
2012-04-25 18:12:51 +07:00
|
|
|
ret = dpcm_run_update_startup(fe, stream);
|
|
|
|
if (ret < 0)
|
2012-11-19 21:39:15 +07: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 22:52:28 +07:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
2012-04-25 18:12:51 +07: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 22:52:28 +07:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_BE);
|
2012-04-25 18:12:51 +07:00
|
|
|
ret = dpcm_run_update_shutdown(fe, stream);
|
|
|
|
if (ret < 0)
|
2012-11-19 21:39:15 +07: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 22:52:28 +07:00
|
|
|
dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO);
|
2012-04-25 18:12:51 +07: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 17:07:25 +07:00
|
|
|
static int soc_dpcm_fe_runtime_update(struct snd_soc_pcm_runtime *fe, int new)
|
2012-04-25 18:12:51 +07: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 17:07:25 +07:00
|
|
|
struct snd_soc_dapm_widget_list *list;
|
|
|
|
int count, paths;
|
2012-04-25 18:12:51 +07: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 17:07:25 +07:00
|
|
|
if (!fe->dai_link->dynamic)
|
|
|
|
return 0;
|
2012-04-25 18:12:51 +07: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 17:07:25 +07:00
|
|
|
/* only check active links */
|
|
|
|
if (!fe->cpu_dai->active)
|
|
|
|
return 0;
|
2012-04-25 18:12:51 +07: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 17:07:25 +07: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 18:12:51 +07: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 17:07:25 +07:00
|
|
|
/* skip if FE doesn't have playback capability */
|
2019-07-22 08:36:16 +07:00
|
|
|
if (!snd_soc_dai_stream_valid(fe->cpu_dai, SNDRV_PCM_STREAM_PLAYBACK) ||
|
|
|
|
!snd_soc_dai_stream_valid(fe->codec_dai, 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 17:07:25 +07:00
|
|
|
goto capture;
|
2012-04-25 18:12:51 +07: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 17:07:25 +07:00
|
|
|
/* skip if FE isn't currently playing */
|
|
|
|
if (!fe->cpu_dai->playback_active || !fe->codec_dai->playback_active)
|
|
|
|
goto capture;
|
2012-04-25 18:12:51 +07: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 17:07:25 +07: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 18:12:51 +07: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 17:07:25 +07: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 18:12:51 +07: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 17:07:25 +07: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 18:12:51 +07: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 17:07:25 +07:00
|
|
|
/* skip if FE doesn't have capture capability */
|
2019-07-22 08:36:16 +07:00
|
|
|
if (!snd_soc_dai_stream_valid(fe->cpu_dai, SNDRV_PCM_STREAM_CAPTURE) ||
|
|
|
|
!snd_soc_dai_stream_valid(fe->codec_dai, 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 17:07:25 +07:00
|
|
|
return 0;
|
2014-11-17 15:02:57 +07: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 17:07:25 +07:00
|
|
|
/* skip if FE isn't currently capturing */
|
|
|
|
if (!fe->cpu_dai->capture_active || !fe->codec_dai->capture_active)
|
|
|
|
return 0;
|
2012-04-25 18:12:51 +07: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 17:07:25 +07: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 18:12:51 +07: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 17:07:25 +07:00
|
|
|
/* update any old capture paths */
|
|
|
|
count = dpcm_process_paths(fe, SNDRV_PCM_STREAM_CAPTURE, &list, new);
|
|
|
|
if (count) {
|
|
|
|
if (new)
|
2012-04-25 18:12:51 +07: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 17:07:25 +07:00
|
|
|
else
|
2012-04-25 18:12:51 +07: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 17:07:25 +07:00
|
|
|
dpcm_clear_pending_state(fe, SNDRV_PCM_STREAM_CAPTURE);
|
|
|
|
dpcm_be_disconnect(fe, SNDRV_PCM_STREAM_CAPTURE);
|
2012-04-25 18:12:51 +07: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 17:07:25 +07:00
|
|
|
dpcm_path_put(&list);
|
|
|
|
|
2012-04-25 18:12:51 +07: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 17:07:25 +07: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 */
|
2018-09-18 08:29:35 +07:00
|
|
|
for_each_card_rtds(card, fe) {
|
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 17:07:25 +07:00
|
|
|
ret = soc_dpcm_fe_runtime_update(fe, 0);
|
|
|
|
if (ret)
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* bring new paths up */
|
2018-09-18 08:29:35 +07:00
|
|
|
for_each_card_rtds(card, fe) {
|
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 17:07:25 +07:00
|
|
|
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 18:12:49 +07:00
|
|
|
int soc_dpcm_be_digital_mute(struct snd_soc_pcm_runtime *fe, int mute)
|
|
|
|
{
|
|
|
|
struct snd_soc_dpcm *dpcm;
|
2018-09-18 08:28:04 +07:00
|
|
|
struct snd_soc_dai *dai;
|
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 18:12:49 +07:00
|
|
|
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, SNDRV_PCM_STREAM_PLAYBACK, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
struct snd_soc_pcm_runtime *be = dpcm->be;
|
2014-07-09 04:19:35 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
if (be->dai_link->ignore_suspend)
|
|
|
|
continue;
|
|
|
|
|
2018-09-18 08:28:04 +07:00
|
|
|
for_each_rtd_codec_dai(be, i, dai) {
|
2014-07-09 04:19:35 +07:00
|
|
|
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 18:12:49 +07:00
|
|
|
|
2014-07-09 04:19:35 +07: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 18:12:49 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-05-10 03:46:27 +07: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 18:12:49 +07: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 16:54:07 +07: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 21:39:15 +07: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 18:12:49 +07: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 */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm)
|
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 18:12:49 +07:00
|
|
|
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-10 03:46:27 +07: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 18:12:49 +07: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 */
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm)
|
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 18:12:49 +07:00
|
|
|
dpcm->state = SND_SOC_DPCM_LINK_STATE_FREE;
|
|
|
|
|
|
|
|
dpcm_be_disconnect(fe, stream);
|
|
|
|
|
|
|
|
fe->dpcm[stream].runtime = NULL;
|
|
|
|
mutex_unlock(&fe->card->mutex);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-06-09 20:45:53 +07:00
|
|
|
/* create a new pcm */
|
|
|
|
int soc_new_pcm(struct snd_soc_pcm_runtime *rtd, int num)
|
|
|
|
{
|
2014-07-09 04:19:35 +07:00
|
|
|
struct snd_soc_dai *codec_dai;
|
2011-06-09 20:45:53 +07:00
|
|
|
struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
|
ASoC: soc-core: add for_each_rtd_components() and replace
ALSA SoC has for_each_rtdcom() which is link list for
rtd-component which is called as rtdcom. The relationship image is like below
rtdcom rtdcom rtdcom
component component component
rtd->component_list -> list -> list -> list ...
Here, the pointer get via normal link list is rtdcom,
Thus, current for_each loop is like below, and need to get
component via rtdcom->component
for_each_rtdcom(rtd, rtdcom) {
component = rtdcom->component;
...
}
but usually, user want to get pointer from for_each_xxx is component
directly, like below.
for_each_rtd_component(rtd, rtdcom, component) {
...
}
This patch expands list_for_each_entry manually, and enable to get
component directly from for_each macro.
Because of it, the macro becoming difficult to read,
but macro itself becoming useful.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878spm64m4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-15 10:59:31 +07:00
|
|
|
struct snd_soc_component *component;
|
2011-06-09 20:45:53 +07:00
|
|
|
struct snd_pcm *pcm;
|
|
|
|
char new_name[64];
|
|
|
|
int ret = 0, playback = 0, capture = 0;
|
2014-07-09 04:19:35 +07:00
|
|
|
int i;
|
2011-06-09 20:45:53 +07: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 18:12:49 +07:00
|
|
|
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
|
2014-01-08 00:51:42 +07: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 18:12:49 +07:00
|
|
|
} else {
|
2019-07-25 23:59:47 +07:00
|
|
|
/* Adapt stream for codec2codec links */
|
|
|
|
struct snd_soc_pcm_stream *cpu_capture = rtd->dai_link->params ?
|
|
|
|
&cpu_dai->driver->playback : &cpu_dai->driver->capture;
|
|
|
|
struct snd_soc_pcm_stream *cpu_playback = rtd->dai_link->params ?
|
|
|
|
&cpu_dai->driver->capture : &cpu_dai->driver->playback;
|
|
|
|
|
2018-09-03 09:12:56 +07:00
|
|
|
for_each_rtd_codec_dai(rtd, i, codec_dai) {
|
2019-07-22 08:36:16 +07:00
|
|
|
if (snd_soc_dai_stream_valid(codec_dai, SNDRV_PCM_STREAM_PLAYBACK) &&
|
2020-01-19 21:19:23 +07:00
|
|
|
snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_CAPTURE))
|
2014-07-09 04:19:35 +07:00
|
|
|
playback = 1;
|
2019-07-22 08:36:16 +07:00
|
|
|
if (snd_soc_dai_stream_valid(codec_dai, SNDRV_PCM_STREAM_CAPTURE) &&
|
2020-01-19 21:19:23 +07:00
|
|
|
snd_soc_dai_stream_valid(cpu_dai, SNDRV_PCM_STREAM_PLAYBACK))
|
2014-07-09 04:19:35 +07:00
|
|
|
capture = 1;
|
|
|
|
}
|
2019-07-25 23:59:47 +07:00
|
|
|
|
|
|
|
capture = capture && cpu_capture->channels_min;
|
|
|
|
playback = playback && cpu_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 18:12:49 +07:00
|
|
|
}
|
|
|
|
|
2013-08-29 20:32:13 +07: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 18:12:49 +07:00
|
|
|
/* create the PCM */
|
2019-07-25 23:59:47 +07:00
|
|
|
if (rtd->dai_link->params) {
|
|
|
|
snprintf(new_name, sizeof(new_name), "codec2codec(%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->no_pcm) {
|
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 18:12:49 +07:00
|
|
|
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-09 04:19:35 +07: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 18:12:49 +07:00
|
|
|
|
|
|
|
ret = snd_pcm_new(rtd->card->snd_card, new_name, num, playback,
|
|
|
|
capture, &pcm);
|
|
|
|
}
|
2011-06-09 20:45:53 +07:00
|
|
|
if (ret < 0) {
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_err(rtd->card->dev, "ASoC: can't create pcm for %s\n",
|
2012-07-06 22:54:52 +07:00
|
|
|
rtd->dai_link->name);
|
2011-06-09 20:45:53 +07:00
|
|
|
return ret;
|
|
|
|
}
|
2012-11-19 21:39:15 +07:00
|
|
|
dev_dbg(rtd->card->dev, "ASoC: registered pcm #%d %s\n",num, new_name);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
|
|
|
/* DAPM dai link stream work */
|
2019-07-25 23:59:47 +07:00
|
|
|
if (rtd->dai_link->params)
|
2019-12-04 00:30:07 +07:00
|
|
|
rtd->close_delayed_work_func = codec2codec_close_delayed_work;
|
2019-07-25 23:59:47 +07:00
|
|
|
else
|
2020-01-10 09:36:17 +07:00
|
|
|
rtd->close_delayed_work_func = snd_soc_close_delayed_work;
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2015-02-12 11:29:53 +07:00
|
|
|
pcm->nonatomic = rtd->dai_link->nonatomic;
|
2011-06-09 20:45:53 +07: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 18:12:49 +07:00
|
|
|
|
2019-07-25 23:59:47 +07:00
|
|
|
if (rtd->dai_link->no_pcm || rtd->dai_link->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 18:12:49 +07:00
|
|
|
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;
|
|
|
|
} 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;
|
|
|
|
}
|
|
|
|
|
ASoC: soc-core: remove snd_soc_rtdcom_list
Current ALSA SoC is using struct snd_soc_rtdcom_list to
connecting component to rtd by using list_head.
struct snd_soc_rtdcom_list {
struct snd_soc_component *component;
struct list_head list; /* rtd::component_list */
};
struct snd_soc_pcm_runtime {
...
struct list_head component_list; /* list of connected components */
...
};
The CPU/Codec/Platform component which will be connected to rtd (a)
is indicated via dai_link at snd_soc_add_pcm_runtime()
int snd_soc_add_pcm_runtime(...)
{
...
/* Find CPU from registered CPUs */
rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
...
(a) snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
...
/* Find CODEC from registered CODECs */
(b) for_each_link_codecs(dai_link, i, codec) {
rtd->codec_dais[i] = snd_soc_find_dai(codec);
...
(a) snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
}
...
/* Find PLATFORM from registered PLATFORMs */
(b) for_each_link_platforms(dai_link, i, platform) {
for_each_component(component) {
...
(a) snd_soc_rtdcom_add(rtd, component);
}
}
}
It shows, it is possible to know how many components will be
connected to rtd by using
dai_link->num_cpus
dai_link->num_codecs
dai_link->num_platforms
If so, we can use component pointer array instead of list_head,
in such case, code can be more simple.
This patch removes struct snd_soc_rtdcom_list that is only
of temporary value, and convert to pointer array.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-By: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-10 09:35:21 +07:00
|
|
|
for_each_rtd_components(rtd, i, component) {
|
ASoC: soc-core: add for_each_rtd_components() and replace
ALSA SoC has for_each_rtdcom() which is link list for
rtd-component which is called as rtdcom. The relationship image is like below
rtdcom rtdcom rtdcom
component component component
rtd->component_list -> list -> list -> list ...
Here, the pointer get via normal link list is rtdcom,
Thus, current for_each loop is like below, and need to get
component via rtdcom->component
for_each_rtdcom(rtd, rtdcom) {
component = rtdcom->component;
...
}
but usually, user want to get pointer from for_each_xxx is component
directly, like below.
for_each_rtd_component(rtd, rtdcom, component) {
...
}
This patch expands list_for_each_entry manually, and enable to get
component directly from for_each macro.
Because of it, the macro becoming difficult to read,
but macro itself becoming useful.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878spm64m4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-15 10:59:31 +07:00
|
|
|
const struct snd_soc_component_driver *drv = component->driver;
|
2017-10-11 08:37:23 +07:00
|
|
|
|
2019-11-22 02:07:08 +07:00
|
|
|
if (drv->ioctl)
|
|
|
|
rtd->ops.ioctl = snd_soc_pcm_component_ioctl;
|
2019-11-22 02:07:09 +07:00
|
|
|
if (drv->sync_stop)
|
|
|
|
rtd->ops.sync_stop = snd_soc_pcm_component_sync_stop;
|
2019-10-02 12:35:13 +07:00
|
|
|
if (drv->copy_user)
|
2019-07-26 11:51:56 +07:00
|
|
|
rtd->ops.copy_user = snd_soc_pcm_component_copy_user;
|
2019-10-02 12:35:13 +07:00
|
|
|
if (drv->page)
|
2019-07-26 11:52:00 +07:00
|
|
|
rtd->ops.page = snd_soc_pcm_component_page;
|
2019-10-02 12:35:13 +07:00
|
|
|
if (drv->mmap)
|
2019-07-26 11:52:04 +07:00
|
|
|
rtd->ops.mmap = snd_soc_pcm_component_mmap;
|
2011-06-09 20:45:53 +07: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 18:12:49 +07:00
|
|
|
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &rtd->ops);
|
2011-06-09 20:45:53 +07: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 18:12:49 +07:00
|
|
|
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &rtd->ops);
|
2011-06-09 20:45:53 +07:00
|
|
|
|
2019-11-18 08:50:32 +07:00
|
|
|
ret = snd_soc_pcm_component_new(rtd);
|
2019-07-26 11:52:08 +07:00
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(rtd->dev, "ASoC: pcm constructor failed: %d\n", ret);
|
|
|
|
return ret;
|
2011-06-09 20:45:53 +07:00
|
|
|
}
|
2017-07-12 22:55:29 +07:00
|
|
|
|
2019-01-11 21:58:39 +07:00
|
|
|
pcm->no_device_suspend = true;
|
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 18:12:49 +07:00
|
|
|
out:
|
2014-07-09 04:19:35 +07: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 20:45:53 +07: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 18:12:49 +07: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;
|
2019-03-08 12:05:53 +07:00
|
|
|
int ret = 1;
|
|
|
|
unsigned long flags;
|
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 18:12:49 +07:00
|
|
|
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_lock_irqsave(&fe->card->dpcm_lock, flags);
|
2018-09-18 08:30:54 +07:00
|
|
|
for_each_dpcm_fe(be, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
if (dpcm->fe == fe)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
state = dpcm->fe->dpcm[stream].state;
|
|
|
|
if (state == SND_SOC_DPCM_STATE_START ||
|
|
|
|
state == SND_SOC_DPCM_STATE_PAUSED ||
|
2019-03-08 12:05:53 +07:00
|
|
|
state == SND_SOC_DPCM_STATE_SUSPEND) {
|
|
|
|
ret = 0;
|
|
|
|
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 18:12:49 +07:00
|
|
|
}
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_unlock_irqrestore(&fe->card->dpcm_lock, flags);
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
/* it's safe to free/stop this BE DAI */
|
2019-03-08 12:05:53 +07: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 18:12:49 +07:00
|
|
|
}
|
|
|
|
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;
|
2019-03-08 12:05:53 +07:00
|
|
|
int ret = 1;
|
|
|
|
unsigned long flags;
|
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 18:12:49 +07:00
|
|
|
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_lock_irqsave(&fe->card->dpcm_lock, flags);
|
2018-09-18 08:30:54 +07:00
|
|
|
for_each_dpcm_fe(be, stream, dpcm) {
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
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 ||
|
2019-03-08 12:05:53 +07:00
|
|
|
state == SND_SOC_DPCM_STATE_PREPARE) {
|
|
|
|
ret = 0;
|
|
|
|
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 18:12:49 +07:00
|
|
|
}
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_unlock_irqrestore(&fe->card->dpcm_lock, flags);
|
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 18:12:49 +07:00
|
|
|
|
|
|
|
/* it's safe to change hw_params */
|
2019-03-08 12:05:53 +07: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 18:12:49 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(snd_soc_dpcm_can_be_params);
|
2012-04-25 18:12:50 +07:00
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_FS
|
2016-11-22 17:29:14 +07:00
|
|
|
static const char *dpcm_state_string(enum snd_soc_dpcm_state state)
|
2012-04-25 18:12:50 +07: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;
|
2019-03-08 12:05:53 +07:00
|
|
|
unsigned long flags;
|
2012-04-25 18:12:50 +07:00
|
|
|
|
|
|
|
/* 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;
|
|
|
|
}
|
|
|
|
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_lock_irqsave(&fe->card->dpcm_lock, flags);
|
2018-09-18 08:31:09 +07:00
|
|
|
for_each_dpcm_be(fe, stream, dpcm) {
|
2012-04-25 18:12:50 +07:00
|
|
|
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));
|
|
|
|
}
|
2019-03-08 12:05:53 +07:00
|
|
|
spin_unlock_irqrestore(&fe->card->dpcm_lock, flags);
|
2012-04-25 18:12:50 +07:00
|
|
|
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;
|
|
|
|
|
2019-07-22 08:36:16 +07:00
|
|
|
if (snd_soc_dai_stream_valid(fe->cpu_dai, SNDRV_PCM_STREAM_PLAYBACK))
|
2012-04-25 18:12:50 +07:00
|
|
|
offset += dpcm_show_state(fe, SNDRV_PCM_STREAM_PLAYBACK,
|
|
|
|
buf + offset, out_count - offset);
|
|
|
|
|
2019-07-22 08:36:16 +07:00
|
|
|
if (snd_soc_dai_stream_valid(fe->cpu_dai, SNDRV_PCM_STREAM_CAPTURE))
|
2012-04-25 18:12:50 +07:00
|
|
|
offset += dpcm_show_state(fe, SNDRV_PCM_STREAM_CAPTURE,
|
|
|
|
buf + offset, out_count - offset);
|
|
|
|
|
2012-04-27 17:33:46 +07:00
|
|
|
ret = simple_read_from_buffer(user_buf, count, ppos, buf, offset);
|
2012-04-25 18:12:50 +07:00
|
|
|
|
2012-04-27 17:33:46 +07:00
|
|
|
kfree(buf);
|
|
|
|
return ret;
|
2012-04-25 18:12:50 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct file_operations dpcm_state_fops = {
|
2012-04-27 17:33:46 +07:00
|
|
|
.open = simple_open,
|
2012-04-25 18:12:50 +07:00
|
|
|
.read = dpcm_state_read_file,
|
|
|
|
.llseek = default_llseek,
|
|
|
|
};
|
|
|
|
|
2015-04-09 15:52:37 +07:00
|
|
|
void soc_dpcm_debugfs_add(struct snd_soc_pcm_runtime *rtd)
|
2012-04-25 18:12:50 +07:00
|
|
|
{
|
2012-05-08 16:33:47 +07:00
|
|
|
if (!rtd->dai_link)
|
2015-04-09 15:52:37 +07:00
|
|
|
return;
|
2012-05-08 16:33:47 +07:00
|
|
|
|
2019-08-07 08:31:36 +07:00
|
|
|
if (!rtd->dai_link->dynamic)
|
|
|
|
return;
|
|
|
|
|
2015-04-09 15:52:38 +07:00
|
|
|
if (!rtd->card->debugfs_card_root)
|
|
|
|
return;
|
2012-05-08 16:33:47 +07:00
|
|
|
|
2012-04-25 18:12:50 +07:00
|
|
|
rtd->debugfs_dpcm_root = debugfs_create_dir(rtd->dai_link->name,
|
|
|
|
rtd->card->debugfs_card_root);
|
|
|
|
|
2017-07-29 21:40:55 +07:00
|
|
|
debugfs_create_file("state", 0444, rtd->debugfs_dpcm_root,
|
|
|
|
rtd, &dpcm_state_fops);
|
2012-04-25 18:12:50 +07:00
|
|
|
}
|
|
|
|
#endif
|