[PATCH v2 0/7] of_graph: prepare for ALSA graph support

[PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Kuninori Morimoto]

Hi Rob

These are v2 of of_graph patch-set

Now OF graph is mainly used by V4L2 SoC, and ALSA SoC is using
different style for SoC <-> Codec binding.
But, for example, HDMI case, V4L2 <-> ALSA need to collaborate,
and then ALSA SoC needs to adjust to OF graph.

OTOH, V4L2's "OF graph" position is same as ALSA SoC "sound card" position.
And ALSA SoC side want to keep existing supported feature on new
OF graph style. I'm posting this on ALSA SoC ML now.

Now, current of_graph is indicating port/endpoint,
but there is no way to understand that it is for video port ? or sound port ?
or other device port ?
For example, HDMI has video port, and sound port.
Because of this reason, ALSA SoC side can't handle OF graph correctly.
Thus, this patch-set tries to add new "type" on OF graph.

And this patch-set includes small feature which are useful for ALSA SoC
side OF graph support.

Kuninori Morimoto (7):
  Documentation: of: add type property
  of_graph: add of_graph_get_remote_endpoint()
  of_graph: add of_graph_port_type_is()
  of_graph: add of_graph_get_port_parent()
  of_graph: add of_graph_get_top_port()
  of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()
  of_graph: add of_graph_get_endpoint_count()

 Documentation/devicetree/bindings/graph.txt |  21 ++++
 drivers/of/base.c                           | 164 ++++++++++++++++++++++++++--
 include/linux/of_graph.h                    |  61 +++++++++++
 3 files changed, 236 insertions(+), 10 deletions(-)

-- 
1.9.1

[PATCH v2 1/7] Documentation: of: add type property

[Kuninori Morimoto]

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

OF graph indicates each devices connection. But it doesn't support type
of each port. For example HDMI case, it has video port and sound port
in one device node.
In this case, current driver can't handle each port correctly.
This patch enables to use type property on OF graph.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2
 - doesn't indicate Linux subsystem on git log
 - use HDMI example on graph.txt

 Documentation/devicetree/bindings/graph.txt | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/graph.txt
index fcb1c6a..fe6c8ce 100644
--- a/Documentation/devicetree/bindings/graph.txt
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -110,6 +110,27 @@ device-2 {
         };
 };
 
+port / endpoint type
+--------------------
+
+Each port can have its type if needed.
+For example HDMI case, it has video port and sound port.
+Below example indicates that port@0 is HDMI-video port,
+and port@1 is HDMI-sound port.
+
+HDMI {
+	port@0 {
+		type = "video";
+		endpoint {
+		};
+	};
+	port@1 {
+		type = "sound";
+		endpoint {
+		};
+	};
+};
+
 
 Required properties
 -------------------
-- 
1.9.1

[PATCH v2 1/7] Documentation: of: add type property

[Kuninori Morimoto]

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

OF graph indicates each devices connection. But it doesn't support type
of each port. For example HDMI case, it has video port and sound port
in one device node.
In this case, current driver can't handle each port correctly.
This patch enables to use type property on OF graph.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2
 - doesn't indicate Linux subsystem on git log
 - use HDMI example on graph.txt

 Documentation/devicetree/bindings/graph.txt | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/graph.txt
index fcb1c6a..fe6c8ce 100644
--- a/Documentation/devicetree/bindings/graph.txt
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -110,6 +110,27 @@ device-2 {
         };
 };
 
+port / endpoint type
+--------------------
+
+Each port can have its type if needed.
+For example HDMI case, it has video port and sound port.
+Below example indicates that port@0 is HDMI-video port,
+and port@1 is HDMI-sound port.
+
+HDMI {
+	port@0 {
+		type = "video";
+		endpoint {
+		};
+	};
+	port@1 {
+		type = "sound";
+		endpoint {
+		};
+	};
+};
+
 
 Required properties
 -------------------
-- 
1.9.1

[PATCH v2 2/7] of_graph: add of_graph_get_remote_endpoint()

[Kuninori Morimoto]

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

