* [PATCH] Codec to codec dai link description
@ 2016-10-20 6:00 anish kumar
2016-10-20 9:44 ` Charles Keepax
0 siblings, 1 reply; 6+ messages in thread
From: anish kumar @ 2016-10-20 6:00 UTC (permalink / raw)
To: perex, tiwai, broonie@kernel.org, Linux-ALSA, Liam Girdwood,
Charles Keepax
Signed-off-by: anish kumar <yesanishhere@gmail.com>
---
Documentation/sound/alsa/soc/codec_to_codec.txt | 114 ++++++++++++++++++++++++
1 file changed, 114 insertions(+)
create mode 100644 Documentation/sound/alsa/soc/codec_to_codec.txt
diff --git a/Documentation/sound/alsa/soc/codec_to_codec.txt
b/Documentation/sound/alsa/soc/codec_to_codec.txt
new file mode 100644
index 0000000..b0f221d
--- /dev/null
+++ b/Documentation/sound/alsa/soc/codec_to_codec.txt
@@ -0,0 +1,114 @@
+Creating codec to codec dai link for ALSA dapm
+===================================================
+
+Mostly the flow of audio is always from CPU to codec so your system
+will look as below:
+
+ ---------- ---------
+| | dai | |
+ CPU -------> codec
+| | | |
+ --------- ---------
+
+In case your system looks as below:
+ ---------
+ | |
+ codec-2
+ | |
+ ---------
+ |
+ dai-2
+ |
+ ---------- ---------
+| | dai-1 | |
+ CPU -------> codec-1
+| | | |
+ ---------- ---------
+ |
+ dai-3
+ |
+ ---------
+ | |
+ codec-3
+ | |
+ ---------
+
+Suppose codec-2 is a bluetooth chip and codec-3 is connected to
+a speaker and you have a below scenario:
+codec-2 will receive the audio data and the user wants to play that
+audio through codec-3 without involving the CPU.This
+aforementioned case is the ideal case when codec to codec
+connection should be used.
+
+Your dai_link should appear as below in your machine
+file:
+
+static const struct snd_soc_pcm_stream dummy_params = {
+ .formats = SNDRV_PCM_FMTBIT_S24_LE,
+ .rate_min = 48000,
+ .rate_max = 48000,
+ .channels_min = 2,
+ .channels_max = 2,
+};
+
+{
+ .name = "your_name",
+ .stream_name = "your_stream_name",
+ .cpu_dai_name = "snd-soc-dummy-dai",
+ .codec_name = "codec-2,
+ .codec_dai_name = "codec-2-dai_name",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+ | SND_SOC_DAIFMT_CBM_CFM,
+ .ignore_suspend = 1,
+ .params = &dummy_params,
+},
+{
+ .name = "your_name",
+ .stream_name = "your_stream_name",
+ .cpu_dai_name = "snd-soc-dummy-dai",
+ .codec_name = "codec-3,
+ .codec_dai_name = "codec-3-dai_name",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+ | SND_SOC_DAIFMT_CBM_CFM,
+ .ignore_suspend = 1,
+ .params = &dummy_params,
+},
+
+Note the "params" callback which lets the dapm know that this
+dai_link is a codec to codec connection.
+Also, in above code cpu_dai should be replaced with your actual
+cpu dai but in case you don't have a actual cpu dai then dummy will
+do.
+
+You can browse the speyside.c for an actual example code in mainline.
+
+Note that in current device tree there is no way to mark a dai_link
+as codec to codec. However, it may change in future.
+
+In dapm core a route is created between cpu_dai playback widget
+and codec_dai capture widget for playback path and vice-versa is
+true for capture path. In order for this aforementioned route to get
+triggered, DAPM needs to find a valid endpoint which could be either
+a sink or source widget corresponding to playback and capture path
+respectively.
+
+Below is what you can use it to trigger the widgets provided you have
+stream name ending with "Playback" and "Capture" for cpu and
+codec dai's.
+
+static const struct snd_soc_dapm_widget aif_dapm_widgets[] = {
+ SND_SOC_DAPM_SPK("dummyspk", NULL),
+ SND_SOC_DAPM_MIC("dummymic", NULL),
+};
+
+static const struct snd_soc_dapm_route audio_i2s_map[] = {
+ {"dummyspk", NULL, "Playback"},
+ {"Capture", NULL, "dummymic"},
+};
+
+Above code is good for quick testing but in order to mainline it
+you are expected to create a thin codec driver for the speaker
+amp rather than doing this sort of thing, as that at least
+sets appropriate constraints for the device even if it needs
+no control. For an example of such a driver you can see:
+sound/soc/codecs/wm8727.c
--
2.8.4 (Apple Git-73)
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] Codec to codec dai link description
2016-10-20 6:00 [PATCH] Codec to codec dai link description anish kumar
@ 2016-10-20 9:44 ` Charles Keepax
2016-10-24 4:03 ` anish kumar
0 siblings, 1 reply; 6+ messages in thread
From: Charles Keepax @ 2016-10-20 9:44 UTC (permalink / raw)
To: anish kumar; +Cc: Liam Girdwood, Linux-ALSA, broonie@kernel.org, tiwai
On Wed, Oct 19, 2016 at 11:00:37PM -0700, anish kumar wrote:
> Signed-off-by: anish kumar <yesanishhere@gmail.com>
> ---
> Documentation/sound/alsa/soc/codec_to_codec.txt | 114 ++++++++++++++++++++++++
> 1 file changed, 114 insertions(+)
> create mode 100644 Documentation/sound/alsa/soc/codec_to_codec.txt
>
> diff --git a/Documentation/sound/alsa/soc/codec_to_codec.txt
> b/Documentation/sound/alsa/soc/codec_to_codec.txt
> new file mode 100644
> index 0000000..b0f221d
> --- /dev/null
> +++ b/Documentation/sound/alsa/soc/codec_to_codec.txt
> @@ -0,0 +1,114 @@
> +Creating codec to codec dai link for ALSA dapm
> +===================================================
> +
> +Mostly the flow of audio is always from CPU to codec so your system
> +will look as below:
> +
> + ---------- ---------
> +| | dai | |
> + CPU -------> codec
> +| | | |
> + --------- ---------
> +
> +In case your system looks as below:
> + ---------
> + | |
> + codec-2
> + | |
> + ---------
> + |
> + dai-2
> + |
> + ---------- ---------
> +| | dai-1 | |
> + CPU -------> codec-1
> +| | | |
> + ---------- ---------
> + |
> + dai-3
> + |
> + ---------
> + | |
> + codec-3
> + | |
> + ---------
> +
> +Suppose codec-2 is a bluetooth chip and codec-3 is connected to
> +a speaker and you have a below scenario:
> +codec-2 will receive the audio data and the user wants to play that
> +audio through codec-3 without involving the CPU.This
> +aforementioned case is the ideal case when codec to codec
> +connection should be used.
> +
> +Your dai_link should appear as below in your machine
> +file:
> +
> +static const struct snd_soc_pcm_stream dummy_params = {
Still not sure I like the name dummy_params its not really a
dummy its specifying how the link will be configured.
> + .formats = SNDRV_PCM_FMTBIT_S24_LE,
> + .rate_min = 48000,
> + .rate_max = 48000,
> + .channels_min = 2,
> + .channels_max = 2,
> +};
> +
> +{
> + .name = "your_name",
> + .stream_name = "your_stream_name",
> + .cpu_dai_name = "snd-soc-dummy-dai",
Not sure we should be using dummies in the example we wouldn't
expect people to use the dummy in a real system so my thinking
would be it shouldn't look like that in the documentation.
> + .codec_name = "codec-2,
> + .codec_dai_name = "codec-2-dai_name",
> + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
> + | SND_SOC_DAIFMT_CBM_CFM,
> + .ignore_suspend = 1,
> + .params = &dummy_params,
> +},
> +{
> + .name = "your_name",
> + .stream_name = "your_stream_name",
> + .cpu_dai_name = "snd-soc-dummy-dai",
> + .codec_name = "codec-3,
> + .codec_dai_name = "codec-3-dai_name",
> + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
> + | SND_SOC_DAIFMT_CBM_CFM,
> + .ignore_suspend = 1,
> + .params = &dummy_params,
> +},
> +
> +Note the "params" callback which lets the dapm know that this
> +dai_link is a codec to codec connection.
> +Also, in above code cpu_dai should be replaced with your actual
> +cpu dai but in case you don't have a actual cpu dai then dummy will
> +do.
Again here not sure we should mention the dummy here.
> +
> +You can browse the speyside.c for an actual example code in mainline.
> +
> +Note that in current device tree there is no way to mark a dai_link
> +as codec to codec. However, it may change in future.
> +
> +In dapm core a route is created between cpu_dai playback widget
> +and codec_dai capture widget for playback path and vice-versa is
> +true for capture path. In order for this aforementioned route to get
> +triggered, DAPM needs to find a valid endpoint which could be either
> +a sink or source widget corresponding to playback and capture path
> +respectively.
> +
> +Below is what you can use it to trigger the widgets provided you have
> +stream name ending with "Playback" and "Capture" for cpu and
> +codec dai's.
> +
> +static const struct snd_soc_dapm_widget aif_dapm_widgets[] = {
> + SND_SOC_DAPM_SPK("dummyspk", NULL),
> + SND_SOC_DAPM_MIC("dummymic", NULL),
> +};
> +
> +static const struct snd_soc_dapm_route audio_i2s_map[] = {
> + {"dummyspk", NULL, "Playback"},
> + {"Capture", NULL, "dummymic"},
> +};
I would still be tempted to leave the part with aif_dapm_widgets
out. Its showing bad practice and the documentation should be
advising people just to link up two CODEC drivers.
> +
> +Above code is good for quick testing but in order to mainline it
> +you are expected to create a thin codec driver for the speaker
> +amp rather than doing this sort of thing, as that at least
> +sets appropriate constraints for the device even if it needs
> +no control. For an example of such a driver you can see:
> +sound/soc/codecs/wm8727.c
Only some minor comments, but it generally looks good thanks for
doing this.
Thanks,
Charles
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] Codec to codec dai link description
2016-10-20 9:44 ` Charles Keepax
@ 2016-10-24 4:03 ` anish kumar
2016-10-24 8:13 ` Charles Keepax
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: anish kumar @ 2016-10-24 4:03 UTC (permalink / raw)
To: Charles Keepax; +Cc: Liam Girdwood, Linux-ALSA, broonie@kernel.org, tiwai
Signed-off-by: anish kumar <yesanishhere@gmail.com>
---
Documentation/sound/alsa/soc/codec_to_codec.txt | 103 ++++++++++++++++++++++++
1 file changed, 103 insertions(+)
create mode 100644 Documentation/sound/alsa/soc/codec_to_codec.txt
diff --git a/Documentation/sound/alsa/soc/codec_to_codec.txt
b/Documentation/sound/alsa/soc/codec_to_codec.txt
new file mode 100644
index 0000000..61c9cae
--- /dev/null
+++ b/Documentation/sound/alsa/soc/codec_to_codec.txt
@@ -0,0 +1,103 @@
+Creating codec to codec dai link for ALSA dapm
+===================================================
+
+Mostly the flow of audio is always from CPU to codec so your system
+will look as below:
+
+ --------- ---------
+| | dai | |
+ CPU -------> codec
+| | | |
+ --------- ---------
+
+In case your system looks as below:
+ ---------
+ | |
+ codec-2
+ | |
+ ---------
+ |
+ dai-2
+ |
+ ---------- ---------
+| | dai-1 | |
+ CPU -------> codec-1
+| | | |
+ ---------- ---------
+ |
+ dai-3
+ |
+ ---------
+ | |
+ codec-3
+ | |
+ ---------
+
+Suppose codec-2 is a bluetooth chip and codec-3 is connected to
+a speaker and you have a below scenario:
+codec-2 will receive the audio data and the user wants to play that
+audio through codec-3 without involving the CPU.This
+aforementioned case is the ideal case when codec to codec
+connection should be used.
+
+Your dai_link should appear as below in your machine
+file:
+
+/*
+ * this pcm stream only supports 24 bit, 2 channel and
+ * 48k sampling rate.
+ */
+static const struct snd_soc_pcm_stream dsp_codec_params = {
+ .formats = SNDRV_PCM_FMTBIT_S24_LE,
+ .rate_min = 48000,
+ .rate_max = 48000,
+ .channels_min = 2,
+ .channels_max = 2,
+};
+
+{
+ .name = "CPU-DSP",
+ .stream_name = "CPU-DSP",
+ .cpu_dai_name = "samsung-i2s.0",
+ .codec_name = "codec-2,
+ .codec_dai_name = "codec-2-dai_name",
+ .platform_name = "samsung-i2s.0",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+ | SND_SOC_DAIFMT_CBM_CFM,
+ .ignore_suspend = 1,
+ .params = &dsp_codec_params,
+},
+{
+ .name = "DSP-CODEC",
+ .stream_name = "DSP-CODEC",
+ .cpu_dai_name = "wm0010-sdi2",
+ .codec_name = "codec-3,
+ .codec_dai_name = "codec-3-dai_name",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+ | SND_SOC_DAIFMT_CBM_CFM,
+ .ignore_suspend = 1,
+ .params = &dsp_codec_params,
+},
+
+Above code snippet is motivated from sound/soc/samsung/speyside.c.
+
+Note the "params" callback which lets the dapm know that this
+dai_link is a codec to codec connection.
+
+In dapm core a route is created between cpu_dai playback widget
+and codec_dai capture widget for playback path and vice-versa is
+true for capture path. In order for this aforementioned route to get
+triggered, DAPM needs to find a valid endpoint which could be either
+a sink or source widget corresponding to playback and capture path
+respectively.
+
+In order to trigger this dai_link widget, a thin codec driver for
+the speaker amp can be created as demonstrated in wm8727.c file, it
+sets appropriate constraints for the device even if it needs no control.
+
+Make sure to name your corresponding cpu and codec playback and capture
+dai names ending with "Playback" and "Capture" respectively as dapm core
+will link and power those dais based on the name.
+
+Note that in current device tree there is no way to mark a dai_link
+as codec to codec. However, it may change in future.
--
2.8.4 (Apple Git-73)
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] Codec to codec dai link description
2016-10-24 4:03 ` anish kumar
@ 2016-10-24 8:13 ` Charles Keepax
2016-10-26 10:31 ` Mark Brown
2016-10-26 10:46 ` Applied "ASoC: Codec to codec dai link description" to the asoc tree Mark Brown
2 siblings, 0 replies; 6+ messages in thread
From: Charles Keepax @ 2016-10-24 8:13 UTC (permalink / raw)
To: anish kumar; +Cc: Linux-ALSA, broonie@kernel.org, Liam Girdwood, tiwai
On Sun, Oct 23, 2016 at 09:03:53PM -0700, anish kumar wrote:
> Signed-off-by: anish kumar <yesanishhere@gmail.com>
> ---
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Thanks,
Charles
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Codec to codec dai link description
2016-10-24 4:03 ` anish kumar
2016-10-24 8:13 ` Charles Keepax
@ 2016-10-26 10:31 ` Mark Brown
2016-10-26 10:46 ` Applied "ASoC: Codec to codec dai link description" to the asoc tree Mark Brown
2 siblings, 0 replies; 6+ messages in thread
From: Mark Brown @ 2016-10-26 10:31 UTC (permalink / raw)
To: anish kumar; +Cc: Liam Girdwood, Charles Keepax, tiwai, Linux-ALSA
[-- Attachment #1.1: Type: text/plain, Size: 407 bytes --]
On Sun, Oct 23, 2016 at 09:03:53PM -0700, anish kumar wrote:
> Signed-off-by: anish kumar <yesanishhere@gmail.com>
> ---
Please submit patches using subject lines reflecting the style for the
subsystem. This makes it easier for people to identify relevant
patches. Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Applied "ASoC: Codec to codec dai link description" to the asoc tree
2016-10-24 4:03 ` anish kumar
2016-10-24 8:13 ` Charles Keepax
2016-10-26 10:31 ` Mark Brown
@ 2016-10-26 10:46 ` Mark Brown
2 siblings, 0 replies; 6+ messages in thread
From: Mark Brown @ 2016-10-26 10:46 UTC (permalink / raw)
To: anish kumar
Cc: Charles Keepax, broonie@kernel.org, Liam Girdwood, Linux-ALSA,
tiwai
The patch
ASoC: Codec to codec dai link description
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 452a256898e7ca88115aa02d3851e67994ce3e19 Mon Sep 17 00:00:00 2001
From: anish kumar <yesanishhere@gmail.com>
Date: Sun, 23 Oct 2016 21:03:53 -0700
Subject: [PATCH] ASoC: Codec to codec dai link description
Signed-off-by: anish kumar <yesanishhere@gmail.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Documentation/sound/alsa/soc/codec_to_codec.txt | 103 ++++++++++++++++++++++++
1 file changed, 103 insertions(+)
create mode 100644 Documentation/sound/alsa/soc/codec_to_codec.txt
diff --git a/Documentation/sound/alsa/soc/codec_to_codec.txt b/Documentation/sound/alsa/soc/codec_to_codec.txt
new file mode 100644
index 000000000000..704a6483652c
--- /dev/null
+++ b/Documentation/sound/alsa/soc/codec_to_codec.txt
@@ -0,0 +1,103 @@
+Creating codec to codec dai link for ALSA dapm
+===================================================
+
+Mostly the flow of audio is always from CPU to codec so your system
+will look as below:
+
+ --------- ---------
+| | dai | |
+ CPU -------> codec
+| | | |
+ --------- ---------
+
+In case your system looks as below:
+ ---------
+ | |
+ codec-2
+ | |
+ ---------
+ |
+ dai-2
+ |
+ ---------- ---------
+| | dai-1 | |
+ CPU -------> codec-1
+| | | |
+ ---------- ---------
+ |
+ dai-3
+ |
+ ---------
+ | |
+ codec-3
+ | |
+ ---------
+
+Suppose codec-2 is a bluetooth chip and codec-3 is connected to
+a speaker and you have a below scenario:
+codec-2 will receive the audio data and the user wants to play that
+audio through codec-3 without involving the CPU.This
+aforementioned case is the ideal case when codec to codec
+connection should be used.
+
+Your dai_link should appear as below in your machine
+file:
+
+/*
+ * this pcm stream only supports 24 bit, 2 channel and
+ * 48k sampling rate.
+ */
+static const struct snd_soc_pcm_stream dsp_codec_params = {
+ .formats = SNDRV_PCM_FMTBIT_S24_LE,
+ .rate_min = 48000,
+ .rate_max = 48000,
+ .channels_min = 2,
+ .channels_max = 2,
+};
+
+{
+ .name = "CPU-DSP",
+ .stream_name = "CPU-DSP",
+ .cpu_dai_name = "samsung-i2s.0",
+ .codec_name = "codec-2,
+ .codec_dai_name = "codec-2-dai_name",
+ .platform_name = "samsung-i2s.0",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+ | SND_SOC_DAIFMT_CBM_CFM,
+ .ignore_suspend = 1,
+ .params = &dsp_codec_params,
+},
+{
+ .name = "DSP-CODEC",
+ .stream_name = "DSP-CODEC",
+ .cpu_dai_name = "wm0010-sdi2",
+ .codec_name = "codec-3,
+ .codec_dai_name = "codec-3-dai_name",
+ .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+ | SND_SOC_DAIFMT_CBM_CFM,
+ .ignore_suspend = 1,
+ .params = &dsp_codec_params,
+},
+
+Above code snippet is motivated from sound/soc/samsung/speyside.c.
+
+Note the "params" callback which lets the dapm know that this
+dai_link is a codec to codec connection.
+
+In dapm core a route is created between cpu_dai playback widget
+and codec_dai capture widget for playback path and vice-versa is
+true for capture path. In order for this aforementioned route to get
+triggered, DAPM needs to find a valid endpoint which could be either
+a sink or source widget corresponding to playback and capture path
+respectively.
+
+In order to trigger this dai_link widget, a thin codec driver for
+the speaker amp can be created as demonstrated in wm8727.c file, it
+sets appropriate constraints for the device even if it needs no control.
+
+Make sure to name your corresponding cpu and codec playback and capture
+dai names ending with "Playback" and "Capture" respectively as dapm core
+will link and power those dais based on the name.
+
+Note that in current device tree there is no way to mark a dai_link
+as codec to codec. However, it may change in future.
--
2.8.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-26 10:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-20 6:00 [PATCH] Codec to codec dai link description anish kumar
2016-10-20 9:44 ` Charles Keepax
2016-10-24 4:03 ` anish kumar
2016-10-24 8:13 ` Charles Keepax
2016-10-26 10:31 ` Mark Brown
2016-10-26 10:46 ` Applied "ASoC: Codec to codec dai link description" to the asoc tree Mark Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).