[PATCH 0/4] ASoC: add graph base connection on simple-card

[PATCH 0/4] ASoC: add graph base connection on simple-card

[Kuninori Morimoto]

Hi Mark

Current simple-card is using "sound-dai" base connection on DT,
but V4L2 is using graph base connection.
For example HDMI case, we would like to use both connection.
To above confusable connection method, and to reuse current resource,
this patch adds new function, and detect both "sound-dai" and "remote-endpoint"
on simple-card. like this

	sound {
		compatible = "simple-audio-card";
		...
		sndcpu: simple-audio-card,cpu {
			sound-dai = <&xxx>;
		};
		sndcodec: simple-audio-card,codec {
=>			remote-endpoint = <&out_hdmi>;
		};
	};

	xxx {
		...
		ports {
			...
			port@0 {
				reg = <0>;
				out_rgb: endpoint {
				};
			};
			port@1 {
				reg = <1>;
=>				out_hdmi: endpoint {
				};
			};
			...
		};
	};

Kuninori Morimoto (4):
      of_graph: add of_graph_get_endpoint_count()
      ASoC: add of_parse_snd_connection_with_args() for sound-dai/graph connection
      ASoC: snd_soc_of_get_dai_name() uses of_parse_snd_soc_connection_with_args()
      ASoC: simple-card: probe both sound-dai and remote-endpoint

 Documentation/devicetree/bindings/sound/simple-card.txt | 19 +++++++++++++++++++
 include/linux/of_graph.h                                | 11 +++++++++++
 include/sound/soc.h                                     |  2 ++
 sound/soc/generic/simple-card.c                         |  9 ++++++---
 sound/soc/soc-core.c                                    | 45 +++++++++++++++++++++++++++++++++++++++++++--
 5 files changed, 81 insertions(+), 5 deletions(-)

[PATCH 1/4] of_graph: add of_graph_get_endpoint_count()

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

same as of_get_child_count()

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 include/linux/of_graph.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index f8bcd0e..4b9c3c5 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -91,4 +91,15 @@ static inline struct device_node *of_graph_get_remote_port(
 
 #endif /* CONFIG_OF */
 
+static inline int of_graph_get_endpoint_count(const struct device_node *np)
+{
+	struct device_node *child;
+	int num = 0;
+
+	for_each_endpoint_of_node(np, child)
+		num++;
+
+	return num;
+}
+
 #endif /* __LINUX_OF_GRAPH_H */
-- 
1.9.1

[PATCH 2/4] ASoC: add of_parse_snd_connection_with_args() for sound-dai/graph connection

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Current ASoC card connection is based on "sound-dai" on DT,
but V4L2 connection is using graph base.
This patch adds common function which can detect both connection.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 include/sound/soc.h  |  2 ++
 sound/soc/soc-core.c | 42 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index 02b4a21..17ddc25 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1669,6 +1669,8 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
 				     const char *prefix,
 				     struct device_node **bitclkmaster,
 				     struct device_node **framemaster);
