[alsa-devel] [PATCH] ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.
Add some DAPM widget types to better support the construction of DAPM graphs within DSPs.
Signed-off-by: Liam Girdwood liam.r.girdwood@linux.intel.com --- include/sound/soc-dapm.h | 6 ++++++ include/uapi/sound/asoc.h | 9 ++++++++- sound/soc/soc-topology.c | 7 +++++++ 3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index a466f4bdc835..f142dace1c14 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -510,6 +510,12 @@ enum snd_soc_dapm_type { snd_soc_dapm_dai_out, snd_soc_dapm_dai_link, /* link between two DAI structures */ snd_soc_dapm_kcontrol, /* Auto-disabled kcontrol */ + snd_soc_dapm_buffer, /* DSP/CODEC internal buffer */ + snd_soc_dapm_pipeline, /* DSP/CODEC internal pipeline */ + snd_soc_dapm_effect, /* DSP/CODEC effect component */ + snd_soc_dapm_src, /* DSP/CODEC SRC component */ + snd_soc_dapm_asrc, /* DSP/CODEC ASRC component */ + snd_soc_dapm_codec, /* FW/SW coder/decoder component */ };
enum snd_soc_dapm_subclass { diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h index 6702533c8bd8..b8993b3c55c6 100644 --- a/include/uapi/sound/asoc.h +++ b/include/uapi/sound/asoc.h @@ -73,7 +73,14 @@ #define SND_SOC_TPLG_DAPM_DAI_IN 13 #define SND_SOC_TPLG_DAPM_DAI_OUT 14 #define SND_SOC_TPLG_DAPM_DAI_LINK 15 -#define SND_SOC_TPLG_DAPM_LAST SND_SOC_TPLG_DAPM_DAI_LINK +#define SND_SOC_TPLG_DAPM_BUFFER 16 +#define SND_SOC_TPLG_DAPM_PIPELINE 17 +#define SND_SOC_TPLG_DAPM_EFFECT 18 +#define SND_SOC_TPLG_DAPM_SIGGEN 19 +#define SND_SOC_TPLG_DAPM_SRC 20 +#define SND_SOC_TPLG_DAPM_ASRC 21 +#define SND_SOC_TPLG_DAPM_CODEC 22 +#define SND_SOC_TPLG_DAPM_LAST SND_SOC_TPLG_DAPM_CODEC
/* Header magic number and string sizes */ #define SND_SOC_TPLG_MAGIC 0x41536F43 /* ASoC */ diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index e10dc353621a..468e74640570 100644 --- a/sound/soc/soc-topology.c +++ b/sound/soc/soc-topology.c @@ -242,6 +242,13 @@ static const struct soc_tplg_map dapm_map[] = { {SND_SOC_TPLG_DAPM_DAI_IN, snd_soc_dapm_dai_in}, {SND_SOC_TPLG_DAPM_DAI_OUT, snd_soc_dapm_dai_out}, {SND_SOC_TPLG_DAPM_DAI_LINK, snd_soc_dapm_dai_link}, + {SND_SOC_TPLG_DAPM_BUFFER, snd_soc_dapm_buffer}, + {SND_SOC_TPLG_DAPM_PIPELINE, snd_soc_dapm_pipeline}, + {SND_SOC_TPLG_DAPM_EFFECT, snd_soc_dapm_effect}, + {SND_SOC_TPLG_DAPM_SIGGEN, snd_soc_dapm_siggen}, + {SND_SOC_TPLG_DAPM_SRC, snd_soc_dapm_src}, + {SND_SOC_TPLG_DAPM_ASRC, snd_soc_dapm_asrc}, + {SND_SOC_TPLG_DAPM_CODEC, snd_soc_dapm_codec}, };
static int tplc_chan_get_reg(struct soc_tplg *tplg,
On Tue, Jun 06, 2017 at 03:44:42PM +0100, Liam Girdwood wrote:
- snd_soc_dapm_buffer, /* DSP/CODEC internal buffer */
- snd_soc_dapm_pipeline, /* DSP/CODEC internal pipeline */
- snd_soc_dapm_effect, /* DSP/CODEC effect component */
What's the difference between a buffer and a pipeline, or between a pipeline and an effect? We should have clear documentation, if they're different we're probably going to end up using them differently in the core at some point and if people use the wrong widget type it might end up breaking things.
- snd_soc_dapm_codec, /* FW/SW coder/decoder component */
Can we call this a fmt_conv or something? CODEC is unfortunately a bit overloaded.
On Wed, 2017-06-07 at 20:23 +0100, Mark Brown wrote:
On Tue, Jun 06, 2017 at 03:44:42PM +0100, Liam Girdwood wrote:
- snd_soc_dapm_buffer, /* DSP/CODEC internal buffer */
- snd_soc_dapm_pipeline, /* DSP/CODEC internal pipeline */
- snd_soc_dapm_effect, /* DSP/CODEC effect component */
What's the difference between a buffer and a pipeline, or between a pipeline and an effect? We should have clear documentation, if they're different we're probably going to end up using them differently in the core at some point and if people use the wrong widget type it might end up breaking things.
Yes, that's a good point. I'll do a V2 that includes some documentation.
- snd_soc_dapm_codec, /* FW/SW coder/decoder component */
Can we call this a fmt_conv or something? CODEC is unfortunately a bit overloaded.
True, what about snd_soc_dapm_media_codec ? or _sw_codec ? or _media_decoder ?
Liam
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On 6/7/17 2:23 PM, Mark Brown wrote:
On Tue, Jun 06, 2017 at 03:44:42PM +0100, Liam Girdwood wrote:
- snd_soc_dapm_buffer, /* DSP/CODEC internal buffer */
- snd_soc_dapm_pipeline, /* DSP/CODEC internal pipeline */
- snd_soc_dapm_effect, /* DSP/CODEC effect component */
What's the difference between a buffer and a pipeline, or between a pipeline and an effect? We should have clear documentation, if they're different we're probably going to end up using them differently in the core at some point and if people use the wrong widget type it might end up breaking things.
it would be good to explain how those elements are organized. Usually an effect/src/asrc is part of a pipeline, it's almost a subgraph within the flat dapm structure
- snd_soc_dapm_codec, /* FW/SW coder/decoder component */
Can we call this a fmt_conv or something? CODEC is unfortunately a bit overloaded.
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (3)
-
Liam Girdwood
-
Mark Brown
-
Pierre-Louis Bossart