It should use same method to get same result.
To getting remote-endpoint node,
let's use of_graph_get_remote_endpoint()

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2

 - no change

 drivers/of/base.c        | 18 ++++++++++++++++--
 include/linux/of_graph.h |  8 ++++++++
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index ebf84e3..347118e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2327,6 +2327,20 @@ struct device_node *of_graph_get_endpoint_by_regs(
 EXPORT_SYMBOL(of_graph_get_endpoint_by_regs);
 
 /**
+ * of_graph_get_remote_endpoint() - get remote endpoint node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: Remote endpoint node associated with remote endpoint node linked
+ *	   to @node. Use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_remote_endpoint(const struct device_node *node)
+{
+	/* Get remote endpoint node. */
+	return of_parse_phandle(node, "remote-endpoint", 0);
+}
+EXPORT_SYMBOL(of_graph_get_remote_endpoint);
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
@@ -2340,7 +2354,7 @@ struct device_node *of_graph_get_remote_port_parent(
 	unsigned int depth;
 
 	/* Get remote endpoint node. */
-	np = of_parse_phandle(node, "remote-endpoint", 0);
+	np = of_graph_get_remote_endpoint(node);
 
 	/* Walk 3 levels up only if there is 'ports' node. */
 	for (depth = 3; depth && np; depth--) {
@@ -2364,7 +2378,7 @@ struct device_node *of_graph_get_remote_port(const struct device_node *node)
 	struct device_node *np;
 
 	/* Get remote endpoint node. */
-	np = of_parse_phandle(node, "remote-endpoint", 0);
+	np = of_graph_get_remote_endpoint(node);
 	if (!np)
 		return NULL;
 	return of_get_next_parent(np);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index bb3a5a2..d9d6d9c 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -48,6 +48,8 @@ struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
 					struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
 		const struct device_node *parent, int port_reg, int reg);
+struct device_node *of_graph_get_remote_endpoint(
+					const struct device_node *node);
 struct device_node *of_graph_get_remote_port_parent(
 					const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -78,6 +80,12 @@ static inline struct device_node *of_graph_get_endpoint_by_regs(
 	return NULL;
 }
 
+static inline struct device_node *of_graph_get_remote_endpoint(
+					const struct device_node *node)
+{
+	return NULL;
+}
+
 static inline struct device_node *of_graph_get_remote_port_parent(
 					const struct device_node *node)
 {
-- 
1.9.1

[PATCH v2 3/7] of_graph: add of_graph_port_type_is()

[Kuninori Morimoto]

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

OF graph indicates each devices connection. But it doesn't support type
of each port. For example HDMI case, it has video port and sound port
in one device node.
In this case, current driver can't handle each port correctly.

This patch adds of_graph_port_type_is() for it,
and adds of_graph_port_type_is_sound macro

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2

 - type_is port only

 drivers/of/base.c        | 14 ++++++++++++++
 include/linux/of_graph.h |  8 ++++++++
 2 files changed, 22 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 347118e..77c9e34 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2384,3 +2384,17 @@ struct device_node *of_graph_get_remote_port(const struct device_node *node)
 	return of_get_next_parent(np);
 }
 EXPORT_SYMBOL(of_graph_get_remote_port);
+
+bool of_graph_port_type_is(struct device_node *port, char *type)
+{
+	const char *prop = NULL;
+
+	of_property_read_string(port, "type", &prop);
+
+	if (prop &&
+	    strcmp(prop, type) == 0)
+		return true;
+
+	return false;
+}
+EXPORT_SYMBOL(of_graph_port_type_is);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index d9d6d9c..0a06441 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -40,9 +40,12 @@ struct of_endpoint {
 	for (child = of_graph_get_next_endpoint(parent, NULL); child != NULL; \
 	     child = of_graph_get_next_endpoint(parent, child))
 
+#define of_graph_port_type_is_sound(n)		of_graph_port_type_is(n, "sound")
+
 #ifdef CONFIG_OF
 int of_graph_parse_endpoint(const struct device_node *node,
 				struct of_endpoint *endpoint);
+bool of_graph_port_type_is(struct device_node *port, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
 struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
 					struct device_node *previous);
@@ -61,6 +64,11 @@ static inline int of_graph_parse_endpoint(const struct device_node *node,
 	return -ENOSYS;
 }
 
+static bool of_graph_port_type_is(struct device_node *port, char *type)
+{
+	return false;
+}
+
 static inline struct device_node *of_graph_get_port_by_id(
 					struct device_node *node, u32 id)
 {
-- 
1.9.1

[PATCH v2 4/7] of_graph: add of_graph_get_port_parent()

[Kuninori Morimoto]

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

Linux kernel already has of_graph_get_remote_port_parent(),
but, sometimes we want to get own port parent.
This patch adds of_graph_get_port_parent()

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2

 - no change

 drivers/of/base.c        | 30 ++++++++++++++++++++++--------
 include/linux/of_graph.h |  7 +++++++
 2 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 77c9e34..a059d59 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2341,6 +2341,27 @@ struct device_node *of_graph_get_remote_endpoint(const struct device_node *node)
 EXPORT_SYMBOL(of_graph_get_remote_endpoint);
 
 /**
+ * of_graph_get_port_parent() - get port's parent node
+ * @node: pointer to a local endpoint device_node
+ *
+ * Return: device node associated with endpoint node linked
+ *	   to @node. Use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_port_parent(struct device_node *node)
+{
+	unsigned int depth;
+
+	/* Walk 3 levels up only if there is 'ports' node. */
+	for (depth = 3; depth && node; depth--) {
+		node = of_get_next_parent(node);
+		if (depth == 2 && of_node_cmp(node->name, "ports"))
+			break;
+	}
+	return node;
+}
+EXPORT_SYMBOL(of_graph_get_port_parent);
+
+/**
  * of_graph_get_remote_port_parent() - get remote port's parent node
  * @node: pointer to a local endpoint device_node
  *
@@ -2351,18 +2372,11 @@ struct device_node *of_graph_get_remote_port_parent(
 			       const struct device_node *node)
 {
 	struct device_node *np;
-	unsigned int depth;
 
 	/* Get remote endpoint node. */
 	np = of_graph_get_remote_endpoint(node);
 
-	/* Walk 3 levels up only if there is 'ports' node. */
-	for (depth = 3; depth && np; depth--) {
-		np = of_get_next_parent(np);
-		if (depth == 2 && of_node_cmp(np->name, "ports"))
-			break;
-	}
-	return np;
+	return of_graph_get_port_parent(np);
 }
 EXPORT_SYMBOL(of_graph_get_remote_port_parent);
 
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 0a06441..0f362ed 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -53,6 +53,7 @@ struct device_node *of_graph_get_endpoint_by_regs(
 		const struct device_node *parent, int port_reg, int reg);
 struct device_node *of_graph_get_remote_endpoint(
 					const struct device_node *node);
+struct device_node *of_graph_get_port_parent(struct device_node *node);
 struct device_node *of_graph_get_remote_port_parent(
 					const struct device_node *node);
 struct device_node *of_graph_get_remote_port(const struct device_node *node);
@@ -94,6 +95,12 @@ static inline struct device_node *of_graph_get_remote_endpoint(
 	return NULL;
 }
 
+static inline struct device_node *of_graph_get_port_parent(
+	struct device_node *node)
+{
+	return NULL;
+}
+
 static inline struct device_node *of_graph_get_remote_port_parent(
 					const struct device_node *node)
 {
-- 
1.9.1

[PATCH v2 5/7] of_graph: add of_graph_get_top_port()

[Kuninori Morimoto]

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

driver want to get top level of port[s] node. This patch adds
of_graph_get_top_port() for this purpose

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2

 - no change

 drivers/of/base.c        | 24 ++++++++++++++++++++++++
 include/linux/of_graph.h |  2 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a059d59..a085961 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2225,6 +2225,30 @@ struct device_node *of_graph_get_port_by_id(struct device_node *parent, u32 id)
 EXPORT_SYMBOL(of_graph_get_port_by_id);
 
 /**
+ * of_graph_get_top_port() - get the top port node
+ * @dev: pointer to the device
+ *
+ * Return: A 'port' node pointer with refcount incremented. The caller
+ * has to use of_node_put() on it when done.
+ */
+struct device_node *of_graph_get_top_port(struct device *dev)
+{
+	struct device_node *np = dev->of_node;
+	struct device_node *node;
+
+	node = of_get_child_by_name(np, "ports");
+	if (node)
+		return node;
+
+	node = of_get_child_by_name(np, "port");
+	if (node)
+		return node;
+
+	return NULL;
+}
+EXPORT_SYMBOL(of_graph_get_top_port);
+
+/**
  * of_graph_get_next_endpoint() - get next endpoint node
  * @parent: pointer to the parent device node
  * @prev: previous endpoint node, or NULL to get first
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 0f362ed..35e9a6e 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -14,6 +14,7 @@
 #ifndef __LINUX_OF_GRAPH_H
 #define __LINUX_OF_GRAPH_H
 
+#include <linux/device.h>
 #include <linux/types.h>
 #include <linux/errno.h>
 
@@ -47,6 +48,7 @@ int of_graph_parse_endpoint(const struct device_node *node,
 				struct of_endpoint *endpoint);
 bool of_graph_port_type_is(struct device_node *port, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
+struct device_node *of_graph_get_top_port(struct device *dev);
 struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
 					struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
-- 
1.9.1

[PATCH v2 6/7] of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()

[Kuninori Morimoto]

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

OF graph indicates each devices connection. It already has
for_each_endpoint_of_node() which is for-loop for each endpoint.
But, some driver needs for-loop for each port[s], and for-loop for
each endpoint in port[s]. This patch adds for_each_of_port()
and for_each_of_endpoint_in_port() for this purpose.

And it also adds for_each_of_endpoint() which is similar to
for_each_endpoint_of_node(). The difference is it can catch port
handle during for-loop.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 drivers/of/base.c        | 62 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_graph.h | 28 ++++++++++++++++++++++
 2 files changed, 90 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a085961..a39d483 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2249,6 +2249,68 @@ struct device_node *of_graph_get_top_port(struct device *dev)
 EXPORT_SYMBOL(of_graph_get_top_port);
 
 /**
+ * of_graph_get_next_port() - get next port node
+ * @parent: pointer to the parent device node
+ * @prev: previous endpoint node, or NULL to get first
+ *
+ * Return: An 'endpoint' node pointer with refcount incremented. Refcount
+ * of the passed @prev node is decremented.
+ */
+struct device_node *of_graph_get_next_port(const struct device_node *parent,
+					   struct device_node *prev)
+{
+	struct device_node *port;
+	struct device_node *node;
+
+	if (!parent)
+		return NULL;
+
+	node = of_get_child_by_name(parent, "ports");
+	if (node)
+		parent = node;
+
+	/*
+	 * Start by locating the port node. If no previous endpoint is specified
+	 * search for the first port node, otherwise get the previous endpoint
+	 * parent port node.
+	 */
+	if (!prev) {
+		port = of_get_child_by_name(parent, "port");
+		if (!port)
+			pr_err("%s(): no port node found in %s\n",
+			       __func__, parent->full_name);
+	} else {
+		do {
+			port = of_get_next_child(parent, prev);
+			if (!port)
+				break;
+		} while (of_node_cmp(port->name, "port"));
+	}
+
+	of_node_put(node);
+
+	return port;
+}
+EXPORT_SYMBOL(of_graph_get_next_port);
+
+/**
+ * of_graph_get_next_endpoint_in_port() - get next endpoint node in port
+ * @parent: pointer to the parent device node
+ * @prev: previous endpoint node, or NULL to get first
+ *
+ * Return: An 'endpoint' node pointer with refcount incremented. Refcount
+ * of the passed @prev node is decremented.
+ */
+struct device_node *of_graph_get_next_endpoint_in_port(const struct device_node *port,
+					       struct device_node *prev)
+{
+	if (!port)
+		return NULL;
+
+	return of_get_next_child(port, prev);
+}
+
+/**
  * of_graph_get_next_endpoint() - get next endpoint node
  * @parent: pointer to the parent device node
  * @prev: previous endpoint node, or NULL to get first
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 35e9a6e..c88b676 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -30,6 +30,16 @@ struct of_endpoint {
 	const struct device_node *local_node;
 };
 
+#define for_each_of_port(parent, port) \
+	for (port = of_graph_get_next_port(parent, NULL); port != NULL; \
+	     port = of_graph_get_next_port(parent, port))
+#define for_each_of_endpoint_in_port(port, ep) \
+	for (ep = of_graph_get_next_endpoint_in_port(port, NULL); ep != NULL; \
+	     ep = of_graph_get_next_endpoint_in_port(port, ep))
+#define for_each_of_endpoint(parent, port, ep) \
+	for_each_of_port(parent, port) \
+		for_each_of_endpoint_in_port(port, ep)
+
 /**
  * for_each_endpoint_of_node - iterate over every endpoint in a device node
  * @parent: parent device node containing ports and endpoints
@@ -49,6 +59,10 @@ int of_graph_parse_endpoint(const struct device_node *node,
 bool of_graph_port_type_is(struct device_node *port, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
 struct device_node *of_graph_get_top_port(struct device *dev);
+struct device_node *of_graph_get_next_port(const struct device_node *parent,
+					struct device_node *prev);
+struct device_node *of_graph_get_next_endpoint_in_port(const struct device_node *port,
+						struct device_node *prev);
 struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
 					struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
@@ -78,6 +92,20 @@ static inline struct device_node *of_graph_get_port_by_id(
 	return NULL;
 }
 
+static inline struct device_node *of_graph_get_next_port(
+					const struct device_node *parent,
+					struct device_node *prev)
+{
+	return NULL;
+}
+
+static inline struct device_node *of_graph_get_next_endpoint_in_port(
+					const struct device_node *port,
+					struct device_node *prev)
+{
+	return NULL;
+}
+
 static inline struct device_node *of_graph_get_next_endpoint(
 					const struct device_node *parent,
 					struct device_node *previous)
-- 
1.9.1

[PATCH v2 6/7] of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>

OF graph indicates each devices connection. It already has
for_each_endpoint_of_node() which is for-loop for each endpoint.
But, some driver needs for-loop for each port[s], and for-loop for
each endpoint in port[s]. This patch adds for_each_of_port()
and for_each_of_endpoint_in_port() for this purpose.

And it also adds for_each_of_endpoint() which is similar to
for_each_endpoint_of_node(). The difference is it can catch port
handle during for-loop.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
 drivers/of/base.c        | 62 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_graph.h | 28 ++++++++++++++++++++++
 2 files changed, 90 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a085961..a39d483 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2249,6 +2249,68 @@ struct device_node *of_graph_get_top_port(struct device *dev)
 EXPORT_SYMBOL(of_graph_get_top_port);
 
 /**
+ * of_graph_get_next_port() - get next port node
+ * @parent: pointer to the parent device node
+ * @prev: previous endpoint node, or NULL to get first
+ *
+ * Return: An 'endpoint' node pointer with refcount incremented. Refcount
+ * of the passed @prev node is decremented.
+ */
+struct device_node *of_graph_get_next_port(const struct device_node *parent,
+					   struct device_node *prev)
+{
+	struct device_node *port;
+	struct device_node *node;
+
+	if (!parent)
+		return NULL;
+
+	node = of_get_child_by_name(parent, "ports");
+	if (node)
+		parent = node;
+
+	/*
+	 * Start by locating the port node. If no previous endpoint is specified
+	 * search for the first port node, otherwise get the previous endpoint
+	 * parent port node.
+	 */
+	if (!prev) {
+		port = of_get_child_by_name(parent, "port");
+		if (!port)
+			pr_err("%s(): no port node found in %s\n",
+			       __func__, parent->full_name);
+	} else {
+		do {
+			port = of_get_next_child(parent, prev);
+			if (!port)
+				break;
+		} while (of_node_cmp(port->name, "port"));
+	}
+
+	of_node_put(node);
+
+	return port;
+}
+EXPORT_SYMBOL(of_graph_get_next_port);
+
+/**
+ * of_graph_get_next_endpoint_in_port() - get next endpoint node in port
+ * @parent: pointer to the parent device node
+ * @prev: previous endpoint node, or NULL to get first
+ *
+ * Return: An 'endpoint' node pointer with refcount incremented. Refcount
+ * of the passed @prev node is decremented.
+ */
+struct device_node *of_graph_get_next_endpoint_in_port(const struct device_node *port,
+					       struct device_node *prev)
+{
+	if (!port)
+		return NULL;
+
+	return of_get_next_child(port, prev);
+}
+
+/**
  * of_graph_get_next_endpoint() - get next endpoint node
  * @parent: pointer to the parent device node
  * @prev: previous endpoint node, or NULL to get first
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 35e9a6e..c88b676 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -30,6 +30,16 @@ struct of_endpoint {
 	const struct device_node *local_node;
 };
 
+#define for_each_of_port(parent, port) \
+	for (port = of_graph_get_next_port(parent, NULL); port != NULL; \
+	     port = of_graph_get_next_port(parent, port))
+#define for_each_of_endpoint_in_port(port, ep) \
+	for (ep = of_graph_get_next_endpoint_in_port(port, NULL); ep != NULL; \
+	     ep = of_graph_get_next_endpoint_in_port(port, ep))
+#define for_each_of_endpoint(parent, port, ep) \
+	for_each_of_port(parent, port) \
+		for_each_of_endpoint_in_port(port, ep)
+
 /**
  * for_each_endpoint_of_node - iterate over every endpoint in a device node
  * @parent: parent device node containing ports and endpoints
@@ -49,6 +59,10 @@ int of_graph_parse_endpoint(const struct device_node *node,
 bool of_graph_port_type_is(struct device_node *port, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
 struct device_node *of_graph_get_top_port(struct device *dev);
+struct device_node *of_graph_get_next_port(const struct device_node *parent,
+					struct device_node *prev);
+struct device_node *of_graph_get_next_endpoint_in_port(const struct device_node *port,
+						struct device_node *prev);
 struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
 					struct device_node *previous);
 struct device_node *of_graph_get_endpoint_by_regs(
@@ -78,6 +92,20 @@ static inline struct device_node *of_graph_get_port_by_id(
 	return NULL;
 }
 
+static inline struct device_node *of_graph_get_next_port(
+					const struct device_node *parent,
+					struct device_node *prev)
+{
+	return NULL;
+}
+
+static inline struct device_node *of_graph_get_next_endpoint_in_port(
+					const struct device_node *port,
+					struct device_node *prev)
+{
+	return NULL;
+}
+
 static inline struct device_node *of_graph_get_next_endpoint(
 					const struct device_node *parent,
 					struct device_node *previous)
-- 
1.9.1

--
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

[PATCH v2 7/7] of_graph: add of_graph_get_endpoint_count()

[Kuninori Morimoto]

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

OF graph want to count its endpoint number, same as
of_get_child_count(). This patch adds of_graph_get_endpoint_count()
which can check specific type. It will count all endpoint if type
was NULL.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2

 - based on port_type_is

 drivers/of/base.c        | 16 ++++++++++++++++
 include/linux/of_graph.h |  8 ++++++++
 2 files changed, 24 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a39d483..84806196 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2498,3 +2498,19 @@ bool of_graph_port_type_is(struct device_node *port, char *type)
 	return false;
 }
 EXPORT_SYMBOL(of_graph_port_type_is);
+
+int of_graph_get_endpoint_count(const struct device_node *np, char *type)
+{
+	struct device_node *port, *endpoint;
+	int num = 0;
+
+	for_each_of_endpoint(np, port, endpoint) {
+		if (!type)
+			num++;
+		else
+			num += of_graph_port_type_is(port, type);
+	}
+
+	return num;
+}
+EXPORT_SYMBOL(of_graph_get_endpoint_count);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index c88b676..28c51c7 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -52,11 +52,13 @@ struct of_endpoint {
 	     child = of_graph_get_next_endpoint(parent, child))
 
 #define of_graph_port_type_is_sound(n)		of_graph_port_type_is(n, "sound")
+#define of_graph_get_sound_endpoint_count(n)	of_graph_get_endpoint_count(n, "sound")
 
 #ifdef CONFIG_OF
 int of_graph_parse_endpoint(const struct device_node *node,
 				struct of_endpoint *endpoint);
 bool of_graph_port_type_is(struct device_node *port, char *type);
+int of_graph_get_endpoint_count(const struct device_node *np, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
 struct device_node *of_graph_get_top_port(struct device *dev);
 struct device_node *of_graph_get_next_port(const struct device_node *parent,
@@ -86,6 +88,12 @@ static bool of_graph_port_type_is(struct device_node *port, char *type)
 	return false;
 }
 
+static inline int of_graph_get_endpoint_count(const struct device_node *np,
+					      char *type)
+{
+	return 0;
+}
+
 static inline struct device_node *of_graph_get_port_by_id(
 					struct device_node *node, u32 id)
 {
-- 
1.9.1

[PATCH v2 7/7] of_graph: add of_graph_get_endpoint_count()

[Kuninori Morimoto]

From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>

OF graph want to count its endpoint number, same as
of_get_child_count(). This patch adds of_graph_get_endpoint_count()
which can check specific type. It will count all endpoint if type
was NULL.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
v1 -> v2

 - based on port_type_is

 drivers/of/base.c        | 16 ++++++++++++++++
 include/linux/of_graph.h |  8 ++++++++
 2 files changed, 24 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a39d483..84806196 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2498,3 +2498,19 @@ bool of_graph_port_type_is(struct device_node *port, char *type)
 	return false;
 }
 EXPORT_SYMBOL(of_graph_port_type_is);
+
+int of_graph_get_endpoint_count(const struct device_node *np, char *type)
+{
+	struct device_node *port, *endpoint;
+	int num = 0;
+
+	for_each_of_endpoint(np, port, endpoint) {
+		if (!type)
+			num++;
+		else
+			num += of_graph_port_type_is(port, type);
+	}
+
+	return num;
+}
+EXPORT_SYMBOL(of_graph_get_endpoint_count);
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index c88b676..28c51c7 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -52,11 +52,13 @@ struct of_endpoint {
 	     child = of_graph_get_next_endpoint(parent, child))
 
 #define of_graph_port_type_is_sound(n)		of_graph_port_type_is(n, "sound")
+#define of_graph_get_sound_endpoint_count(n)	of_graph_get_endpoint_count(n, "sound")
 
 #ifdef CONFIG_OF
 int of_graph_parse_endpoint(const struct device_node *node,
 				struct of_endpoint *endpoint);
 bool of_graph_port_type_is(struct device_node *port, char *type);
+int of_graph_get_endpoint_count(const struct device_node *np, char *type);
 struct device_node *of_graph_get_port_by_id(struct device_node *node, u32 id);
 struct device_node *of_graph_get_top_port(struct device *dev);
 struct device_node *of_graph_get_next_port(const struct device_node *parent,
@@ -86,6 +88,12 @@ static bool of_graph_port_type_is(struct device_node *port, char *type)
 	return false;
 }
 
+static inline int of_graph_get_endpoint_count(const struct device_node *np,
+					      char *type)
+{
+	return 0;
+}
+
 static inline struct device_node *of_graph_get_port_by_id(
 					struct device_node *node, u32 id)
 {
-- 
1.9.1

--
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: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Mark Brown]

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

On Wed, Jun 29, 2016 at 12:33:15AM +0000, Kuninori Morimoto wrote:
> 
> Hi Rob
> 
> These are v2 of of_graph patch-set

Please stop sending things to my work address, that's not going to get
any extra attention paid to them.  I've got my kernel.org address in
MAINTAINERS and it's what I use consistently for upstream, please only
send patches there.

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

Re: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Mark Brown]

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

On Wed, Jun 29, 2016 at 12:33:15AM +0000, Kuninori Morimoto wrote:
> 
> Hi Rob
> 
> These are v2 of of_graph patch-set

Please stop sending things to my work address, that's not going to get
any extra attention paid to them.  I've got my kernel.org address in
MAINTAINERS and it's what I use consistently for upstream, please only
send patches there.

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

Re: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Kuninori Morimoto]

Hi Mark

> > 
> > Hi Rob
> > 
> > These are v2 of of_graph patch-set
> 
> Please stop sending things to my work address, that's not going to get
> any extra attention paid to them.  I've got my kernel.org address in
> MAINTAINERS and it's what I use consistently for upstream, please only
> send patches there.

I'm sorry about that.
I have dropped your non-kernel.org address from my mailer for upstream purpose

Re: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Kuninori Morimoto]

Hi Mark

> > 
> > Hi Rob
> > 
> > These are v2 of of_graph patch-set
> 
> Please stop sending things to my work address, that's not going to get
> any extra attention paid to them.  I've got my kernel.org address in
> MAINTAINERS and it's what I use consistently for upstream, please only
> send patches there.

I'm sorry about that.
I have dropped your non-kernel.org address from my mailer for upstream purpose

--
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: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Rob Herring]

On Wed, Jun 29, 2016 at 12:33:15AM +0000, Kuninori Morimoto wrote:
> 
> Hi Rob
> 
> These are v2 of of_graph patch-set
> 
> Now OF graph is mainly used by V4L2 SoC, and ALSA SoC is using
> different style for SoC <-> Codec binding.
> But, for example, HDMI case, V4L2 <-> ALSA need to collaborate,
> and then ALSA SoC needs to adjust to OF graph.
> 
> OTOH, V4L2's "OF graph" position is same as ALSA SoC "sound card" position.
> And ALSA SoC side want to keep existing supported feature on new
> OF graph style. I'm posting this on ALSA SoC ML now.
> 
> Now, current of_graph is indicating port/endpoint,
> but there is no way to understand that it is for video port ? or sound port ?
> or other device port ?

I need to see how you want to use this. I'm not completely convinced 
this is necessary as the port number should be meaningful. For example, 
port 0 is video and port 1 is audio. This information is specific to the 
local parent node which could be problematic if you have generic code 
parsing the local node. However, if you know which local port is audio, 
then you know the remote endpoint's port is also the audio port. 

> For example, HDMI has video port, and sound port.
> Because of this reason, ALSA SoC side can't handle OF graph correctly.
> Thus, this patch-set tries to add new "type" on OF graph.
> 
> And this patch-set includes small feature which are useful for ALSA SoC
> side OF graph support.

In general, all these helpers look okay if you have a user for them.

Rob

Re: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Rob Herring]

On Wed, Jun 29, 2016 at 12:33:15AM +0000, Kuninori Morimoto wrote:
> 
> Hi Rob
> 
> These are v2 of of_graph patch-set
> 
> Now OF graph is mainly used by V4L2 SoC, and ALSA SoC is using
> different style for SoC <-> Codec binding.
> But, for example, HDMI case, V4L2 <-> ALSA need to collaborate,
> and then ALSA SoC needs to adjust to OF graph.
> 
> OTOH, V4L2's "OF graph" position is same as ALSA SoC "sound card" position.
> And ALSA SoC side want to keep existing supported feature on new
> OF graph style. I'm posting this on ALSA SoC ML now.
> 
> Now, current of_graph is indicating port/endpoint,
> but there is no way to understand that it is for video port ? or sound port ?
> or other device port ?

I need to see how you want to use this. I'm not completely convinced 
this is necessary as the port number should be meaningful. For example, 
port 0 is video and port 1 is audio. This information is specific to the 
local parent node which could be problematic if you have generic code 
parsing the local node. However, if you know which local port is audio, 
then you know the remote endpoint's port is also the audio port. 

> For example, HDMI has video port, and sound port.
> Because of this reason, ALSA SoC side can't handle OF graph correctly.
> Thus, this patch-set tries to add new "type" on OF graph.
> 
> And this patch-set includes small feature which are useful for ALSA SoC
> side OF graph support.

In general, all these helpers look okay if you have a user for them.

Rob
--
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: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Kuninori Morimoto]

Hi Rob, Mark

Thank you for your feedback

> I need to see how you want to use this. I'm not completely convinced 
> this is necessary as the port number should be meaningful. For example, 
> port 0 is video and port 1 is audio. This information is specific to the 
> local parent node which could be problematic if you have generic code 
> parsing the local node. However, if you know which local port is audio, 
> then you know the remote endpoint's port is also the audio port. 

Yes, as you pointed, sound side (= ALSA SoC) will use generic driver
for sound card which needs to know its total port number.
Then, these patches are needed.

I posted OF graph part only this time, but of course I have total full-set
in my local environment.
But these are ...
 1) cleanup current generic sound driver (= almost 30 patch)
 2) OF graph new feature (= this patch-set) (= almost 10 patch)
 3) OF graph base generic sound driver (= almost 30 patch)
 - ...

I'm posting 1) part to ALSA SoC ML, 2) part to this ML.
1) will take more long term >> Mark ??
If you want to see this patch-set together with use case, then 3) is needed.
If so, I will merge 2) and 3), and post these to this ML and ALSA SoC ML.

Is it OK for you ? >> Rob, Mark
I don't know how to handle it, but I can follow your opinion

> In general, all these helpers look okay if you have a user for them.

Thanks.
As I explained above, it is based on 1) part, but it will takes more
long term.

Re: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Kuninori Morimoto]

Hi Rob, Mark

Thank you for your feedback

> I need to see how you want to use this. I'm not completely convinced 
> this is necessary as the port number should be meaningful. For example, 
> port 0 is video and port 1 is audio. This information is specific to the 
> local parent node which could be problematic if you have generic code 
> parsing the local node. However, if you know which local port is audio, 
> then you know the remote endpoint's port is also the audio port. 

Yes, as you pointed, sound side (= ALSA SoC) will use generic driver
for sound card which needs to know its total port number.
Then, these patches are needed.

I posted OF graph part only this time, but of course I have total full-set
in my local environment.
But these are ...
 1) cleanup current generic sound driver (= almost 30 patch)
 2) OF graph new feature (= this patch-set) (= almost 10 patch)
 3) OF graph base generic sound driver (= almost 30 patch)
 - ...

I'm posting 1) part to ALSA SoC ML, 2) part to this ML.
1) will take more long term >> Mark ??
If you want to see this patch-set together with use case, then 3) is needed.
If so, I will merge 2) and 3), and post these to this ML and ALSA SoC ML.

Is it OK for you ? >> Rob, Mark
I don't know how to handle it, but I can follow your opinion

> In general, all these helpers look okay if you have a user for them.

Thanks.
As I explained above, it is based on 1) part, but it will takes more
long term.

--
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: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Kuninori Morimoto]

Hi Rob, Mark, again

> Yes, as you pointed, sound side (= ALSA SoC) will use generic driver
> for sound card which needs to know its total port number.
> Then, these patches are needed.
> 
> I posted OF graph part only this time, but of course I have total full-set
> in my local environment.
> But these are ...
>  1) cleanup current generic sound driver (= almost 30 patch)
>  2) OF graph new feature (= this patch-set) (= almost 10 patch)
>  3) OF graph base generic sound driver (= almost 30 patch)
>  - ...
> 
> I'm posting 1) part to ALSA SoC ML, 2) part to this ML.
> 1) will take more long term >> Mark ??
> If you want to see this patch-set together with use case, then 3) is needed.
> If so, I will merge 2) and 3), and post these to this ML and ALSA SoC ML.
> 
> Is it OK for you ? >> Rob, Mark
> I don't know how to handle it, but I can follow your opinion

I think we can use 2 patterns ?

pattern1)
	post "OF graph new feature" patch and "ALSA SoC use it" patch

	1. OF graph new feature 1 patch
	2. ALSA SoC use feature 1 patch
	3. OF graph new feature 2 patch
	4. ALSA SoC use feature 2 patch
	5. OF graph new feature 3 patch
	6. ALSA SoC use feature 3 patch
	...

	It is easy to review, but difficult on maintainer ?

pattern2)
	post "OF graph new feature" patch-set and "ALSA SoC use it" patch-set

	1. OF graph new feature 1 patch
	2. OF graph new feature 2 patch
	3. OF graph new feature 3 patch
	4. ALSA SoC use feature 1 patch
	5. ALSA SoC use feature 2 patch
	6. ALSA SoC use feature 3 patch
	...

	It is easy on maintainer, difficult to review ?

Actually, this patch-set is 1, 2, 3 part of pattern2).
I can post all patch-set in next time if we use pattern2) case.

Or I can post as pattern1), and maintainer will pickup as
pattern2) order ?

> > In general, all these helpers look okay if you have a user for them.
> 
> Thanks.
> As I explained above, it is based on 1) part, but it will takes more
> long term.
> 

Re: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Kuninori Morimoto]

Hi Rob, Mark, again

> Yes, as you pointed, sound side (= ALSA SoC) will use generic driver
> for sound card which needs to know its total port number.
> Then, these patches are needed.
> 
> I posted OF graph part only this time, but of course I have total full-set
> in my local environment.
> But these are ...
>  1) cleanup current generic sound driver (= almost 30 patch)
>  2) OF graph new feature (= this patch-set) (= almost 10 patch)
>  3) OF graph base generic sound driver (= almost 30 patch)
>  - ...
> 
> I'm posting 1) part to ALSA SoC ML, 2) part to this ML.
> 1) will take more long term >> Mark ??
> If you want to see this patch-set together with use case, then 3) is needed.
> If so, I will merge 2) and 3), and post these to this ML and ALSA SoC ML.
> 
> Is it OK for you ? >> Rob, Mark
> I don't know how to handle it, but I can follow your opinion

I think we can use 2 patterns ?

pattern1)
	post "OF graph new feature" patch and "ALSA SoC use it" patch

	1. OF graph new feature 1 patch
	2. ALSA SoC use feature 1 patch
	3. OF graph new feature 2 patch
	4. ALSA SoC use feature 2 patch
	5. OF graph new feature 3 patch
	6. ALSA SoC use feature 3 patch
	...

	It is easy to review, but difficult on maintainer ?

pattern2)
	post "OF graph new feature" patch-set and "ALSA SoC use it" patch-set

	1. OF graph new feature 1 patch
	2. OF graph new feature 2 patch
	3. OF graph new feature 3 patch
	4. ALSA SoC use feature 1 patch
	5. ALSA SoC use feature 2 patch
	6. ALSA SoC use feature 3 patch
	...

	It is easy on maintainer, difficult to review ?

Actually, this patch-set is 1, 2, 3 part of pattern2).
I can post all patch-set in next time if we use pattern2) case.

Or I can post as pattern1), and maintainer will pickup as
pattern2) order ?

> > In general, all these helpers look okay if you have a user for them.
> 
> Thanks.
> As I explained above, it is based on 1) part, but it will takes more
> long term.
> 

Re: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Rob Herring]

On Tue, Jul 5, 2016 at 1:24 AM, Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:
>
> Hi Rob, Mark, again
>
>> Yes, as you pointed, sound side (= ALSA SoC) will use generic driver
>> for sound card which needs to know its total port number.
>> Then, these patches are needed.
>>
>> I posted OF graph part only this time, but of course I have total full-set
>> in my local environment.
>> But these are ...
>>  1) cleanup current generic sound driver (= almost 30 patch)
>>  2) OF graph new feature (= this patch-set) (= almost 10 patch)
>>  3) OF graph base generic sound driver (= almost 30 patch)
>>  - ...
>>
>> I'm posting 1) part to ALSA SoC ML, 2) part to this ML.
>> 1) will take more long term >> Mark ??
>> If you want to see this patch-set together with use case, then 3) is needed.
>> If so, I will merge 2) and 3), and post these to this ML and ALSA SoC ML.
>>
>> Is it OK for you ? >> Rob, Mark
>> I don't know how to handle it, but I can follow your opinion
>
> I think we can use 2 patterns ?
>
> pattern1)
>         post "OF graph new feature" patch and "ALSA SoC use it" patch
>
>         1. OF graph new feature 1 patch
>         2. ALSA SoC use feature 1 patch
>         3. OF graph new feature 2 patch
>         4. ALSA SoC use feature 2 patch
>         5. OF graph new feature 3 patch
>         6. ALSA SoC use feature 3 patch
>         ...
>
>         It is easy to review, but difficult on maintainer ?
>
> pattern2)
>         post "OF graph new feature" patch-set and "ALSA SoC use it" patch-set
>
>         1. OF graph new feature 1 patch
>         2. OF graph new feature 2 patch
>         3. OF graph new feature 3 patch
>         4. ALSA SoC use feature 1 patch
>         5. ALSA SoC use feature 2 patch
>         6. ALSA SoC use feature 3 patch
>         ...
>
>         It is easy on maintainer, difficult to review ?
>
> Actually, this patch-set is 1, 2, 3 part of pattern2).
> I can post all patch-set in next time if we use pattern2) case.
>
> Or I can post as pattern1), and maintainer will pickup as
> pattern2) order ?
>
>> > In general, all these helpers look okay if you have a user for them.
>>
>> Thanks.
>> As I explained above, it is based on 1) part, but it will takes more
>> long term.
>>

Re: [PATCH v2 0/7] of_graph: prepare for ALSA graph support

[Rob Herring]

On Mon, Jul 4, 2016 at 6:41 PM, Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> wrote:
>
> Hi Rob, Mark
>
> Thank you for your feedback
>
>> I need to see how you want to use this. I'm not completely convinced
>> this is necessary as the port number should be meaningful. For example,
>> port 0 is video and port 1 is audio. This information is specific to the
>> local parent node which could be problematic if you have generic code
>> parsing the local node. However, if you know which local port is audio,
>> then you know the remote endpoint's port is also the audio port.
>
> Yes, as you pointed, sound side (= ALSA SoC) will use generic driver
> for sound card which needs to know its total port number.
> Then, these patches are needed.

But the sound card node will have ports

> I posted OF graph part only this time, but of course I have total full-set
> in my local environment.
> But these are ...
>  1) cleanup current generic sound driver (= almost 30 patch)
>  2) OF graph new feature (= this patch-set) (= almost 10 patch)
>  3) OF graph base generic sound driver (= almost 30 patch)
>  - ...
>
> I'm posting 1) part to ALSA SoC ML, 2) part to this ML.
> 1) will take more long term >> Mark ??
> If you want to see this patch-set together with use case, then 3) is needed.
> If so, I will merge 2) and 3), and post these to this ML and ALSA SoC ML.
>
> Is it OK for you ? >> Rob, Mark

Fine by me.

> I don't know how to handle it, but I can follow your opinion
>
>> In general, all these helpers look okay if you have a user for them.
>
> Thanks.
> As I explained above, it is based on 1) part, but it will takes more
> long term.
>