+int of_parse_snd_soc_connection_with_args(const struct device_node *np,
+					  struct of_phandle_args *out_args);
 int snd_soc_of_get_dai_name(struct device_node *of_node,
 			    const char **dai_name);
 int snd_soc_of_get_dai_link_codecs(struct device *dev,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index d2e62b15..643b244 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -34,6 +34,7 @@
 #include <linux/ctype.h>
 #include <linux/slab.h>
 #include <linux/of.h>
+#include <linux/of_graph.h>
 #include <sound/core.h>
 #include <sound/jack.h>
 #include <sound/pcm.h>
@@ -3839,6 +3840,47 @@ static int snd_soc_get_dai_name(struct of_phandle_args *args,
 	return ret;
 }
 
+int of_parse_snd_soc_connection_with_args(const struct device_node *np,
+					  struct of_phandle_args *out_args)
+{
+	int ret;
+
+	ret = of_parse_phandle_with_args(np, "sound-dai",
+					 "#sound-dai-cells", 0, out_args);
+	if (ret) {
+		struct device_node *p_node = NULL;
+		struct device_node *ep_node = NULL;
+		struct of_endpoint ep;
+
+		/* try graph base parse */
+		p_node = of_graph_get_remote_port_parent(np);
+		if (!p_node)
+			return -EINVAL;
+
+		ep_node = of_graph_get_remote_port(np);
+		if (!p_node) {
+			ret = -EINVAL;
+			goto graph_err_parent;
+		}
+
+		ret = of_graph_parse_endpoint(ep_node, &ep);
+		if (ret < 0)
+			goto graph_err_endpoint;
+
+		out_args->np		= p_node;
+		out_args->args_count	= (1 != of_graph_get_endpoint_count(p_node));
+		out_args->args[0]	= ep.port;
+
+graph_err_endpoint:
+		of_node_put(ep_node);
+graph_err_parent:
+		of_node_put(p_node);
+	}
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_parse_snd_soc_connection_with_args);
+
 int snd_soc_of_get_dai_name(struct device_node *of_node,
 			    const char **dai_name)
 {
-- 
1.9.1

Re: [alsa-devel] [PATCH 2/4] ASoC: add of_parse_snd_connection_with_args() for sound-dai/graph connection

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

Hi Kuninori,

[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.6-rc3 next-20160413]
[if your patch is applied to the wrong git tree, please drop us a note to help improving the system]

url:    https://github.com/0day-ci/linux/commits/Kuninori-Morimoto/ASoC-add-graph-base-connection-on-simple-card/20160414-135303
base:   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
config: x86_64-randconfig-x013-201615 (attached as .config)
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   sound/soc/soc-core.c: In function 'of_parse_snd_soc_connection_with_args':
>> sound/soc/soc-core.c:3848:35: warning: passing argument 1 of 'of_parse_phandle_with_args' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
     ret = of_parse_phandle_with_args(np, "sound-dai",
                                      ^
   In file included from sound/soc/soc-core.c:36:0:
   include/linux/of.h:588:19: note: expected 'struct device_node *' but argument is of type 'const struct device_node *'
    static inline int of_parse_phandle_with_args(struct device_node *np,
                      ^

vim +3848 sound/soc/soc-core.c

  3832				*dai_name = pos->dai_drv[id].name;
  3833				if (!*dai_name)
  3834					*dai_name = pos->name;
  3835			}
  3836	
  3837			break;
  3838		}
  3839		mutex_unlock(&client_mutex);
  3840		return ret;
  3841	}
  3842	
  3843	int of_parse_snd_soc_connection_with_args(const struct device_node *np,
  3844						  struct of_phandle_args *out_args)
  3845	{
  3846		int ret;
  3847	
> 3848		ret = of_parse_phandle_with_args(np, "sound-dai",
  3849						 "#sound-dai-cells", 0, out_args);
  3850		if (ret) {
  3851			struct device_node *p_node = NULL;
  3852			struct device_node *ep_node = NULL;
  3853			struct of_endpoint ep;
  3854	
  3855			/* try graph base parse */
  3856			p_node = of_graph_get_remote_port_parent(np);

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 28358 bytes --]

[PATCH] of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

commit 93c667ca2598bd84f1bd3f2fa176af69707699fe
("of: *node argument to of_parse_phandle_with_args should be const")
changed struct device node *np as "const".
but it cares CONFIG_OF case only, !CONFIG_OF case need it too.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 include/linux/of.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index 7fcb681..4f2ce1b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -585,7 +585,7 @@ static inline struct device_node *of_parse_phandle(const struct device_node *np,
 	return NULL;
 }
 
-static inline int of_parse_phandle_with_args(struct device_node *np,
+static inline int of_parse_phandle_with_args(const struct device_node *np,
 					     const char *list_name,
 					     const char *cells_name,
 					     int index,
-- 
1.9.1

[PATCH] of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

commit 93c667ca2598bd84f1bd3f2fa176af69707699fe
("of: *node argument to of_parse_phandle_with_args should be const")
changed struct device node *np as "const".
but it cares CONFIG_OF case only, !CONFIG_OF case need it too.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 include/linux/of.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index 7fcb681..4f2ce1b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -585,7 +585,7 @@ static inline struct device_node *of_parse_phandle(const struct device_node *np,
 	return NULL;
 }
 
-static inline int of_parse_phandle_with_args(struct device_node *np,
+static inline int of_parse_phandle_with_args(const struct device_node *np,
 					     const char *list_name,
 					     const char *cells_name,
 					     int index,
-- 
1.9.1

[PATCH][RESEND] of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

commit 93c667ca2598bd84f1bd3f2fa176af69707699fe
("of: *node argument to of_parse_phandle_with_args should be const")
changed struct device node *np as "const".
but it cares CONFIG_OF case only, !CONFIG_OF case need it too.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 include/linux/of.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index 7fcb681..4f2ce1b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -585,7 +585,7 @@ static inline struct device_node *of_parse_phandle(const struct device_node *np,
 	return NULL;
 }
 
-static inline int of_parse_phandle_with_args(struct device_node *np,
+static inline int of_parse_phandle_with_args(const struct device_node *np,
 					     const char *list_name,
 					     const char *cells_name,
 					     int index,
-- 
1.9.1

[PATCH][RESEND] of: add missing const for of_parse_phandle_with_args() in !CONFIG_OF

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

commit 93c667ca2598bd84f1bd3f2fa176af69707699fe
("of: *node argument to of_parse_phandle_with_args should be const")
changed struct device node *np as "const".
but it cares CONFIG_OF case only, !CONFIG_OF case need it too.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 include/linux/of.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/of.h b/include/linux/of.h
index 7fcb681..4f2ce1b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -585,7 +585,7 @@ static inline struct device_node *of_parse_phandle(const struct device_node *np,
 	return NULL;
 }
 
-static inline int of_parse_phandle_with_args(struct device_node *np,
+static inline int of_parse_phandle_with_args(const struct device_node *np,
 					     const char *list_name,
 					     const char *cells_name,
 					     int index,
-- 
1.9.1

[PATCH 3/4] ASoC: snd_soc_of_get_dai_name() uses of_parse_snd_soc_connection_with_args()

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 sound/soc/soc-core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 643b244..fed5076 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3887,8 +3887,7 @@ int snd_soc_of_get_dai_name(struct device_node *of_node,
 	struct of_phandle_args args;
 	int ret;
 
-	ret = of_parse_phandle_with_args(of_node, "sound-dai",
-					 "#sound-dai-cells", 0, &args);
+	ret = of_parse_snd_soc_connection_with_args(of_node, &args);
 	if (ret)
 		return ret;
 
-- 
1.9.1

[PATCH 4/4] ASoC: simple-card: probe both sound-dai and remote-endpoint

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Current simple-card can probe "sound-dai" base connection on DT.
OTOH, V4L2 soc is using graph base connection. Because of this
different style, DT will be confusable if it support both
video/sound in same time.

This patch enables both "sound-dai" (= current simple-card style)
and "remote-endpoint" (= current V4L2 style) on simple-card.

	sound {
		compatible = "simple-audio-card";
		...
		sndcpu: simple-audio-card,cpu {
			sound-dai = <&xxxx>;
		};
		sndcodec: simple-audio-card,codec {
			remote-endpoint = <&yyyy>;
		};
	};

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 .../devicetree/bindings/sound/simple-card.txt         | 19 +++++++++++++++++++
 sound/soc/generic/simple-card.c                       |  9 ++++++---
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt
index cf3979e..030edca 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -70,6 +70,7 @@ properties should also be placed in the codec node if needed.
 Required CPU/CODEC subnodes properties:
 
 - sound-dai				: phandle and port of CPU/CODEC
+- remote-endpoint			: graph endpoint of CPU/CODEC
 
 Optional CPU/CODEC subnodes properties:
 
@@ -162,3 +163,21 @@ sound {
 		};
 	};
 };
+
+Example 3 - sound-dai and remote-endpoint
+
+rsnd_ak4613: sound {
+	compatible = "simple-audio-card";
+
+	simple-audio-card,name = "R-Sound";
+	simple-audio-card,format = "left_j";
+	simple-audio-card,bitclock-master = <&sndcpu>;
+	simple-audio-card,frame-master = <&sndcpu>;
+
+	sndcpu: simple-audio-card,cpu {
+		sound-dai = <&rcar_sound 1>;
+	};
+	sndcodec: simple-audio-card,codec {
+		remote-endpoint = <&du_out_hdmi0>;
+	};
+};
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 2389ab4..a1d6001 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -14,6 +14,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_gpio.h>
+#include <linux/of_graph.h>
 #include <linux/platform_device.h>
 #include <linux/string.h>
 #include <sound/jack.h>
@@ -224,11 +225,13 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
 	int ret;
 
 	/*
-	 * Get node via "sound-dai = <&phandle port>"
+	 * Get node via
+	 *	sound-dai = <&phandle port>
+	 * or
+	 *	remote-endpoint = <&phandle>
 	 * it will be used as xxx_of_node on soc_bind_dai_link()
 	 */
-	ret = of_parse_phandle_with_args(np, "sound-dai",
-					 "#sound-dai-cells", 0, &args);
+	ret = of_parse_snd_soc_connection_with_args(np, &args);
 	if (ret)
 		return ret;
 
-- 
1.9.1

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Jean-Francois Moine]

On Thu, 14 Apr 2016 05:45:41 +0000
Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:

> Current simple-card is using "sound-dai" base connection on DT,
> but V4L2 is using graph base connection.
> For example HDMI case, we would like to use both connection.
> To above confusable connection method, and to reuse current resource,
> this patch adds new function, and detect both "sound-dai" and "remote-endpoint"
> on simple-card. like this
> 
> 	sound {
> 		compatible = "simple-audio-card";
> 		...
> 		sndcpu: simple-audio-card,cpu {
> 			sound-dai = <&xxx>;
> 		};
> 		sndcodec: simple-audio-card,codec {
> =>			remote-endpoint = <&out_hdmi>;
> 		};
> 	};
> 
> 	xxx {
> 		...
> 		ports {
> 			...
> 			port@0 {
> 				reg = <0>;
> 				out_rgb: endpoint {
> 				};
> 			};
> 			port@1 {
> 				reg = <1>;
> =>				out_hdmi: endpoint {
> 				};
> 			};
> 			...
> 		};
> 	};
	[snip]

Hi Kuninori,

Thanks for this first step towards the graph of ports in audio,
but I don't see exactly the use of this remote-endpoint.

According to Documentation/devicetree/bindings/graph.txt section
"Links between endpoints", the endpoint/remote-endpoint links are
bi-directional and describe the physical links: the audio port of the
codec is connected to the audio controller and reverse.
There is no reverse link from the codec to the 'simple-card'.

If the codec has only one DAI, using the remote-port just complexifies
the access to the codec (remote-port -> endpoint -> parent [->parent]).

If the codec has more than one audio input, a DT may look like:

	hdmi_transmitter {
		...
		port@1 {			/* audio from I2S */
			reg = <1>;
			...
			i2s: endpoint {
				remote-endpoint = <&audio_i2s>;
			};
		};
		port@2 {			 /* audio from S/PDIF */
			reg = <2>;
			...
			spdif: endpoint {
				remote-endpoint = <&audio_spdif>;
			};
		};
	};
(the video port is not shown and may be declared before, between or
after the audio ports)

The codec associated to the HDMI transmitter declares 2 DAIs.
It may choose to define the DAI numbers either in a fixed order
(say 0 is always S/PDIF and 1 is always I2S), or dynamically, following
the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).

As the DAI numbers are used by the simple card to get the DAI names,
their values must be know.

With the standard declaration of the codec DAIs in the simple card
(phandle to the codec - hdmi -  plus DAI number), either numbering
scheme works (the documentation of the hdmi transmitter tells which
scheme is used and the DAI number in the DT is set accordingly).

When using a phandle to the remote-endpoint (without DAI number), the
simple card has no direct way to find the DAI number:
- with a fixed order, some more information must be set in the DT
  (audio port type),
- with a dynamic order, a loop on all ports must be done, counting the
  audio ports and skipping the video port(s).

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Jean-Francois Moine]

On Thu, 14 Apr 2016 05:45:41 +0000
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:

> Current simple-card is using "sound-dai" base connection on DT,
> but V4L2 is using graph base connection.
> For example HDMI case, we would like to use both connection.
> To above confusable connection method, and to reuse current resource,
> this patch adds new function, and detect both "sound-dai" and "remote-endpoint"
> on simple-card. like this
> 
> 	sound {
> 		compatible = "simple-audio-card";
> 		...
> 		sndcpu: simple-audio-card,cpu {
> 			sound-dai = <&xxx>;
> 		};
> 		sndcodec: simple-audio-card,codec {
> =>			remote-endpoint = <&out_hdmi>;
> 		};
> 	};
> 
> 	xxx {
> 		...
> 		ports {
> 			...
> 			port@0 {
> 				reg = <0>;
> 				out_rgb: endpoint {
> 				};
> 			};
> 			port@1 {
> 				reg = <1>;
> =>				out_hdmi: endpoint {
> 				};
> 			};
> 			...
> 		};
> 	};
	[snip]

Hi Kuninori,

Thanks for this first step towards the graph of ports in audio,
but I don't see exactly the use of this remote-endpoint.

According to Documentation/devicetree/bindings/graph.txt section
"Links between endpoints", the endpoint/remote-endpoint links are
bi-directional and describe the physical links: the audio port of the
codec is connected to the audio controller and reverse.
There is no reverse link from the codec to the 'simple-card'.

If the codec has only one DAI, using the remote-port just complexifies
the access to the codec (remote-port -> endpoint -> parent [->parent]).

If the codec has more than one audio input, a DT may look like:

	hdmi_transmitter {
		...
		port@1 {			/* audio from I2S */
			reg = <1>;
			...
			i2s: endpoint {
				remote-endpoint = <&audio_i2s>;
			};
		};
		port@2 {			 /* audio from S/PDIF */
			reg = <2>;
			...
			spdif: endpoint {
				remote-endpoint = <&audio_spdif>;
			};
		};
	};
(the video port is not shown and may be declared before, between or
after the audio ports)

The codec associated to the HDMI transmitter declares 2 DAIs.
It may choose to define the DAI numbers either in a fixed order
(say 0 is always S/PDIF and 1 is always I2S), or dynamically, following
the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).

As the DAI numbers are used by the simple card to get the DAI names,
their values must be know.

With the standard declaration of the codec DAIs in the simple card
(phandle to the codec - hdmi -  plus DAI number), either numbering
scheme works (the documentation of the hdmi transmitter tells which
scheme is used and the DAI number in the DT is set accordingly).

When using a phandle to the remote-endpoint (without DAI number), the
simple card has no direct way to find the DAI number:
- with a fixed order, some more information must be set in the DT
  (audio port type),
- with a dynamic order, a loop on all ports must be done, counting the
  audio ports and skipping the video port(s).

-- 
Ken ar c'henta�	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Kuninori Morimoto]

Hi Jean

Thank you for your feedback

> According to Documentation/devicetree/bindings/graph.txt section
> "Links between endpoints", the endpoint/remote-endpoint links are
> bi-directional and describe the physical links: the audio port of the
> codec is connected to the audio controller and reverse.
> There is no reverse link from the codec to the 'simple-card'.
(snip)
> The codec associated to the HDMI transmitter declares 2 DAIs.
> It may choose to define the DAI numbers either in a fixed order
> (say 0 is always S/PDIF and 1 is always I2S), or dynamically, following
> the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).

My assumption was video/audio are using same port, but indeed
we need to care about more.

But, if we need to describe both "video port" and "audio port" separately
in graph, simple-card side doesn't need graph style IMO.
Because normal phandle style (= non graph style) is working already.

I thought that describing both "video" and "audio" is too much.
-> assume that video/audio can share same port
 -> this patch
  -> but thoughtless :P

I'm not sure, but do you think snd_soc_get_dai_name()::of_xlate_dai_name
can works for us ?

My concern is if audio side need to care/support "formal" graph style,
I think all cpu/codec/card driver (and soc-core too ?) need to be updated,
but it is too much for me.
if fake graph style (like this patch) is OK, I'm happy to hack it more.

Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Kuninori Morimoto]

Hi Jean

Thank you for your feedback

> According to Documentation/devicetree/bindings/graph.txt section
> "Links between endpoints", the endpoint/remote-endpoint links are
> bi-directional and describe the physical links: the audio port of the
> codec is connected to the audio controller and reverse.
> There is no reverse link from the codec to the 'simple-card'.
(snip)
> The codec associated to the HDMI transmitter declares 2 DAIs.
> It may choose to define the DAI numbers either in a fixed order
> (say 0 is always S/PDIF and 1 is always I2S), or dynamically, following
> the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).

My assumption was video/audio are using same port, but indeed
we need to care about more.

But, if we need to describe both "video port" and "audio port" separately
in graph, simple-card side doesn't need graph style IMO.
Because normal phandle style (= non graph style) is working already.

I thought that describing both "video" and "audio" is too much.
-> assume that video/audio can share same port
 -> this patch
  -> but thoughtless :P

I'm not sure, but do you think snd_soc_get_dai_name()::of_xlate_dai_name
can works for us ?

My concern is if audio side need to care/support "formal" graph style,
I think all cpu/codec/card driver (and soc-core too ?) need to be updated,
but it is too much for me.
if fake graph style (like this patch) is OK, I'm happy to hack it more.

Best regards
---
Kuninori Morimoto

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Kuninori Morimoto]

Hi again

> > According to Documentation/devicetree/bindings/graph.txt section
> > "Links between endpoints", the endpoint/remote-endpoint links are
> > bi-directional and describe the physical links: the audio port of the
> > codec is connected to the audio controller and reverse.
> > There is no reverse link from the codec to the 'simple-card'.
> (snip)
> > The codec associated to the HDMI transmitter declares 2 DAIs.
> > It may choose to define the DAI numbers either in a fixed order
> > (say 0 is always S/PDIF and 1 is always I2S), or dynamically, following
> > the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).
> 
> My assumption was video/audio are using same port, but indeed
> we need to care about more.
> 
> But, if we need to describe both "video port" and "audio port" separately
> in graph, simple-card side doesn't need graph style IMO.
> Because normal phandle style (= non graph style) is working already.
> 
> I thought that describing both "video" and "audio" is too much.
> -> assume that video/audio can share same port
>  -> this patch
>   -> but thoughtless :P
> 
> I'm not sure, but do you think snd_soc_get_dai_name()::of_xlate_dai_name
> can works for us ?
> 
> My concern is if audio side need to care/support "formal" graph style,
> I think all cpu/codec/card driver (and soc-core too ?) need to be updated,
> but it is too much for me.
> if fake graph style (like this patch) is OK, I'm happy to hack it more.

