2018-07-02 09:22:58 +03: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 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
2014-01-17 21:03:55 +04: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 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 ,
2012-04-25 15:12:52 +04: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 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 ;
/* hw params for this link - may be different for each link */
struct snd_pcm_hw_params hw_params ;
2012-04-25 15:12:50 +04: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 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 */
ASoC: dpcm: Add Dynamic PCM core operations.
The Dynamic PCM core allows digital audio data to be dynamically
routed between different ALSA PCMs and DAI links on SoC CPUs with
on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
routed to any (or all) SoC DAI links.
Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
they can dynamically route digital audio data to any supported BE
PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
substream and audio HW parameters.
e.g. pcm:0,0 routing digital data to 2 external codecs.
FE pcm:0,0 ----> BE (McBSP.0) ----> CODEC 0
+--> BE (McPDM.0) ----> CODEC 1
e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
FE pcm:0,0 ---
+--> BE (McBSP.0) ----> CODEC
FE pcm:0,1 ---
The digital audio routing is controlled by the usual ALSA method
of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
routing based upon the mixer settings and configures the BE PCMs
based on routing and the FE HW params.
DPCM is designed so that most ASoC component drivers will need no
modification at all. It's intended that existing CODEC, DAI and
platform drivers can be used in DPCM based audio devices without
any changes. However, there will be some cases where minor changes
are required (e.g. for very tightly coupled HW) and there are
helpers to support this too.
Somethimes the HW params of a FE and BE do not match or are
incompatible, so in these cases the machine driver can reconfigure
any hw_params and make any DSP perform sample rate / format conversion.
This patch adds the core DPCM code and contains :-
o The FE and BE PCM operations.
o FE and BE DAI link support.
o FE and BE PCM creation.
o BE support API.
o BE 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
} ;
2019-10-25 03:56:10 +03: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 )
2018-09-18 04:31:09 +03: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 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 ) ;
2020-03-12 12:52:14 +03:00
/* 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
2019-08-07 04:31:31 +03: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-17 21:03:55 +04:00
int dpcm_path_get ( struct snd_soc_pcm_runtime * fe ,
int stream , struct snd_soc_dapm_widget_list * * list_ ) ;
ASoC: soc-pcm: move dpcm_path_put() to soc-pcm.c
dpcm_path_put() (A) is calling kfree(*list).
The freed list is created by dapm_widget_list_create() (B) which is called
from snd_soc_dapm_dai_get_connected_widgets() (C) which is called from
dpcm_path_get() (D).
(B) dapm_widget_list_create(**list, ...)
{
...
=> *list = kzalloc();
...
}
(C) snd_soc_dapm_dai_get_connected_widgets(..., **list, ...)
{
...
dapm_widget_list_create(list, ...);
...
}
(D) dpcm_path_get(..., **list)
{
...
snd_soc_dapm_dai_get_connected_widgets(..., list, ...);
...
}
(A) dpcm_path_put(**list)
{
=> kfree(*list);
}
This kind of unbalance code is very difficult to read/understand.
To avoid this issue, this patch adds each missing paired function
dapm_widget_list_free() for dapm_widget_list_create() (B), and
snd_soc_dapm_dai_free_widgets() for snd_soc_dapm_dai_get_connected_widgets() (C).
This patch uses these, and moves dpcm_path_put() next to dpcm_path_get().
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a75fjc9q.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-19 09:56:52 +03:00
void dpcm_path_put ( struct snd_soc_dapm_widget_list * * list ) ;
2014-01-17 21:03:55 +04:00
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 ) ;
2021-03-09 04:08:17 +03:00
void dpcm_be_dai_stop ( struct snd_soc_pcm_runtime * fe , int stream ,
int do_hw_free , struct snd_soc_dpcm * last ) ;
2014-01-17 21:03:55 +04:00
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 ) ;
2021-03-15 03:58:32 +03:00
void dpcm_be_dai_hw_free ( struct snd_soc_pcm_runtime * fe , int stream ) ;
2014-01-17 21:03:55 +04:00
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 ) ;
2021-03-09 04:08:17 +03:00
# 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
