2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-26 14:14:01 +08:00
linux-next/include/sound/soc-dpcm.h

163 lines
4.7 KiB
C
Raw Normal View History

ASoC: dpcm: Add Dynamic PCM core operations. The Dynamic PCM core allows digital audio data to be dynamically routed between different ALSA PCMs and DAI links on SoC CPUs with on chip DSP devices. e.g. audio data could be played on pcm:0,0 and routed to any (or all) SoC DAI links. Dynamic PCM introduces the concept of Front End (FE) PCMs and Back End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that they can dynamically route digital audio data to any supported BE PCM. A BE PCM has no ALSA device, but represents a DAI link and it's substream and audio HW parameters. e.g. pcm:0,0 routing digital data to 2 external codecs. FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0 +--> BE (McPDM.0) ----> CODEC 1 e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec. FE pcm:0,0 --- +--> BE (McBSP.0) ----> CODEC FE pcm:0,1 --- The digital audio routing is controlled by the usual ALSA method of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the routing based upon the mixer settings and configures the BE PCMs based on routing and the FE HW params. DPCM is designed so that most ASoC component drivers will need no modification at all. It's intended that existing CODEC, DAI and platform drivers can be used in DPCM based audio devices without any changes. However, there will be some cases where minor changes are required (e.g. for very tightly coupled HW) and there are helpers to support this too. Somethimes the HW params of a FE and BE do not match or are incompatible, so in these cases the machine driver can reconfigure any hw_params and make any DSP perform sample rate / format conversion. This patch adds the core DPCM code and contains :- o The FE and BE PCM operations. o FE and BE DAI link support. o FE and BE PCM creation. o BE support API. o BE and FE link management. Signed-off-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 19:12:49 +08:00
/*
* linux/sound/soc-dpcm.h -- ALSA SoC Dynamic PCM Support
*
* Author: Liam Girdwood <lrg@ti.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#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 19:12:49 +08: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 19:12:49 +08: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;
/* hw params for this link - may be different for each link */
struct snd_pcm_hw_params hw_params;
#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 19:12:49 +08: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 23:52:28 +08:00
int trigger_pending; /* trigger cmd + 1 if pending, 0 if not */
ASoC: dpcm: Add Dynamic PCM core operations. The Dynamic PCM core allows digital audio data to be dynamically routed between different ALSA PCMs and DAI links on SoC CPUs with on chip DSP devices. e.g. audio data could be played on pcm:0,0 and routed to any (or all) SoC DAI links. Dynamic PCM introduces the concept of Front End (FE) PCMs and Back End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that they can dynamically route digital audio data to any supported BE PCM. A BE PCM has no ALSA device, but represents a DAI link and it's substream and audio HW parameters. e.g. pcm:0,0 routing digital data to 2 external codecs. FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0 +--> BE (McPDM.0) ----> CODEC 1 e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec. FE pcm:0,0 --- +--> BE (McBSP.0) ----> CODEC FE pcm:0,1 --- The digital audio routing is controlled by the usual ALSA method of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the routing based upon the mixer settings and configures the BE PCMs based on routing and the FE HW params. DPCM is designed so that most ASoC component drivers will need no modification at all. It's intended that existing CODEC, DAI and platform drivers can be used in DPCM based audio devices without any changes. However, there will be some cases where minor changes are required (e.g. for very tightly coupled HW) and there are helpers to support this too. Somethimes the HW params of a FE and BE do not match or are incompatible, so in these cases the machine driver can reconfigure any hw_params and make any DSP perform sample rate / format conversion. This patch adds the core DPCM code and contains :- o The FE and BE PCM operations. o FE and BE DAI link support. o FE and BE PCM creation. o BE support API. o BE and FE link management. Signed-off-by: Liam Girdwood <lrg@ti.com> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2012-04-25 19:12:49 +08: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);
/* get the BE runtime state */
enum snd_soc_dpcm_state
snd_soc_dpcm_be_get_state(struct snd_soc_pcm_runtime *be, int stream);
/* 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);
/* internal use only */
int soc_dpcm_be_digital_mute(struct snd_soc_pcm_runtime *fe, int mute);
void soc_dpcm_debugfs_add(struct snd_soc_pcm_runtime *rtd);
int soc_dpcm_runtime_update(struct snd_soc_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 19:12:49 +08:00
int dpcm_path_get(struct snd_soc_pcm_runtime *fe,
int stream, 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);
int dpcm_be_dai_shutdown(struct snd_soc_pcm_runtime *fe, int stream);
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);
int 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);
static inline void dpcm_path_put(struct snd_soc_dapm_widget_list **list)
{
kfree(*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 19:12:49 +08:00
#endif