This "fake graph style" means it is supporting both graph's "remote-endpoint"
and current simple-card's "sound-dai" (= not 100% graph style).

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Jean-Francois Moine]

On Fri, 15 Apr 2016 09:26:03 +0000
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:

> > > According to Documentation/devicetree/bindings/graph.txt section
> > > "Links between endpoints", the endpoint/remote-endpoint links are
> > > bi-directional and describe the physical links: the audio port of the
> > > codec is connected to the audio controller and reverse.
> > > There is no reverse link from the codec to the 'simple-card'.
> > (snip)
> > > The codec associated to the HDMI transmitter declares 2 DAIs.
> > > It may choose to define the DAI numbers either in a fixed order
> > > (say 0 is always S/PDIF and 1 is always I2S), or dynamically, following
> > > the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).
> > 
> > My assumption was video/audio are using same port, but indeed
> > we need to care about more.
> > 
> > But, if we need to describe both "video port" and "audio port" separately
> > in graph, simple-card side doesn't need graph style IMO.
> > Because normal phandle style (= non graph style) is working already.
> > 
> > I thought that describing both "video" and "audio" is too much.
> > -> assume that video/audio can share same port
> >  -> this patch
> >   -> but thoughtless :P
> > 
> > I'm not sure, but do you think snd_soc_get_dai_name()::of_xlate_dai_name
> > can works for us ?
> > 
> > My concern is if audio side need to care/support "formal" graph style,
> > I think all cpu/codec/card driver (and soc-core too ?) need to be updated,
> > but it is too much for me.
> > if fake graph style (like this patch) is OK, I'm happy to hack it more.
> 
> This "fake graph style" means it is supporting both graph's "remote-endpoint"
> and current simple-card's "sound-dai" (= not 100% graph style).

