diff mbox

[8/8] ASoC: add snd-soc-dummy DT support

Message ID 874mx7iqgt.wl%kuninori.morimoto.gx@renesas.com (mailing list archive)
State New, archived
Headers show

Commit Message

Kuninori Morimoto Aug. 20, 2014, 7:13 a.m. UTC
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

This patch adds snd-soc-dummy DT binding support.
It removes .stream_name from dummy_dai,
because "Playback" / "Capture" is very popular naming.

The DAPM will lost correct route settings
if other CPU/Codec was using same stream name.
And it will be problem when DPCM case.
Like below

FE CPU   (rsnd):   "DAI0 Playback"
   Codec (dummy):  "Playback"

BE CPU   (dummy):  "Playback"
   Codec (ak4642): "Playback"

simple-audio-card,routing = "Playback", "DAI0 Playback";

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 .../devicetree/bindings/sound/snd-soc-dummy        |   13 +++++++++++++
 sound/soc/soc-utils.c                              |   12 +++++++++---
 2 files changed, 22 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/snd-soc-dummy

Comments

Lars-Peter Clausen Aug. 24, 2014, 8:48 a.m. UTC | #1
On 08/20/2014 09:13 AM, Kuninori Morimoto wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> This patch adds snd-soc-dummy DT binding support.

The devicetree describes the hardware, the snd-soc-dummy is a software only 
thing and should not be found in the devicetree.

> It removes .stream_name from dummy_dai,
> because "Playback" / "Capture" is very popular naming.
>
> The DAPM will lost correct route settings
> if other CPU/Codec was using same stream name.
> And it will be problem when DPCM case.
> Like below
>
> FE CPU   (rsnd):   "DAI0 Playback"
>     Codec (dummy):  "Playback"
>
> BE CPU   (dummy):  "Playback"
>     Codec (ak4642): "Playback"


That's something we need to fix, but I don't think removing the stream names 
is the right way to do this. In a multi CODEC environment you'll quite 
likely end up with widgets of the same name. Ideally a route endpoint would 
be expressed by a tuple of DT node and pin name. But I don't think it is 
possible to mix integer and string elements in a property.
Kuninori Morimoto Aug. 26, 2014, 12:04 a.m. UTC | #2
Hi Lars

Thank you for your feedback

> > This patch adds snd-soc-dummy DT binding support.
> 
> The devicetree describes the hardware, the snd-soc-dummy is a software only 
> thing and should not be found in the devicetree.

Hmm... indeed
OK. I will re-consider about this

> > FE CPU   (rsnd):   "DAI0 Playback"
> >     Codec (dummy):  "Playback"
> >
> > BE CPU   (dummy):  "Playback"
> >     Codec (ak4642): "Playback"
> 
> 
> That's something we need to fix, but I don't think removing the stream names 
> is the right way to do this. In a multi CODEC environment you'll quite 
> likely end up with widgets of the same name. Ideally a route endpoint would 
> be expressed by a tuple of DT node and pin name. But I don't think it is 
> possible to mix integer and string elements in a property.

Thank you for your advice.
"DT node and name" seems nice idea, but it works on DT case only ?
Anyway, I re-consider about this too.
It can be trial and error...

Best regards
---
Kuninori Morimoto
Mark Brown Aug. 26, 2014, 6:25 a.m. UTC | #3
On Mon, Aug 25, 2014 at 05:04:20PM -0700, Kuninori Morimoto wrote:

> > That's something we need to fix, but I don't think removing the stream names 
> > is the right way to do this. In a multi CODEC environment you'll quite 
> > likely end up with widgets of the same name. Ideally a route endpoint would 
> > be expressed by a tuple of DT node and pin name. But I don't think it is 
> > possible to mix integer and string elements in a property.

It's not.  Now that we have preprocessor support it's a lot easier to
just use numbers though - the legibility problems from just using raw
numbers in big tables don't apply so much any more.

> Thank you for your advice.
> "DT node and name" seems nice idea, but it works on DT case only ?
> Anyway, I re-consider about this too.
> It can be trial and error...

I think that for hardware which has fairly monolithic audio blocks using
DPCM it might be worth thinking about providing a way for the DT to look
like the DT for a simple I2S DAI with the driver for the IP in the SoC
filling in all the structure needed by DPCM.
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/sound/snd-soc-dummy b/Documentation/devicetree/bindings/sound/snd-soc-dummy
new file mode 100644
index 0000000..ea3fe0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/snd-soc-dummy
@@ -0,0 +1,13 @@ 
+snd-soc-dummy:
+
+ALSA SoC dummy codec.
+
+Required properties:
+
+  - compatible : "alsa-soc-dummy"
+
+Example:
+
+sound_dummy {
+	compatible = "alsa-soc-dummy";
+};
diff --git a/sound/soc/soc-utils.c b/sound/soc/soc-utils.c
index 7f22ca3..df11010 100644
--- a/sound/soc/soc-utils.c
+++ b/sound/soc/soc-utils.c
@@ -12,7 +12,8 @@ 
  *  Free Software Foundation;  either version 2 of the  License, or (at your
  *  option) any later version.
  */
-
+#include <linux/module.h>
+#include <linux/of.h>
 #include <linux/platform_device.h>
 #include <linux/export.h>
 #include <sound/core.h>
@@ -104,14 +105,12 @@  static struct snd_soc_codec_driver dummy_codec;
 static struct snd_soc_dai_driver dummy_dai = {
 	.name = "snd-soc-dummy-dai",
 	.playback = {
-		.stream_name	= "Playback",
 		.channels_min	= 1,
 		.channels_max	= 384,
 		.rates		= STUB_RATES,
 		.formats	= STUB_FORMATS,
 	},
 	.capture = {
-		.stream_name	= "Capture",
 		.channels_min	= 1,
 		.channels_max	= 384,
 		.rates = STUB_RATES,
@@ -151,10 +150,17 @@  static int snd_soc_dummy_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static struct of_device_id soc_dummy_of_match[] = {
+	{ .compatible = "alsa-soc-dummy" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, soc_dummy_of_match);
+
 static struct platform_driver soc_dummy_driver = {
 	.driver = {
 		.name = "snd-soc-dummy",
 		.owner = THIS_MODULE,
+		.of_match_table = soc_dummy_of_match,
 	},
 	.probe = snd_soc_dummy_probe,
 	.remove = snd_soc_dummy_remove,