WSL2-Linux-Kernel/include/sound/soc-dpcm.h

174 строки
5.5 KiB
C
Исходник Обычный вид История

/* SPDX-License-Identifier: GPL-2.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 15:12:49 +04:00
* linux/sound/soc-dpcm.h -- ALSA SoC Dynamic PCM Support
*
* Author: Liam Girdwood <lrg@ti.com>
*/
#ifndef __LINUX_SND_SOC_DPCM_H
#define __LINUX_SND_SOC_DPCM_H
#include <linux/slab.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 15:12:49 +04:00
#include <linux/list.h>
#include <sound/pcm.h>
struct snd_soc_pcm_runtime;
/*
* Types of runtime_update to perform. e.g. originated from FE PCM ops
* or audio route changes triggered by muxes/mixers.
*/
enum snd_soc_dpcm_update {
SND_SOC_DPCM_UPDATE_NO = 0,
SND_SOC_DPCM_UPDATE_BE,
SND_SOC_DPCM_UPDATE_FE,
};
/*
* Dynamic PCM Frontend -> Backend link management states.
*/
enum snd_soc_dpcm_link_state {
SND_SOC_DPCM_LINK_STATE_NEW = 0, /* newly created link */
SND_SOC_DPCM_LINK_STATE_FREE, /* link to be dismantled */
};
/*
* Dynamic PCM Frontend -> Backend link PCM states.
*/
enum snd_soc_dpcm_state {
SND_SOC_DPCM_STATE_NEW = 0,
SND_SOC_DPCM_STATE_OPEN,
SND_SOC_DPCM_STATE_HW_PARAMS,
SND_SOC_DPCM_STATE_PREPARE,
SND_SOC_DPCM_STATE_START,
SND_SOC_DPCM_STATE_STOP,
SND_SOC_DPCM_STATE_PAUSED,
SND_SOC_DPCM_STATE_SUSPEND,
SND_SOC_DPCM_STATE_HW_FREE,
SND_SOC_DPCM_STATE_CLOSE,
};
/*
* Dynamic PCM trigger ordering. Triggering flexibility is required as some
* DSPs require triggering before/after their CPU platform and DAIs.
*
* i.e. some clients may want to manually order this call in their PCM
* trigger() whilst others will just use the regular core ordering.
*/
enum snd_soc_dpcm_trigger {
SND_SOC_DPCM_TRIGGER_PRE = 0,
SND_SOC_DPCM_TRIGGER_POST,
SND_SOC_DPCM_TRIGGER_BESPOKE,
ASoC: dpcm: Add Dynamic PCM core operations. The Dynamic PCM core allows digital audio data to be dynamically routed between different ALSA PCMs and DAI links on SoC CPUs with on chip DSP devices. e.g. audio data could be played on pcm:0,0 and routed to any (or all) SoC DAI links. Dynamic PCM introduces the concept of Front End (FE) PCMs and Back End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that they can dynamically route digital audio data to any supported BE PCM. A BE PCM has no ALSA device, but represents a DAI link and it's substream and audio HW parameters. e.g. pcm:0,0 routing digital data to 2 external codecs. FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0 +--> BE (McPDM.0) ----> CODEC 1 e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec. FE pcm:0,0 --- +--> BE (McBSP.0) ----> CODEC FE pcm:0,1 --- The digital audio routing is controlled by the usual ALSA method of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the routing based upon the mixer settings and configures the BE PCMs based on routing and the FE HW params. DPCM is designed so that most ASoC component drivers will need no modification at all. It's intended that existing CODEC, DAI and platform drivers can be used in DPCM based audio devices without any changes. However, there will be some cases where minor changes are required (e.g. for very tightly coupled HW) and there are helpers to support this too. Somethimes the HW params of a FE and BE do not match or are incompatible, so in these cases the machine driver can reconfigure any hw_params and make any DSP perform sample rate / format conversion. This patch adds the core DPCM code and contains :- o The FE and BE PCM operations. o FE and BE DAI link support. o FE and BE PCM creation. o BE support API. o BE and FE link management. Signed-off-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 15:12:49 +04:00
};
/*
* Dynamic PCM link
* This links together a FE and BE DAI at runtime and stores the link
* state information and the hw_params configuration.
*/
struct snd_soc_dpcm {
/* FE and BE DAIs*/
struct snd_soc_pcm_runtime *be;
struct snd_soc_pcm_runtime *fe;
/* link state */
enum snd_soc_dpcm_link_state state;
/* list of BE and FE for this DPCM link */
struct list_head list_be;
struct list_head list_fe;
#ifdef CONFIG_DEBUG_FS
struct dentry *debugfs_state;
#endif
ASoC: dpcm: Add Dynamic PCM core operations. The Dynamic PCM core allows digital audio data to be dynamically routed between different ALSA PCMs and DAI links on SoC CPUs with on chip DSP devices. e.g. audio data could be played on pcm:0,0 and routed to any (or all) SoC DAI links. Dynamic PCM introduces the concept of Front End (FE) PCMs and Back End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that they can dynamically route digital audio data to any supported BE PCM. A BE PCM has no ALSA device, but represents a DAI link and it's substream and audio HW parameters. e.g. pcm:0,0 routing digital data to 2 external codecs. FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0 +--> BE (McPDM.0) ----> CODEC 1 e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec. FE pcm:0,0 --- +--> BE (McBSP.0) ----> CODEC FE pcm:0,1 --- The digital audio routing is controlled by the usual ALSA method of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the routing based upon the mixer settings and configures the BE PCMs based on routing and the FE HW params. DPCM is designed so that most ASoC component drivers will need no modification at all. It's intended that existing CODEC, DAI and platform drivers can be used in DPCM based audio devices without any changes. However, there will be some cases where minor changes are required (e.g. for very tightly coupled HW) and there are helpers to support this too. Somethimes the HW params of a FE and BE do not match or are incompatible, so in these cases the machine driver can reconfigure any hw_params and make any DSP perform sample rate / format conversion. This patch adds the core DPCM code and contains :- o The FE and BE PCM operations. o FE and BE DAI link support. o FE and BE PCM creation. o BE support API. o BE and FE link management. Signed-off-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 15:12:49 +04:00
};
/*
* Dynamic PCM runtime data.
*/
struct snd_soc_dpcm_runtime {
struct list_head be_clients;
struct list_head fe_clients;
int users;
struct snd_pcm_runtime *runtime;
struct snd_pcm_hw_params hw_params;
/* state and update */
enum snd_soc_dpcm_update runtime_update;
enum snd_soc_dpcm_state state;
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 18:52:28 +03:00
int trigger_pending; /* trigger cmd + 1 if pending, 0 if not */
int be_start; /* refcount protected by BE stream pcm lock */
ASoC: soc-pcm: improve BE transition for PAUSE_RELEASE Commit 3aa1e96a2b95 ("ASoC: soc-pcm: fix BE handling of PAUSE_RELEASE") did not modify the existing logic and kept the same logic for the following transition play FE1 -> BE state is START pause FE1 -> BE state is PAUSED play FE2 -> BE state is START stop FE2 -> BE state is STOP <<< !! release FE1 -> BE state is START stop FE1 -> BE state is STOP At the time it was identified by reviewers that a better solution might consist in play FE1 -> BE state is START pause FE1 -> BE state is PAUSED play FE2 -> BE state is START stop FE2 -> BE state is PAUSE <<< !! release FE1 -> BE state is START stop FE1 -> BE state is STOP This patch suggest a transition to PAUSE when all the 'active' streams are paused. This would allow for a more consistent resource management for platforms where PAUSE and STOP are handled differently. To track the special case of an FE going from PAUSE_PUSH to STOP, we add a state variable for each FE context. This 'fe_pause' boolean is set on PAUSE_PUSH and cleared on either PAUSE_RELEASE and STOP triggers. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220406190056.233481-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-06 22:00:55 +03:00
int be_pause; /* refcount protected by BE stream pcm lock */
bool fe_pause; /* used to track STOP after PAUSE */
ASoC: dpcm: Add Dynamic PCM core operations. The Dynamic PCM core allows digital audio data to be dynamically routed between different ALSA PCMs and DAI links on SoC CPUs with on chip DSP devices. e.g. audio data could be played on pcm:0,0 and routed to any (or all) SoC DAI links. Dynamic PCM introduces the concept of Front End (FE) PCMs and Back End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that they can dynamically route digital audio data to any supported BE PCM. A BE PCM has no ALSA device, but represents a DAI link and it's substream and audio HW parameters. e.g. pcm:0,0 routing digital data to 2 external codecs. FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0 +--> BE (McPDM.0) ----> CODEC 1 e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec. FE pcm:0,0 --- +--> BE (McBSP.0) ----> CODEC FE pcm:0,1 --- The digital audio routing is controlled by the usual ALSA method of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the routing based upon the mixer settings and configures the BE PCMs based on routing and the FE HW params. DPCM is designed so that most ASoC component drivers will need no modification at all. It's intended that existing CODEC, DAI and platform drivers can be used in DPCM based audio devices without any changes. However, there will be some cases where minor changes are required (e.g. for very tightly coupled HW) and there are helpers to support this too. Somethimes the HW params of a FE and BE do not match or are incompatible, so in these cases the machine driver can reconfigure any hw_params and make any DSP perform sample rate / format conversion. This patch adds the core DPCM code and contains :- o The FE and BE PCM operations. o FE and BE DAI link support. o FE and BE PCM creation. o BE support API. o BE and FE link management. Signed-off-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 15:12:49 +04:00
};
#define for_each_dpcm_fe(be, stream, _dpcm) \
list_for_each_entry(_dpcm, &(be)->dpcm[stream].fe_clients, list_fe)
#define for_each_dpcm_be(fe, stream, _dpcm) \
list_for_each_entry(_dpcm, &(fe)->dpcm[stream].be_clients, list_be)
#define for_each_dpcm_be_safe(fe, stream, _dpcm, __dpcm) \
list_for_each_entry_safe(_dpcm, __dpcm, &(fe)->dpcm[stream].be_clients, list_be)
#define for_each_dpcm_be_rollback(fe, stream, _dpcm) \
list_for_each_entry_continue_reverse(_dpcm, &(fe)->dpcm[stream].be_clients, list_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 15:12:49 +04:00
/* can this BE stop and free */
int snd_soc_dpcm_can_be_free_stop(struct snd_soc_pcm_runtime *fe,
struct snd_soc_pcm_runtime *be, int stream);
/* can this BE perform a hw_params() */
int snd_soc_dpcm_can_be_params(struct snd_soc_pcm_runtime *fe,
struct snd_soc_pcm_runtime *be, int stream);
/* is the current PCM operation for this FE ? */
int snd_soc_dpcm_fe_can_update(struct snd_soc_pcm_runtime *fe, int stream);
/* 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);
/* get the substream for this BE */
struct snd_pcm_substream *
snd_soc_dpcm_get_substream(struct snd_soc_pcm_runtime *be, int stream);
/* update audio routing between PCMs and any DAI links */
int snd_soc_dpcm_runtime_update(struct snd_soc_card *card);
ASoC: dpcm: Add Dynamic PCM core operations. The Dynamic PCM core allows digital audio data to be dynamically routed between different ALSA PCMs and DAI links on SoC CPUs with on chip DSP devices. e.g. audio data could be played on pcm:0,0 and routed to any (or all) SoC DAI links. Dynamic PCM introduces the concept of Front End (FE) PCMs and Back End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that they can dynamically route digital audio data to any supported BE PCM. A BE PCM has no ALSA device, but represents a DAI link and it's substream and audio HW parameters. e.g. pcm:0,0 routing digital data to 2 external codecs. FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0 +--> BE (McPDM.0) ----> CODEC 1 e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec. FE pcm:0,0 --- +--> BE (McBSP.0) ----> CODEC FE pcm:0,1 --- The digital audio routing is controlled by the usual ALSA method of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the routing based upon the mixer settings and configures the BE PCMs based on routing and the FE HW params. DPCM is designed so that most ASoC component drivers will need no modification at all. It's intended that existing CODEC, DAI and platform drivers can be used in DPCM based audio devices without any changes. However, there will be some cases where minor changes are required (e.g. for very tightly coupled HW) and there are helpers to support this too. Somethimes the HW params of a FE and BE do not match or are incompatible, so in these cases the machine driver can reconfigure any hw_params and make any DSP perform sample rate / format conversion. This patch adds the core DPCM code and contains :- o The FE and BE PCM operations. o FE and BE DAI link support. o FE and BE PCM creation. o BE support API. o BE and FE link management. Signed-off-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 15:12:49 +04:00
#ifdef CONFIG_DEBUG_FS
void soc_dpcm_debugfs_add(struct snd_soc_pcm_runtime *rtd);
#else
static inline void soc_dpcm_debugfs_add(struct snd_soc_pcm_runtime *rtd)
{
}
#endif
int dpcm_path_get(struct snd_soc_pcm_runtime *fe,
int stream, struct snd_soc_dapm_widget_list **list_);
void dpcm_path_put(struct snd_soc_dapm_widget_list **list);
int dpcm_process_paths(struct snd_soc_pcm_runtime *fe,
int stream, struct snd_soc_dapm_widget_list **list, int new);
int dpcm_be_dai_startup(struct snd_soc_pcm_runtime *fe, int stream);
void dpcm_be_dai_stop(struct snd_soc_pcm_runtime *fe, int stream,
int do_hw_free, struct snd_soc_dpcm *last);
void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream);
void dpcm_clear_pending_state(struct snd_soc_pcm_runtime *fe, int stream);
void dpcm_be_dai_hw_free(struct snd_soc_pcm_runtime *fe, int stream);
int dpcm_be_dai_hw_params(struct snd_soc_pcm_runtime *fe, int tream);
int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime *fe, int stream, int cmd);
int dpcm_be_dai_prepare(struct snd_soc_pcm_runtime *fe, int stream);
int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir,
int event);
bool dpcm_end_walk_at_be(struct snd_soc_dapm_widget *widget, enum snd_soc_dapm_direction dir);
int widget_in_list(struct snd_soc_dapm_widget_list *list,
struct snd_soc_dapm_widget *widget);
#define dpcm_be_dai_startup_rollback(fe, stream, last) \
dpcm_be_dai_stop(fe, stream, 0, last)
#define dpcm_be_dai_startup_unwind(fe, stream) dpcm_be_dai_stop(fe, stream, 0, NULL)
#define dpcm_be_dai_shutdown(fe, stream) dpcm_be_dai_stop(fe, stream, 1, NULL)
ASoC: dpcm: Add Dynamic PCM core operations. The Dynamic PCM core allows digital audio data to be dynamically routed between different ALSA PCMs and DAI links on SoC CPUs with on chip DSP devices. e.g. audio data could be played on pcm:0,0 and routed to any (or all) SoC DAI links. Dynamic PCM introduces the concept of Front End (FE) PCMs and Back End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that they can dynamically route digital audio data to any supported BE PCM. A BE PCM has no ALSA device, but represents a DAI link and it's substream and audio HW parameters. e.g. pcm:0,0 routing digital data to 2 external codecs. FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0 +--> BE (McPDM.0) ----> CODEC 1 e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec. FE pcm:0,0 --- +--> BE (McBSP.0) ----> CODEC FE pcm:0,1 --- The digital audio routing is controlled by the usual ALSA method of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the routing based upon the mixer settings and configures the BE PCMs based on routing and the FE HW params. DPCM is designed so that most ASoC component drivers will need no modification at all. It's intended that existing CODEC, DAI and platform drivers can be used in DPCM based audio devices without any changes. However, there will be some cases where minor changes are required (e.g. for very tightly coupled HW) and there are helpers to support this too. Somethimes the HW params of a FE and BE do not match or are incompatible, so in these cases the machine driver can reconfigure any hw_params and make any DSP perform sample rate / format conversion. This patch adds the core DPCM code and contains :- o The FE and BE PCM operations. o FE and BE DAI link support. o FE and BE PCM creation. o BE support API. o BE and FE link management. Signed-off-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 15:12:49 +04:00
#endif