Hi Kuninori,

Maybe I was not clear. Here is more information.

The simple-card must know the codec (DAI) device node and the DAI name
(found from the DAI number thanks to snd_soc_get_dai_name
()::of_xlate_dai_name()).

The actual definition "sound-dai" works directly in any case, with or
without a graph of ports. Indeed, the DAI of the codec must be known
(option fixed/dynamic number).

A graph of ports describes the links between the hardware components.
Fox example, in the (Dove) Cubox, the HDMI transmitter receives video
(one port) from the video controller and audio (2 ports) from the audio
controller. The graph is:

video <-----------------------\
                              v
       | i2s <------> CODEC = HDMI transmitter
audio <               ^
       | s/pdif <-----/
                       \---> S/PDIF connector

In the DT, the HDMI is described by:

	hdmi: hdmi-encoder {
		...
		port@0 {
			port-type = "video";
			port-value = <0x230145>;
			hdmi_0: endpoint {
				remote-endpoint = <&lcd0_0>;
			};
		};
		port@1 {			/* AP1 = I2S */
			port-type = "audio-i2s";
			port-value = <0x03>;
			tda998x_i2s: endpoint {
				remote-endpoint = <&audio1_i2s>;
			};
		};
		port@2 {			 /* AP2 = S/PDIF */
			port-type = "audio-spdif";
			port-value = <0x04>;
			tda998x_spdif: endpoint {
				remote-endpoint = <&audio1_spdif1>;
			};
		};
	};

