2018-07-02 15:22:58 +09:00
|
|
|
/* 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 20:12:49 +09: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
|
|
|
|
|
|
2014-01-18 02:03:55 +09:00
|
|
|
#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 20:12:49 +09: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,
|
2012-04-25 20:12:52 +09:00
|
|
|
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 20:12:49 +09: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;
|
2012-04-25 20:12:50 +09:00
|
|
|
#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 20:12:49 +09: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-05 00:52:28 +09: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 20:12:49 +09:00
|
|
|
};
|
|
|
|
|
|
2018-09-18 10:30:54 +09:00
|
|
|
#define for_each_dpcm_fe(be, stream, dpcm) \
|
|
|
|
|
list_for_each_entry(dpcm, &(be)->dpcm[stream].fe_clients, list_fe)
|
|
|
|
|
|
2018-09-18 10:31:09 +09:00
|
|
|
#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 20:12:49 +09: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);
|
2013-07-24 22:27:36 +09:00
|
|
|
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 20:12:49 +09:00
|
|
|
|
2019-08-07 10:31:31 +09: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
|
|
|
|
|
|
2014-01-18 02:03:55 +09: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 20:12:49 +09:00
|
|
|
#endif
|