Skip to contentSkip to conversation

ASoC: soc-pcm: Add support for unidirectional dai links

RFC In review Fabio Estevam 3 participants 4 messages Aug 29, 2013

Subsystems (3)
Sound Arm i.MX and Layerscape ASoC
lore
Share & tools
lore

Fabio Estevam

author reviewer
#0 lore raw

RFC 1/1 ASoC: soc-pcm: Add support for unidirectional dai links

From: Fabio Estevam <[email protected]>

On a mx28 board, running "aplay -l" and "arecord -l" results in the following:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: mxssgtl5000 [mxs_sgtl5000], device 0: Playback sgtl5000-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: mxssgtl5000 [mxs_sgtl5000], device 1: Capture sgtl5000-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: mxssgtl5000 [mxs_sgtl5000], device 0: Playback sgtl5000-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: mxssgtl5000 [mxs_sgtl5000], device 1: Capture sgtl5000-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

,which is not correct because we got a capture device listed in aplay and a playback device listed in arecord.

On mx28 there are two serial audio interface ports (SAIF0 and SAIF1) and each one of them are unidirectional.

Allow to specify a dai link as 'playback_only' or 'capture_only', which suits well for this case.

After this change we can correctly report the capabilities as follows:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: mxssgtl5000 [mxs_sgtl5000], device 0: HiFi Playback sgtl5000-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: mxssgtl5000 [mxs_sgtl5000], device 1: HiFi Capture sgtl5000-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Also tested playback and capture on the mx28evk board.

Signed-off-by Fabio Estevam <[email protected]>

---

After I get some feedback, I can split the patch in two parts (one for soc-pcm and another one for mxs-sgtl5000).

 include/sound/soc.h          |  4 ++++
 sound/soc/mxs/mxs-sgtl5000.c |  2 ++
 sound/soc/soc-pcm.c          | 10 ++++++++++
 3 files changed, 16 insertions(+)
include/sound/soc.h +4 -0
index 8e2ad52..774d3be 100644
@@ -934,6 +934,10 @@ struct snd_soc_dai_link {
 	/* machine stream operations */
 	const struct snd_soc_ops *ops;
 	const struct snd_soc_compr_ops *compr_ops;
+
+	/* For unidirectional dai links */
+	bool playback_only;
+	bool capture_only;
 };
 
 struct snd_soc_codec_conf {
sound/soc/mxs/mxs-sgtl5000.c +2 -0
index ce084eb..4bb2737 100644
@@ -105,11 +105,13 @@ static struct snd_soc_dai_link mxs_sgtl5000_dai[] = {
 		.stream_name	= "HiFi Playback",
 		.codec_dai_name	= "sgtl5000",
 		.ops		= &mxs_sgtl5000_hifi_ops,
+		.playback_only	= true,
 	}, {
 		.name		= "HiFi Rx",
 		.stream_name	= "HiFi Capture",
 		.codec_dai_name	= "sgtl5000",
 		.ops		= &mxs_sgtl5000_hifi_ops,
+		.capture_only	= true,
 	},
 };
sound/soc/soc-pcm.c +10 -0
index fb70fbe..5e44863 100644
@@ -2020,6 +2020,16 @@ int soc_new_pcm(struct snd_soc_pcm_runtime *rtd, int num)
 			capture = 1;
 	}
 
+	if (rtd->dai_link->playback_only) {
+		playback = 1;
+		capture = 0;
+	}
+
+	if (rtd->dai_link->capture_only) {
+		playback = 0;
+		capture = 1;
+	}
+
 	/* create the PCM */
 	if (rtd->dai_link->no_pcm) {
 		snprintf(new_name, sizeof(new_name), "(%s)",
Signature · 1 line
1.8.1.2
maintainer
#1 lore raw

sound/soc/mxs/mxs-sgtl5000.c static struct snd_soc_dai_link mxs_sgtl5000_dai[] = { · line 115

Quoted 12 lines · Fabio Estevam
sound/soc/mxs/mxs-sgtl5000.c +2 -0
@@ -105,11 +105,13 @@ static struct snd_soc_dai_link mxs_sgtl5000_dai[] = {
 		.stream_name	= "HiFi Playback",
 		.codec_dai_name	= "sgtl5000",
 		.ops		= &mxs_sgtl5000_hifi_ops,
+		.playback_only	= true,
 	}, {
 		.name		= "HiFi Rx",
 		.stream_name	= "HiFi Capture",
 		.codec_dai_name	= "sgtl5000",
 		.ops		= &mxs_sgtl5000_hifi_ops,
+		.capture_only	= true,
 	},

This doesn't make much sense to me - it should be possible to tell from the capabilities of the two DAIs on the link if they support both playback and capture. Or has the board wired up two bidirectional DAIs on each link for some reason?

#2 lore raw
Quoted 11 lines · Mark Brown
Quoted 9 lines · Fabio Estevam
sound/soc/mxs/mxs-sgtl5000.c +1 -0
@@ -105,11 +105,13 @@ static struct snd_soc_dai_link mxs_sgtl5000_dai[] = {
 		.stream_name	= "HiFi Playback",
 		.codec_dai_name	= "sgtl5000",
 		.ops		= &mxs_sgtl5000_hifi_ops,
+		.playback_only	= true,
 	}, {
 		.name		= "HiFi Rx",
 		.stream_name	= "HiFi Capture",
 		.codec_dai_name	= "sgtl5000",
Quoted 9 lines

sound/soc/mxs/mxs-sgtl5000.c static struct snd_soc_dai_link mxs_sgtl5000_dai[] = { · line 115

Quoted 3 lines
sound/soc/mxs/mxs-sgtl5000.c +1 -0
 		.ops		= &mxs_sgtl5000_hifi_ops,
+		.capture_only	= true,
 	},

This doesn't make much sense to me - it should be possible to tell from the capabilities of the two DAIs on the link if they support both playback and capture. Or has the board wired up two bidirectional DAIs on each link for some reason?

The MXS DAIs are unidirectional, but the direction can be configured at runtime. The alternative here is to specify the direction at driver probe time instead of in the dai_link.

maintainer
#3 lore raw
Quoted 10 lines · Lars-Peter Clausen
Quoted 4 lines · Mark Brown

This doesn't make much sense to me - it should be possible to tell from the capabilities of the two DAIs on the link if they support both playback and capture. Or has the board wired up two bidirectional DAIs on each link for some reason?

The MXS DAIs are unidirectional, but the direction can be configured at runtime. The alternative here is to specify the direction at driver probe time instead of in the dai_link.

Ah, OK. That's somewhat interesting and is something that might happen for other devices - Fabio can you submit your patches please?