As you may see, there is no port link to any audio card definition as
the 'simple-card'.

When using the simple-card, my definition was:
	sound {
		compatible = "simple-audio-card";
		simple-audio-card,name = "Cubox Audio";

		simple-audio-card,dai-link@0 {	/* S/PDIF -> HDMI & S/PDIF */
			format = "i2s";
			cpu {
				sound-dai = <&audio1 1>;
			};
			codec {
				sound-dai = <&hdmi 0>, <&spdif_codec>;
			};
		};

		simple-audio-card,dai-link@1 {	/* I2S -> HDMI */
			format = "i2s";
			cpu {
				sound-dai = <&audio1 0>;
			};
			codec {
				sound-dai = <&hdmi 1>;
			};
		};
	};

This worked fine, but I found that the simple-card was redondant with
the graph of ports, so, now, in my system, the card creation is done
only from the graph of ports (without any more information in the DT -
this system was proposed in january 2015
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086837.html
but rejected).

At startup time, the audio driver scans its ports in the graph.
This permits for it to create its own DAIs.
Then, it looks at the remote-ports. These ones define the DAI links:
the CPU side is a local DAI, and the CODEC side is the parent of the
remote port plus a DAI number.
The problem is that the DAI number is not in the DT. It must be
computed. This is simply done scanning the ports of the codec (remote)
node and skipping the non-audio ports (indeed, this works because the
hdmi codec uses a dynamic port numbering scheme).

For information here is the DT of the audio controller:

audio1: audio-controller@b4000 {
	audio-card,format = "i2s";
	port@0 {
		port-type = "spdif";
		audio1_spdif0: endpoint@0 {
			remote-endpoint = <&spdif_out>;
		};
		audio1_spdif1: endpoint@1 {
			remote-endpoint = <&tda998x_spdif>;
		};
	};
	port@1 {
		port-type = "i2s";
		audio1_i2s: endpoint {
			remote-endpoint = <&tda998x_i2s>;
		};
	};

So, in brief:
- the simple-card with only "sound-dai" works fine with or without a
  graph of ports,
- for a full use of the graph of ports, forget about the simple-card.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Jean-Francois Moine]

On Fri, 15 Apr 2016 09:26:03 +0000
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:

> > > According to Documentation/devicetree/bindings/graph.txt section
> > > "Links between endpoints", the endpoint/remote-endpoint links are
> > > bi-directional and describe the physical links: the audio port of the
> > > codec is connected to the audio controller and reverse.
> > > There is no reverse link from the codec to the 'simple-card'.
> > (snip)
> > > The codec associated to the HDMI transmitter declares 2 DAIs.
> > > It may choose to define the DAI numbers either in a fixed order
> > > (say 0 is always S/PDIF and 1 is always I2S), or dynamically, following
> > > the declaration of the ports (in the example, 0 is I2S and 1 is S/PDIF).
> > 
> > My assumption was video/audio are using same port, but indeed
> > we need to care about more.
> > 
> > But, if we need to describe both "video port" and "audio port" separately
> > in graph, simple-card side doesn't need graph style IMO.
> > Because normal phandle style (= non graph style) is working already.
> > 
> > I thought that describing both "video" and "audio" is too much.
> > -> assume that video/audio can share same port
> >  -> this patch
> >   -> but thoughtless :P
> > 
> > I'm not sure, but do you think snd_soc_get_dai_name()::of_xlate_dai_name
> > can works for us ?
> > 
> > My concern is if audio side need to care/support "formal" graph style,
> > I think all cpu/codec/card driver (and soc-core too ?) need to be updated,
> > but it is too much for me.
> > if fake graph style (like this patch) is OK, I'm happy to hack it more.
> 
> This "fake graph style" means it is supporting both graph's "remote-endpoint"
> and current simple-card's "sound-dai" (= not 100% graph style).

Hi Kuninori,

Maybe I was not clear. Here is more information.

The simple-card must know the codec (DAI) device node and the DAI name
(found from the DAI number thanks to snd_soc_get_dai_name
()::of_xlate_dai_name()).

The actual definition "sound-dai" works directly in any case, with or
without a graph of ports. Indeed, the DAI of the codec must be known
(option fixed/dynamic number).

A graph of ports describes the links between the hardware components.
Fox example, in the (Dove) Cubox, the HDMI transmitter receives video
(one port) from the video controller and audio (2 ports) from the audio
controller. The graph is:

