[PATCH v2] ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.

[PATCH v2] ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.

[Liam Girdwood]

Add some DAPM widget types to better support the construction of DAPM
graphs within DSPs

Changes v1.
  o Added some documentation.
  o Split codec widget into encoder and decoder to avoid confusion with HW
    CODECS.

Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
---
 Documentation/sound/soc/dapm.rst | 18 ++++++++++++++++++
 include/sound/soc-dapm.h         |  7 +++++++
 include/uapi/sound/asoc.h        | 10 +++++++++-
 sound/soc/soc-topology.c         |  8 ++++++++
 4 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst
index a27f42befa4d..78d63f6a35fa 100644
--- a/Documentation/sound/soc/dapm.rst
+++ b/Documentation/sound/soc/dapm.rst
@@ -105,6 +105,24 @@ Pre
 	Special PRE widget (exec before all others)
 Post
 	Special POST widget (exec after all others)
+Buffer
+	Inter widget audio data buffer within a DSP.
+Pipeline
+	Collection of widgets within a DSP, can represent a sequence of DSP
+	widgets and their collective configuration.
+Effect
+	Widget that performs an audio processing effect.
+SRC
+	Sample Rate Converter within DSP or CODEC
+ASRC
+	Asynchronous Sample Rate Converter within DSP or CODEC
+Encoder
+	Widget that encodes audio data from one format (usually PCM) to another
+	usually more compressed format.
+Decoder
+	Widget that decodes audio data from a compressed format to an
+	uncompressed format like PCM.
+
 
 (Widgets are defined in include/sound/soc-dapm.h)
 
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index a466f4bdc835..68fea6d97199 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -510,6 +510,13 @@ 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_encoder,		/* FW/SW audio encoder component */
+	snd_soc_dapm_decoder,		/* FW/SW audio decoder component */
 };
 
 enum snd_soc_dapm_subclass {
diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h
index 6702533c8bd8..8a4fdf3e7e2e 100644
--- a/include/uapi/sound/asoc.h
+++ b/include/uapi/sound/asoc.h
@@ -73,7 +73,15 @@
 #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_ENCODER	22
+#define SND_SOC_TPLG_DAPM_DECODER	23
+#define SND_SOC_TPLG_DAPM_LAST		SND_SOC_TPLG_DAPM_DECODER
 
 /* 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 12e189701924..b82d2755c2ac 100644
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -242,6 +242,14 @@ 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_ENCODER, snd_soc_dapm_encoder},
+	{SND_SOC_TPLG_DAPM_DECODER, snd_soc_dapm_decoder},
 };
 
 static int tplc_chan_get_reg(struct soc_tplg *tplg,
-- 
2.11.0

Re: [PATCH v2] ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 762 bytes --]

On Fri, Jun 09, 2017 at 04:23:49PM +0100, Liam Girdwood wrote:

> Changes v1.
>   o Added some documentation.
>   o Split codec widget into encoder and decoder to avoid confusion with HW
>     CODECS.

Please put the inter-version changelogs after the --- so they get
filtered out when applied.

> +Pipeline
> +	Collection of widgets within a DSP, can represent a sequence of DSP
> +	widgets and their collective configuration.
> +Effect
> +	Widget that performs an audio processing effect.

I'm still a bit unclear about how a pipeline and effect are different
from an ASoC point of view - it matters on the DSP but from the kernel's
point of view a pipeline just an effect that happens to have a more
complicated implementation on the DSP?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH v2] ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.

[Liam Girdwood]

On Fri, 2017-06-09 at 18:53 +0100, Mark Brown wrote:
> On Fri, Jun 09, 2017 at 04:23:49PM +0100, Liam Girdwood wrote:
> 
> > Changes v1.
> >   o Added some documentation.
> >   o Split codec widget into encoder and decoder to avoid confusion with HW
> >     CODECS.
> 
> Please put the inter-version changelogs after the --- so they get
> filtered out when applied.
> 
> > +Pipeline
> > +	Collection of widgets within a DSP, can represent a sequence of DSP
> > +	widgets and their collective configuration.
> > +Effect
> > +	Widget that performs an audio processing effect.
> 
> I'm still a bit unclear about how a pipeline and effect are different
> from an ASoC point of view - it matters on the DSP but from the kernel's
> point of view a pipeline just an effect that happens to have a more
> complicated implementation on the DSP?

Sorry for the delay.

Yes, that's true, some of the objects will most likely be treated the
same by the kernel core but for the DSP and driver they will different.
i.e. they create different objects with different topology private data
(using the widget ID to differentiate).

Liam

> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH v2] ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 837 bytes --]

On Wed, Jun 14, 2017 at 12:28:55PM +0100, Liam Girdwood wrote:
> On Fri, 2017-06-09 at 18:53 +0100, Mark Brown wrote:

> > I'm still a bit unclear about how a pipeline and effect are different
> > from an ASoC point of view - it matters on the DSP but from the kernel's
> > point of view a pipeline just an effect that happens to have a more
> > complicated implementation on the DSP?

> Yes, that's true, some of the objects will most likely be treated the
> same by the kernel core but for the DSP and driver they will different.
> i.e. they create different objects with different topology private data
> (using the widget ID to differentiate).

Shouldn't that just be handled in the driver though?  Nothing outside
the driver cares.  We're going to need to differentiate between
different effects and pipelines in the driver anyway.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH v2] ASoC: dapm: Add new widget type for constructing DAPM graphs on DSPs.

[Liam Girdwood]

On Thu, 2017-06-15 at 11:01 +0100, Mark Brown wrote:
> On Wed, Jun 14, 2017 at 12:28:55PM +0100, Liam Girdwood wrote:
> > On Fri, 2017-06-09 at 18:53 +0100, Mark Brown wrote:
> 
> > > I'm still a bit unclear about how a pipeline and effect are different
> > > from an ASoC point of view - it matters on the DSP but from the kernel's
> > > point of view a pipeline just an effect that happens to have a more
> > > complicated implementation on the DSP?
> 
> > Yes, that's true, some of the objects will most likely be treated the
> > same by the kernel core but for the DSP and driver they will different.
> > i.e. they create different objects with different topology private data
> > (using the widget ID to differentiate).
> 
> Shouldn't that just be handled in the driver though?  Nothing outside
> the driver cares.  We're going to need to differentiate between
> different effects and pipelines in the driver anyway.

It can be, just a little more code in the driver that's all. I'll remove
the pipeline widget and resend.

Thanks

Liam