video <-----------------------\
                              v
       | i2s <------> CODEC = HDMI transmitter
audio <               ^
       | s/pdif <-----/
                       \---> S/PDIF connector

In the DT, the HDMI is described by:

	hdmi: hdmi-encoder {
		...
		port@0 {
			port-type = "video";
			port-value = <0x230145>;
			hdmi_0: endpoint {
				remote-endpoint = <&lcd0_0>;
			};
		};
		port@1 {			/* AP1 = I2S */
			port-type = "audio-i2s";
			port-value = <0x03>;
			tda998x_i2s: endpoint {
				remote-endpoint = <&audio1_i2s>;
			};
		};
		port@2 {			 /* AP2 = S/PDIF */
			port-type = "audio-spdif";
			port-value = <0x04>;
			tda998x_spdif: endpoint {
				remote-endpoint = <&audio1_spdif1>;
			};
		};
	};

As you may see, there is no port link to any audio card definition as
the 'simple-card'.

When using the simple-card, my definition was:
	sound {
		compatible = "simple-audio-card";
		simple-audio-card,name = "Cubox Audio";

		simple-audio-card,dai-link@0 {	/* S/PDIF -> HDMI & S/PDIF */
			format = "i2s";
			cpu {
				sound-dai = <&audio1 1>;
			};
			codec {
				sound-dai = <&hdmi 0>, <&spdif_codec>;
			};
		};

		simple-audio-card,dai-link@1 {	/* I2S -> HDMI */
			format = "i2s";
			cpu {
				sound-dai = <&audio1 0>;
			};
			codec {
				sound-dai = <&hdmi 1>;
			};
		};
	};

This worked fine, but I found that the simple-card was redondant with
the graph of ports, so, now, in my system, the card creation is done
only from the graph of ports (without any more information in the DT -
this system was proposed in january 2015
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086837.html
but rejected).

At startup time, the audio driver scans its ports in the graph.
This permits for it to create its own DAIs.
Then, it looks at the remote-ports. These ones define the DAI links:
the CPU side is a local DAI, and the CODEC side is the parent of the
remote port plus a DAI number.
The problem is that the DAI number is not in the DT. It must be
computed. This is simply done scanning the ports of the codec (remote)
node and skipping the non-audio ports (indeed, this works because the
hdmi codec uses a dynamic port numbering scheme).

For information here is the DT of the audio controller:

audio1: audio-controller@b4000 {
	audio-card,format = "i2s";
	port@0 {
		port-type = "spdif";
		audio1_spdif0: endpoint@0 {
			remote-endpoint = <&spdif_out>;
		};
		audio1_spdif1: endpoint@1 {
			remote-endpoint = <&tda998x_spdif>;
		};
	};
	port@1 {
		port-type = "i2s";
		audio1_i2s: endpoint {
			remote-endpoint = <&tda998x_i2s>;
		};
	};

So, in brief:
- the simple-card with only "sound-dai" works fine with or without a
  graph of ports,
- for a full use of the graph of ports, forget about the simple-card.

-- 
Ken ar c'henta�	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [PATCH 0/4] ASoC: add graph base connection on simple-card

[Kuninori Morimoto]

Hi Jean

Thank you for clearing your problem.
Sorry for my confusable email.
But can I ask something ?

> > > My concern is if audio side need to care/support "formal" graph style,
> > > I think all cpu/codec/card driver (and soc-core too ?) need to be updated,
> > > but it is too much for me.
> > > if fake graph style (like this patch) is OK, I'm happy to hack it more.
> > 
> > This "fake graph style" means it is supporting both graph's "remote-endpoint"
> > and current simple-card's "sound-dai" (= not 100% graph style).
(snip)
> So, in brief:
> - the simple-card with only "sound-dai" works fine with or without a
>   graph of ports,
> - for a full use of the graph of ports, forget about the simple-card.

Q1
If we use full graph style card, and if it would like to reuse current existing
CPU/CODEC driver, then, I think CPU/CODEC driver should support graph style too.
(Now, I'm checking v4l2 side existing graph style driver)
I know it is based on its current implementation, but basically YES ?

Q2
If Q1 was Yes, to keeping ABI compatibility,
that CPU/CODEC driver should support both "phandle" and "graph" style ?

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Kuninori Morimoto]

Hi Jean

Thank you for clearing your problem.
Sorry for my confusable email.
But can I ask something ?

> > > My concern is if audio side need to care/support "formal" graph style,
> > > I think all cpu/codec/card driver (and soc-core too ?) need to be updated,
> > > but it is too much for me.
> > > if fake graph style (like this patch) is OK, I'm happy to hack it more.
> > 
> > This "fake graph style" means it is supporting both graph's "remote-endpoint"
> > and current simple-card's "sound-dai" (= not 100% graph style).
(snip)
> So, in brief:
> - the simple-card with only "sound-dai" works fine with or without a
>   graph of ports,
> - for a full use of the graph of ports, forget about the simple-card.

Q1
If we use full graph style card, and if it would like to reuse current existing
CPU/CODEC driver, then, I think CPU/CODEC driver should support graph style too.
(Now, I'm checking v4l2 side existing graph style driver)
I know it is based on its current implementation, but basically YES ?

Q2
If Q1 was Yes, to keeping ABI compatibility,
that CPU/CODEC driver should support both "phandle" and "graph" style ?

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Jean-Francois Moine]

On Mon, 18 Apr 2016 02:43:21 +0000
Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:

> But can I ask something ?
> 
> > > > My concern is if audio side need to care/support "formal" graph style,
> > > > I think all cpu/codec/card driver (and soc-core too ?) need to be updated,
> > > > but it is too much for me.
> > > > if fake graph style (like this patch) is OK, I'm happy to hack it more.
> > > 
> > > This "fake graph style" means it is supporting both graph's "remote-endpoint"
> > > and current simple-card's "sound-dai" (= not 100% graph style).
> (snip)
> > So, in brief:
> > - the simple-card with only "sound-dai" works fine with or without a
> >   graph of ports,
> > - for a full use of the graph of ports, forget about the simple-card.
> 
> Q1
> If we use full graph style card, and if it would like to reuse current existing
> CPU/CODEC driver, then, I think CPU/CODEC driver should support graph style too.
> (Now, I'm checking v4l2 side existing graph style driver)
> I know it is based on its current implementation, but basically YES ?
> 
> Q2
> If Q1 was Yes, to keeping ABI compatibility,
> that CPU/CODEC driver should support both "phandle" and "graph" style ?

Hi Kuninori,

When the cards are defined from a graph of ports, the CPU/CODEC drivers
do not need to know about this graph if they use a fixed numbering of
their DAIs (I think this is the case of all existing drivers but the
ones in my system). There is no useful information for these drivers
in the DT, so, they don't need any change when moving to a graph of
ports.

Such a move is done first in the DT by removing the simple-card node
and replacing the previous 'dai-link' definitions by couples of ports
in the CPU (audio controller) and in the CODEC device nodes.

The previous DAI properties (tdm-slots, clocks...) must also be moved
to the graph (ports of the graph links). As nothing exists about these
port properties in the DT documentation, they must be added.

The previous global (simple-)card properties (widgets, routing..) must
also be moved. Where? Simply to the main audio controller node.
They could be named 'audio-xxx' or included in an audio container.

Now, let's talk about the code. As there is no simple-card device to
create the card, an other piece of code must do the job.
The simplest way to run it is to put it in the audio controller:
when the audio controller scans the DT, it sees the card definitions
(audio-xxx' or audio container), so, it has all elements to create the
card.
This card is as generic as the simple-card, so it could be in the
sound/soc core.

So, in brief again: when using a full graph style card:
- there is no change in the CPU/CODEC drivers,
- there is no simple-card,
- the 'audio-graph-card's are created by the audio controllers which
  run a generic code.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Jean-Francois Moine]

On Mon, 18 Apr 2016 02:43:21 +0000
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:

> But can I ask something ?
> 
> > > > My concern is if audio side need to care/support "formal" graph style,
> > > > I think all cpu/codec/card driver (and soc-core too ?) need to be updated,
> > > > but it is too much for me.
> > > > if fake graph style (like this patch) is OK, I'm happy to hack it more.
> > > 
> > > This "fake graph style" means it is supporting both graph's "remote-endpoint"
> > > and current simple-card's "sound-dai" (= not 100% graph style).
> (snip)
> > So, in brief:
> > - the simple-card with only "sound-dai" works fine with or without a
> >   graph of ports,
> > - for a full use of the graph of ports, forget about the simple-card.
> 
> Q1
> If we use full graph style card, and if it would like to reuse current existing
> CPU/CODEC driver, then, I think CPU/CODEC driver should support graph style too.
> (Now, I'm checking v4l2 side existing graph style driver)
> I know it is based on its current implementation, but basically YES ?
> 
> Q2
> If Q1 was Yes, to keeping ABI compatibility,
> that CPU/CODEC driver should support both "phandle" and "graph" style ?

Hi Kuninori,

When the cards are defined from a graph of ports, the CPU/CODEC drivers
do not need to know about this graph if they use a fixed numbering of
their DAIs (I think this is the case of all existing drivers but the
ones in my system). There is no useful information for these drivers
in the DT, so, they don't need any change when moving to a graph of
ports.

Such a move is done first in the DT by removing the simple-card node
and replacing the previous 'dai-link' definitions by couples of ports
in the CPU (audio controller) and in the CODEC device nodes.

The previous DAI properties (tdm-slots, clocks...) must also be moved
to the graph (ports of the graph links). As nothing exists about these
port properties in the DT documentation, they must be added.

The previous global (simple-)card properties (widgets, routing..) must
also be moved. Where? Simply to the main audio controller node.
They could be named 'audio-xxx' or included in an audio container.

Now, let's talk about the code. As there is no simple-card device to
create the card, an other piece of code must do the job.
The simplest way to run it is to put it in the audio controller:
when the audio controller scans the DT, it sees the card definitions
(audio-xxx' or audio container), so, it has all elements to create the
card.
This card is as generic as the simple-card, so it could be in the
sound/soc core.

So, in brief again: when using a full graph style card:
- there is no change in the CPU/CODEC drivers,
- there is no simple-card,
- the 'audio-graph-card's are created by the audio controllers which
  run a generic code.

-- 
Ken ar c'henta�	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Kuninori Morimoto]

Hi Jean

Thank you for your kindly explanation.

> When the cards are defined from a graph of ports, the CPU/CODEC drivers
> do not need to know about this graph if they use a fixed numbering of
> their DAIs (I think this is the case of all existing drivers but the
> ones in my system). There is no useful information for these drivers
> in the DT, so, they don't need any change when moving to a graph of
> ports.
> 
> Such a move is done first in the DT by removing the simple-card node
> and replacing the previous 'dai-link' definitions by couples of ports
> in the CPU (audio controller) and in the CODEC device nodes.
> 
> The previous DAI properties (tdm-slots, clocks...) must also be moved
> to the graph (ports of the graph links). As nothing exists about these
> port properties in the DT documentation, they must be added.
> 
> The previous global (simple-)card properties (widgets, routing..) must
> also be moved. Where? Simply to the main audio controller node.
> They could be named 'audio-xxx' or included in an audio container.
> 
> Now, let's talk about the code. As there is no simple-card device to
> create the card, an other piece of code must do the job.
> The simplest way to run it is to put it in the audio controller:
> when the audio controller scans the DT, it sees the card definitions
> (audio-xxx' or audio container), so, it has all elements to create the
> card.
> This card is as generic as the simple-card, so it could be in the
> sound/soc core.
> 
> So, in brief again: when using a full graph style card:
> - there is no change in the CPU/CODEC drivers,
> - there is no simple-card,
> - the 'audio-graph-card's are created by the audio controllers which
>   run a generic code.

I could understand your idea,
and had read previous some discussions.
I would like to have it on upstream too.
Can you show me about your plan for next step ?

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Jean-Francois Moine]

On Wed, 20 Apr 2016 02:55:39 +0000
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:

> I could understand your idea,
> and had read previous some discussions.
> I would like to have it on upstream too.
> Can you show me about your plan for next step ?

Hi Kuninori,

I have no plan.
My Cubox machine has too many specific code and it is used in an organ
as the sound synthesizer. I will not do any more development in its
kernel.
In my new machine, an Orange PI 2, while audio on HDMI is working for
me, there is still a lot of job to do aside (YUV video, analog
audio, embedded wifi...) and I am blocked by the HDMI driver which has
no free license nor documentation about the hardware. So, I have not
submitted yet a patch series about audio for this machine.

Otherwise, if you read the previous discussions, I think the most
important is Mark's remark (Sat, 7 Feb 2015 16:33:55 +0800 in the
alsa-devel mailing-list):

> We already have simple-card to provide a binding for trivial
> systems and don't want to end up with a never ending series of slightly
> more complicated bindings which each cover slightly different sets of
> systems in ways that users struggle to differentiate between.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [alsa-devel] [PATCH 0/4] ASoC: add graph base connection on simple-card

[Jean-Francois Moine]

On Wed, 20 Apr 2016 02:55:39 +0000
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:

> I could understand your idea,
> and had read previous some discussions.
> I would like to have it on upstream too.
> Can you show me about your plan for next step ?

Hi Kuninori,

I have no plan.
My Cubox machine has too many specific code and it is used in an organ
as the sound synthesizer. I will not do any more development in its
kernel.
In my new machine, an Orange PI 2, while audio on HDMI is working for
me, there is still a lot of job to do aside (YUV video, analog
audio, embedded wifi...) and I am blocked by the HDMI driver which has
no free license nor documentation about the hardware. So, I have not
submitted yet a patch series about audio for this machine.

Otherwise, if you read the previous discussions, I think the most
important is Mark's remark (Sat, 7 Feb 2015 16:33:55 +0800 in the
alsa-devel mailing-list):

> We already have simple-card to provide a binding for trivial
> systems and don't want to end up with a never ending series of slightly
> more complicated bindings which each cover slightly different sets of
> systems in ways that users struggle to differentiate between.

-- 
Ken ar c'henta�	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [PATCH 0/4] ASoC: add graph base connection on simple-card

[Rob Herring]

On Thu, Apr 14, 2016 at 05:45:41AM +0000, Kuninori Morimoto wrote:
> Hi Mark
> 
> Current simple-card is using "sound-dai" base connection on DT,
> but V4L2 is using graph base connection.
> For example HDMI case, we would like to use both connection.
> To above confusable connection method, and to reuse current resource,
> this patch adds new function, and detect both "sound-dai" and "remote-endpoint"
> on simple-card. like this
> 
> 	sound {
> 		compatible = "simple-audio-card";
> 		...
> 		sndcpu: simple-audio-card,cpu {
> 			sound-dai = <&xxx>;
> 		};
> 		sndcodec: simple-audio-card,codec {
> =>			remote-endpoint = <&out_hdmi>;

This is not valid usage of the graph binding. You are only using half of 
it.

> 		};
> 	};
> 
> 	xxx {
> 		...
> 		ports {
> 			...
> 			port@0 {
> 				reg = <0>;
> 				out_rgb: endpoint {
> 				};
> 			};
> 			port@1 {
> 				reg = <1>;
> =>				out_hdmi: endpoint {
> 				};
> 			};
> 			...
> 		};
> 	};
> 
> Kuninori Morimoto (4):
>       of_graph: add of_graph_get_endpoint_count()
>       ASoC: add of_parse_snd_connection_with_args() for sound-dai/graph connection
>       ASoC: snd_soc_of_get_dai_name() uses of_parse_snd_soc_connection_with_args()
>       ASoC: simple-card: probe both sound-dai and remote-endpoint
> 
>  Documentation/devicetree/bindings/sound/simple-card.txt | 19 +++++++++++++++++++
>  include/linux/of_graph.h                                | 11 +++++++++++
>  include/sound/soc.h                                     |  2 ++
>  sound/soc/generic/simple-card.c                         |  9 ++++++---
>  sound/soc/soc-core.c                                    | 45 +++++++++++++++++++++++++++++++++++++++++++--
>  5 files changed, 81 insertions(+), 5 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] ASoC: add graph base connection on simple-card

[Rob Herring]

On Thu, Apr 14, 2016 at 05:45:41AM +0000, Kuninori Morimoto wrote:
> Hi Mark
> 
> Current simple-card is using "sound-dai" base connection on DT,
> but V4L2 is using graph base connection.
> For example HDMI case, we would like to use both connection.
> To above confusable connection method, and to reuse current resource,
> this patch adds new function, and detect both "sound-dai" and "remote-endpoint"
> on simple-card. like this
> 
> 	sound {
> 		compatible = "simple-audio-card";
> 		...
> 		sndcpu: simple-audio-card,cpu {
> 			sound-dai = <&xxx>;
> 		};
> 		sndcodec: simple-audio-card,codec {
> =>			remote-endpoint = <&out_hdmi>;

This is not valid usage of the graph binding. You are only using half of 
it.

> 		};
> 	};
> 
> 	xxx {
> 		...
> 		ports {
> 			...
> 			port@0 {
> 				reg = <0>;
> 				out_rgb: endpoint {
> 				};
> 			};
> 			port@1 {
> 				reg = <1>;
> =>				out_hdmi: endpoint {
> 				};
> 			};
> 			...
> 		};
> 	};
> 
> Kuninori Morimoto (4):
>       of_graph: add of_graph_get_endpoint_count()
>       ASoC: add of_parse_snd_connection_with_args() for sound-dai/graph connection
>       ASoC: snd_soc_of_get_dai_name() uses of_parse_snd_soc_connection_with_args()
>       ASoC: simple-card: probe both sound-dai and remote-endpoint
> 
>  Documentation/devicetree/bindings/sound/simple-card.txt | 19 +++++++++++++++++++
>  include/linux/of_graph.h                                | 11 +++++++++++
>  include/sound/soc.h                                     |  2 ++
>  sound/soc/generic/simple-card.c                         |  9 ++++++---
>  sound/soc/soc-core.c                                    | 45 +++++++++++++++++++++++++++++++++++++++++++--
>  5 files changed, 81 insertions(+), 5 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html