* [PATCH v5 07/14] of_graph: add of_graph_get_endpoint_count()
From: Kuninori Morimoto @ 2016-11-28 2:46 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87k2bowckx.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
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>
---
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 705ea15..76d2819 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2596,3 +2596,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 7f735f8..826752f 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,
@@ -87,6 +89,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
^ permalink raw reply related
* [PATCH v5 06/14] of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()
From: Kuninori Morimoto @ 2016-11-28 2:46 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87k2bowckx.wl%kuninori.morimoto.gx@renesas.com>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
OF graph is used mainly from V4L2, but ALSA needs to use it. It already
has for_each_endpoint_of_node() which is for-loop for each endpoint.
But, ALSA needs for-loop for each port[s], and for-loop for each
endpoint of inside 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 | 64 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of_graph.h | 29 ++++++++++++++++++++++
2 files changed, 93 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8c5080b..705ea15 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2352,6 +2352,70 @@ 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);
+}
+EXPORT_SYMBOL(of_graph_get_next_endpoint_in_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 699835a..7f735f8 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,11 @@ 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(
@@ -83,6 +98,20 @@ static inline struct device_node *of_graph_get_top_port(struct device *dev)
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
^ permalink raw reply related
* [PATCH v5 05/14] of_graph: add of_graph_get_top_port()
From: Kuninori Morimoto @ 2016-11-28 2:46 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87k2bowckx.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
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-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
drivers/of/base.c | 24 ++++++++++++++++++++++++
include/linux/of_graph.h | 7 +++++++
2 files changed, 31 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index f94884d..8c5080b 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2328,6 +2328,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..699835a 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(
@@ -76,6 +78,11 @@ static inline struct device_node *of_graph_get_port_by_id(
return NULL;
}
+static inline struct device_node *of_graph_get_top_port(struct device *dev)
+{
+ 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
^ permalink raw reply related
* [PATCH v5 04/14] of_graph: add of_graph_get_port_parent()
From: Kuninori Morimoto @ 2016-11-28 2:45 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87k2bowckx.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
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-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
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 d6237ba..f94884d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2437,6 +2437,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
*
@@ -2447,18 +2468,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
--
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
^ permalink raw reply related
* [PATCH v5 03/14] of_graph: add of_graph_port_type_is()
From: Kuninori Morimoto @ 2016-11-28 2:45 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87k2bowckx.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
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-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
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 fed109d..d6237ba 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2480,3 +2480,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
--
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
^ permalink raw reply related
* [PATCH v5 02/14] of_graph: add of_graph_get_remote_endpoint()
From: Kuninori Morimoto @ 2016-11-28 2:45 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87k2bowckx.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
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-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
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 a0bccb5..fed109d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2423,6 +2423,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
*
@@ -2436,7 +2450,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--) {
@@ -2460,7 +2474,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
--
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
^ permalink raw reply related
* [PATCH v5 01/14] Documentation: of: add type property
From: Kuninori Morimoto @ 2016-11-28 2:44 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87k2bowckx.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
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-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
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
--
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
^ permalink raw reply related
* [PATCH v5 00/14] ASoC: add OF graph base simple-card
From: Kuninori Morimoto @ 2016-11-28 2:42 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
Hi Rob, Mark
These are v5 of OF graph base simple-card patch-set.
I removed new "type" property on v4 patch-set, but I noticed that
it is necessary for ALSA SoC binding purpose. Thus, this v5 has
it again.
For example HDMI case, its DT will has video and sound ports.
This DT will be used from HDMI Video driver and HDMI sound driver.
HDMI video side can handle all somehow, because it is fully under its control.
HDMI sound side will just references it. But it can't know total
Video/Sound ports number which is necessary for ALSA SoC side.
For example, if HDMI video had 4 ports, sound had 2 ports,
this case, HDMI sound ports will be port@4, port@5.
Here, ALSA SoC side needs to know total 2 sound port,
and, it should be handled as 1st / 2nd port.
It is impossible without "type" property.
1) - 7) : OF graph new feature
8) - 14) : OF graph base simple-card
Kuninori Morimoto (14):
1) Documentation: of: add type property
2) of_graph: add of_graph_get_remote_endpoint()
3) of_graph: add of_graph_port_type_is()
4) of_graph: add of_graph_get_port_parent()
5) of_graph: add of_graph_get_top_port()
6) of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()
7) of_graph: add of_graph_get_endpoint_count()
8) ASoC: simple-card-utils: adjust for graph on asoc_simple_card_parse_card_name
9) ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()
10) ASoC: simple-card-utils: add asoc_simple_card_try_to_probe_graph_card()
11) ASoC: add simple-graph-card document
12) ASoC: add simple-graph-card support
13) ASoC: add simple-graph-scu-card document
14) ASoC: add simple-graph-scu-card support
Documentation/devicetree/bindings/graph.txt | 21 +
.../bindings/sound/simple-graph-card.txt | 67 +++
.../bindings/sound/simple-graph-scu-card.txt | 69 +++
drivers/of/base.c | 166 +++++++-
include/linux/of_graph.h | 67 +++
include/sound/simple_card_utils.h | 13 +
sound/soc/generic/Kconfig | 15 +
sound/soc/generic/Makefile | 4 +
sound/soc/generic/simple-card-utils.c | 98 ++++-
sound/soc/generic/simple-card.c | 2 +-
sound/soc/generic/simple-graph-card.c | 461 +++++++++++++++++++++
sound/soc/generic/simple-graph-scu-card.c | 441 ++++++++++++++++++++
sound/soc/generic/simple-scu-card.c | 2 +-
13 files changed, 1413 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/simple-graph-card.txt
create mode 100644 Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt
create mode 100644 sound/soc/generic/simple-graph-card.c
create mode 100644 sound/soc/generic/simple-graph-scu-card.c
--
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
^ permalink raw reply
* Re: [PATCH v9 3/4] dtc: Plugin and fixup support
From: David Gibson @ 2016-11-28 2:32 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Jon Loeliger, Grant Likely, Frank Rowand, Rob Herring, Jan Luebbe,
Sascha Hauer, Phil Elwell, Simon Glass, Maxime Ripard,
Thomas Petazzoni, Boris Brezillon, Antoine Tenart, Stephen Boyd,
Devicetree Compiler, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AB914E20-1F16-441B-9D7C-5A7298E963A6-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 17171 bytes --]
On Fri, Nov 25, 2016 at 02:44:39PM +0200, Pantelis Antoniou wrote:
> Hi David,
>
> > On Nov 25, 2016, at 13:26 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> >
> > On Fri, Nov 25, 2016 at 12:55:25PM +0200, Pantelis Antoniou wrote:
> >> Hi David,
> >>
> >>> On Nov 25, 2016, at 06:11 , David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> >>>
> >>> On Thu, Nov 24, 2016 at 02:31:32PM +0200, Pantelis Antoniou wrote:
> >>>> This patch enable the generation of symbols & local fixup information
> >>>> for trees compiled with the -@ (--symbols) option.
> >>>>
> >>>> Using this patch labels in the tree and their users emit information
> >>>> in __symbols__ and __local_fixups__ nodes.
> >>>>
> >>>> The __fixups__ node make possible the dynamic resolution of phandle
> >>>> references which are present in the plugin tree but lie in the
> >>>> tree that are applying the overlay against.
> >>>>
> >>>> While there is a new magic number for dynamic device tree/overlays blobs
> >>>> it is by default disabled. This is in order to give time for DT blob
> >>>> methods to be updated.
> >>>>
> >>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> >>>> Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >>>> Signed-off-by: Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >>>> ---
> >>>> Documentation/manual.txt | 25 +++++-
> >>>> checks.c | 8 +-
> >>>> dtc-lexer.l | 5 ++
> >>>> dtc-parser.y | 49 +++++++++--
> >>>> dtc.c | 39 +++++++-
> >>>> dtc.h | 20 ++++-
> >>>> fdtdump.c | 2 +-
> >>>> flattree.c | 17 ++--
> >>>> fstree.c | 2 +-
> >>>> libfdt/fdt.c | 2 +-
> >>>> libfdt/fdt.h | 3 +-
> >>>> livetree.c | 225 ++++++++++++++++++++++++++++++++++++++++++++++-
> >>>> tests/mangle-layout.c | 7 +-
> >>>> treesource.c | 7 +-
> >>>> 14 files changed, 380 insertions(+), 31 deletions(-)
> >>>>
> >>>> diff --git a/Documentation/manual.txt b/Documentation/manual.txt
> >>>> index 398de32..65fbf09 100644
> >>>> --- a/Documentation/manual.txt
> >>>> +++ b/Documentation/manual.txt
> >>>> @@ -119,6 +119,24 @@ Options:
> >>>> Make space for <number> reserve map entries
> >>>> Relevant for dtb and asm output only.
> >>>>
> >>>> + -@
> >>>> + Generates a __symbols__ node at the root node of the resulting blob
> >>>> + for any node labels used, and for any local references using phandles
> >>>> + it also generates a __local_fixups__ node that tracks them.
> >>>> +
> >>>> + When using the /plugin/ tag all unresolved label references to
> >>>> + be tracked in the __fixups__ node, making dynamic resolution possible.
> >>>> +
> >>>> + -A
> >>>> + Generate automatically aliases for all node labels. This is similar to
> >>>> + the -@ option (the __symbols__ node contain identical information) but
> >>>> + the semantics are slightly different since no phandles are automatically
> >>>> + generated for labeled nodes.
> >>>> +
> >>>> + -M
> >>>> + Generate blobs with the new FDT magic number. By default blobs with the
> >>>> + standard FDT magic number are generated.
> >>>
> >>> First, this description is incomplete since -M *only* affects the
> >>> magic number for /plugin/ input, not in other cases. Second, the
> >>> default is the wrong way around. If we make old-style the default,
> >>> then new-style will never be used, which defeats the purpose.
> >>
> >> Then we’ll break user-space that has this assumption (i.e. that the magic is the same).
> >> I can certainly do it the other way around.
> >
> > Which userspace in particular?
> >
>
> Kernel unflatteners in various OSes/bootloaders? All those would have to be updated since
> they don’t grok the new magic number.
Those will certainly need dtbs with the old magic number as input, but
I don't see how that affects the dtc default. Using the option
explicitly if you're targetting a bootloader that hasn't been updated
seems reasonable.
> >>>> +
> >>>> -S <bytes>
> >>>> Ensure the blob at least <bytes> long, adding additional
> >>>> space if needed.
> >>>> @@ -146,13 +164,18 @@ Additionally, dtc performs various sanity checks on the tree.
> >>>> Here is a very rough overview of the layout of a DTS source file:
> >>>>
> >>>>
> >>>> - sourcefile: list_of_memreserve devicetree
> >>>> + sourcefile: versioninfo plugindecl list_of_memreserve devicetree
> >>>>
> >>>> memreserve: label 'memreserve' ADDR ADDR ';'
> >>>> | label 'memreserve' ADDR '-' ADDR ';'
> >>>>
> >>>> devicetree: '/' nodedef
> >>>>
> >>>> + versioninfo: '/' 'dts-v1' '/' ';'
> >>>> +
> >>>> + plugindecl: '/' 'plugin' '/' ';'
> >>>> + | /* empty */
> >>>> +
> >>>> nodedef: '{' list_of_property list_of_subnode '}' ';'
> >>>>
> >>>> property: label PROPNAME '=' propdata ';'
> >>>> diff --git a/checks.c b/checks.c
> >>>> index 609975a..bc03d42 100644
> >>>> --- a/checks.c
> >>>> +++ b/checks.c
> >>>> @@ -486,8 +486,12 @@ static void fixup_phandle_references(struct check *c, struct boot_info *bi,
> >>>>
> >>>> refnode = get_node_by_ref(dt, m->ref);
> >>>> if (! refnode) {
> >>>> - FAIL(c, "Reference to non-existent node or label \"%s\"\n",
> >>>> - m->ref);
> >>>> + if (!(bi->versionflags & VF_PLUGIN))
> >>>> + FAIL(c, "Reference to non-existent node or "
> >>>> + "label \"%s\"\n", m->ref);
> >>>> + else /* mark the entry as unresolved */
> >>>> + *((cell_t *)(prop->val.val + m->offset)) =
> >>>> + cpu_to_fdt32(0xffffffff);
> >>>> continue;
> >>>> }
> >>>>
> >>>> diff --git a/dtc-lexer.l b/dtc-lexer.l
> >>>> index 790fbf6..40bbc87 100644
> >>>> --- a/dtc-lexer.l
> >>>> +++ b/dtc-lexer.l
> >>>> @@ -121,6 +121,11 @@ static void lexical_error(const char *fmt, ...);
> >>>> return DT_V1;
> >>>> }
> >>>>
> >>>> +<*>"/plugin/" {
> >>>> + DPRINT("Keyword: /plugin/\n");
> >>>> + return DT_PLUGIN;
> >>>> + }
> >>>> +
> >>>> <*>"/memreserve/" {
> >>>> DPRINT("Keyword: /memreserve/\n");
> >>>> BEGIN_DEFAULT();
> >>>> diff --git a/dtc-parser.y b/dtc-parser.y
> >>>> index 14aaf2e..4afc592 100644
> >>>> --- a/dtc-parser.y
> >>>> +++ b/dtc-parser.y
> >>>> @@ -19,6 +19,7 @@
> >>>> */
> >>>> %{
> >>>> #include <stdio.h>
> >>>> +#include <inttypes.h>
> >>>>
> >>>> #include "dtc.h"
> >>>> #include "srcpos.h"
> >>>> @@ -33,6 +34,9 @@ extern void yyerror(char const *s);
> >>>>
> >>>> extern struct boot_info *the_boot_info;
> >>>> extern bool treesource_error;
> >>>> +
> >>>> +/* temporary while the tree is not built */
> >>>> +static unsigned int the_versionflags;
> >>>
> >>> Hrm. Using a global during parsing is pretty dangerous - it makes
> >>> assumptions about the order in which bison will execute semantic
> >>> actions that may not always be correct.
> >>>
> >>> It'll probably work in practice, so I *might* be convinced it's
> >>> adequate for a first cut. I'm a bit reluctant though, since I suspect
> >>> once merged it will become entrenched.
> >>>
> >>
> >> We use bison, globals are the way of life. It’s not going to be used
> >> anywhere else, it’s static in the parser file.
> >
> > Using globals to communicate the final result is inevitable (well, not
> > without using the whole different re-entrant interface stuff). That
> > just assumes that the start symbol's semantic action is executed
> > before the parser competes, which is guaranteed.
> >
> > This is a different matter - using a global to communicate between
> > different parts of the parser. More specifically different parts of
> > the parser that are in different arms of the parse tree. That makes
> > assumptions about the relative order of semantic actions which are
> > *not* guaranteed. In theory the parser could generate the entire
> > parse tree and semantic action dependency graph, then execute them in
> > an arbitrary order (well, it would have to be a topologically sorted
> > order, but that won't help).
> >
>
> I’ve given it a little bit more thought and it’s easily fixed by using
> inherited attributes which is safe to do and avoid the global all together.
Hmm.. we'll see.
> >> We could allocate the boot_info earlier (when the v1tag is detected) but
> >> that would be quite a big change for something as trivial.
> >
> > That wouldn't help. You still wouldn't have a guarantee on the order
> > between setting the version flags and using the version flags.
> >
> >>> The correct way to handle this, IMO, is not to ever attempt to apply
> >>> overlays during the parse. Basically, we'd change the overall
> >>> structure so that the output from the parser is not a single tree, but
> >>> a list of overlays / fragments. Then, once the parse is complete, so
> >>> versioninfo (which could now become a member of bootinfo) is well
> >>> defined, we either apply the fragments in place (base tree) or encode
> >>> them into the overlay structure (plugin mode).
> >>>
> >>> See https://github.com/dgibson/dtc/tree/overlay for some incomplete
> >>> work I did in this direction.
> >>>
> >>
> >> This tree is pretty stale; last commit was back in march.
> >
> > Yes, it was a while since I worked on it. It rebased clean, though.
> >
> >> I thing there’s a wrong assumption here. The purpose of this patch is not
> >> to apply overlays during compile time, is to generate a blob that can be
> >> applied at runtime by another piece of software.
> >
> > No, I realise what you're doing. But the input is in the form of a
> > batch of overlays, regardless. You then have two modes of operation:
> > for base trees you resolve those overlays during the compile, for
> > plugins you assemble those overlays into a blob which can be applied
> > later.
> >
> > Because it wasn't designed with runtime overlays in mind, the current
> > code handles the resolution of those overlays during the parse. Your
> > patch extends that by rather than resolving them, just putting them
> > together with metadata into the dtbo.
> >
> > I'm saying that resolution or assembly should be moved out of the
> > parser. Instead, the parser output would be an (ordered) list of
> > overlay fragments. In the main program the two modes of operation
> > become explicit: for base trees we resolve the overlays into a single
> > tree, for plugins we collate the pieces into the dtbo format.
>
> The case for building an overlay is only for the syntactic sugar version.
I don't understand what you're saying here.
> This is not the common use case at all. I could easily remove it and then
> there would be no overlays built at all in the parser.
Remove what exactly? You mean the case with &ref { } when you're not
building a dtbo? I'm not sure that is so uncommon - dts include files
are basically useless without it.
> In fact the extra fixup nodes are generated now after the parse stage,
> after the check stage and before the sort stage.
Yes.. I'm not talking about the fixup nodes, I'm talking about the
assembly of the tree fragments.
> Perhaps it should be separated out so that we don’t get sidetracked?
What exactly should be separated out from what?
> >>> In addition to not making unsafe assumptions about parser operation, I
> >>> think this will also allow for better error reporting. It also moves
> >>> more code into plain-old-C instead of potentially hard to follow bison
> >>> code fragments.
> >>>
> >>
> >> We don’t try to apply overlays during parse, and especially in the parse code.
> >
> > The existing code does this, and you don't change it. Furthermore you
> > absolutely do do the assembly of the fragments within the parser -
> > that's exactly what add_orphan_node() called directly from semantic
> > actions does. To verify this, all you need to do is look at the
> > parser output: the boot_info structure has just a single tree, not a
> > list of overlays.
> >
>
> Only for the un-common case.
>
> >> The global is used only for the syntactic sugar method of turning a &ref { };
> >> node into an overlay.
> >
> > I'm saying that treating that as mere syntactic sugar is a fundamental
> > error in design. We could get away with it when the &ref {} stuff was
> > always resolved immediately. Now that that resolution can be delayed
> > until later, it gets worse. We should move that resolution outside of
> > the parser.
> >
>
> The &ref { } stuff is sidetracking us. This is not the core issue.
You haven't convinced me of that.
> In fact out in the community there are not a lot of cases where it
> is used.
I thought it was the standard way to construct a dtbo.
But in any case, regardless of how common it is, it is currently
introducing an order dependency between different parts of the parse
tree that hasn't been adequately handled (in v9, I'll reasses when I
review the v10 patches).
> >>>> diff --git a/treesource.c b/treesource.c
> >>>> index a55d1d1..75e920d 100644
> >>>> --- a/treesource.c
> >>>> +++ b/treesource.c
> >>>> @@ -267,7 +267,12 @@ void dt_to_source(FILE *f, struct boot_info *bi)
> >>>> {
> >>>> struct reserve_info *re;
> >>>>
> >>>> - fprintf(f, "/dts-v1/;\n\n");
> >>>> + fprintf(f, "/dts-v1/");
> >>>> +
> >>>> + if (bi->versionflags & VF_PLUGIN)
> >>>> + fprintf(f, " /plugin/");
> >>>> +
> >>>> + fprintf(f, ";\n\n");
> >>>
> >>> I'm not sure this really makes sense. The /plugin/ tag triggers the
> >>> fixup construction and encoding of overlay fragments. But in an
> >>> incoming dtb, that processing has already been done once, doing it
> >>> again would not make sense. So I think the output should not have the
> >>> /plugin/ tag, even if the input did.
> >>>
> >>> Unless, of course, you parsed the input into an explicit list of
> >>> overlays, then output it here again as a list of overlays, not the
> >>> encoded fragments. i.e. if this was the original tree:
> >>>
> >>> /dts-v1/ /plugin/;
> >>>
> >>> &somwhere {
> >>> name = "value";
> >>> };
> >>>
> >>> then legitimately the output of -I dts -O dts could be either:
> >>>
> >>> /dts-v1/ /plugin/;
> >>>
> >>> &somwhere {
> >>> name = "value";
> >>> };
> >>>
> >>> OR
> >>>
> >>> /dts-v1/;
> >>>
> >>> / {
> >>> fragment@0 {
> >>> target = <0xffffffff>;
> >>> __overlay__{
> >>> name = "value";
> >>> };
> >>> };
> >>> __fixups__ {
> >>> somewhere = "/fragment@0:target:0";
> >>> };
> >>> };
> >>>
> >>> But it doesn't make sense to combine the two: the second structure
> >>> with the "/plugin/" tag.
> >>>
> >>
> >>> Another advantage of moving the overlay application out of the parser
> >>> is you can sanely produce either output, both of which could be useful
> >>> in the right circumstances. You can potentially even produce the
> >>> first output (or something close) from dtb input, with correct parsing
> >>> of the overlay structure on dtb input.
> >>>
> >>
> >> Yes, this makes sense. For now I’ll remove the plugin tag, but if the blob
> >> was compiled with -@ you could conceivably reverse back to a form that contains
> >> labels and phandle references correctly.
> >>
> >> But this is quite complicated to undertake in this patch series.
> >>
> >> To re-iterate though there is no overlay application here :)
> >
> > Well, I think we've both been a bit sloppy with terminology - does
> > "overlay" refer to a dtbo file, or to one of the &ref { ... }
> > fragments in the source, or to both.
> >
> > But whatever the right term is for the &ref { .. } fragments in the
> > source they absolutely *are* applied during compile for the base tree
> > case. And while they're not resolved fully, they are encoded into
> > part of a larger tree structure for the plugin case.
> >
> > The confusion will be reduced if we make these
> > overlays/fragments/whatever first class objects in the "live tree"
> > phase of the compile, and move the resolution and/or assembly of them
> > a stage that's separate from the parse. In addition, it opens the way
> > for decompiling a dtbo more naturally, though as you say that's a
> > moderate amount of extra work.
>
> How about we get the non &ref { } case sorted out and we can talk about
> the syntactic sugar version done?
Uh.. sure. I'm not really clear on what you mean by that, but I guess
I'll look and see.
>
> v10 has been sent out.
>
>
> Regards
>
> — Pantelis
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/7] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: David Miller @ 2016-11-28 1:33 UTC (permalink / raw)
To: martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
khilman-rdvid1DuHRBWk0Htik3J/w, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
carlo-KA+7E9HrN00dnm+yROfE0A, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
From: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Date: Fri, 25 Nov 2016 14:01:49 +0100
> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
> cycle TX clock delay. This seems to work fine for many boards (for
> example Odroid-C2 or Amlogic's reference boards) but there are some
> others where TX traffic is simply broken.
> There are probably multiple reasons why it's working on some boards
> while it's broken on others:
> - some of Amlogic's reference boards are using a Micrel PHY
> - hardware circuit design
> - maybe more...
The ARM arch file changes do not apply cleanly to net-next, you probably
want to merge them via the ARM tree instead of mine, and respin this series
to be without the .dts file changes.
--
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
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: André Przywara @ 2016-11-28 0:29 UTC (permalink / raw)
To: Icenowy Zheng, Jonathan Corbet, Maxime Ripard, Chen-Yu Tsai,
Mark Rutland, Russell King, Hans de Goede
Cc: devicetree@vger.kernel.org, Vishnu Patekar, Arnd Bergmann,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <5373671480239408@web31m.yandex.ru>
On 27/11/16 09:36, Icenowy Zheng wrote:
Hi,
> 22.11.2016, 00:26, "Icenowy Zheng" <icenowy@aosc.xyz>:
>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
>>
>> Add a device tree file for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ---
>> Changes since v2:
>> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
>> - removed uart3, which is not accessible on Orange Pi Zero.
>> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
>> sun8i-h3.dtsi.
>> - Removed allwinner,sun8i-h3 compatible.
>>
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++++++++
>> 2 files changed, 138 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 802a10d..51a1dd7 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>> sun8i-a33-sinlinx-sina33.dtb \
>> sun8i-a83t-allwinner-h8homlet-v2.dtb \
>> sun8i-a83t-cubietruck-plus.dtb \
>> + sun8i-h2plus-orangepi-zero.dtb \
>> sun8i-h3-bananapi-m2-plus.dtb \
>> sun8i-h3-nanopi-neo.dtb \
>> sun8i-h3-orangepi-2.dtb \
>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> new file mode 100644
>> index 0000000..b428e47
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> @@ -0,0 +1,137 @@
>> +/*
>> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
>> + *
>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>> + * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun8i-h3.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> + model = "Xunlong Orange Pi Zero";
>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
>> +
>> + pwr_led {
>> + label = "orangepi:green:pwr";
>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + status_led {
>> + label = "orangepi:red:status";
>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>> + cd-inverted;
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&pio {
>> + leds_opi0: led_pins@0 {
>> + pins = "PA17";
>> + function = "gpio_out";
>> + };
>> +};
>> +
>> +&r_pio {
>> + leds_r_opi0: led_pins@0 {
>> + pins = "PL10";
>> + function = "gpio_out";
>> + };
>> +};
>> +
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_pins_a>;
>> + status = "okay";
>> +};
>> +
>> +&uart1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart1_pins>;
>> + status = "disabled";
>> +};
>> +
>> +&uart2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart2_pins>;
>> + status = "disabled";
>> +};
>> +
>> +&usbphy {
>> + /* USB VBUS is always on */
>> + status = "okay";
>> +};
>
> Something more interesting happened.
>
> Xunlong made a add-on board for Orange Pi Zero, which exposes the two USB Controllers exported at expansion bus as USB Type-A connectors.
>
> Also it exposes a analog A/V jack and a microphone.
>
> Should I enable {e,o}hci{2.3} in the device tree?
Actually we should do this regardless of this extension board. The USB
pins are not multiplexed and are exposed on user accessible pins (just
not soldered, but that's a detail), so I think they qualify for DT
enablement. And even if a user can't use them, it doesn't hurt to have
them (since they are not multiplexed).
Cheers,
Andre.
^ permalink raw reply
* Re: [PATCH 0/5] Meson GXL and GXM USB support
From: Martin Blumenstingl @ 2016-11-27 22:42 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, kishon-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
narmstrong-rdvid1DuHRBWk0Htik3J/w, Martin Blumenstingl
In-Reply-To: <20161126145635.24488-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Hello Kishon,
On Sat, Nov 26, 2016 at 3:56 PM, Martin Blumenstingl
<martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> USB support on GXL and GXM differs a lot from Meson8b and GXBB:
> The most obvious change is that GXL and GXM now have one dwc3
> controller and one dwc2 controller (instead of two dwc2 controllers).
> With that there are also new USB PHYs.
>
> Due to lack of hardware I was only able to test this on a board with
> GXM, but as far as I understand the hardware my preparations should be
> correct (so it should also work on GXL).
>
> dwc2 will probably stay unused on most GXM devices since it's limited
> to device mode via some dwc2 hardware configuration register.
>
> dwc3 is probably used on all devices, even if there is more than just
> one USB port. dwc3 has a built-in USB2 hub - on GXL this hub has two
> ports enabled, while on GXM there are three ports enabled (see below
> for lsusb output). There are no USB3 ports enabled in the dwc3 hardware
> configuration, meaning that the SoC is limited to high-speed mode.
> On my GXM device the dwc3 hardware configuration forces it into "host
> only" mode.
>
> The SoCs contain two PHY blocks: one USB3 PHY and up to four USB2 PHYs
> (on GXM there are only three enabled, but the registers should support
> up to four).
> The USB3 PHY also handles the OTG interrupts, but since dwc3's hardware
> configuration enforces "host only" mode I was not able to test this. It
> simply takes care of an interrupt and then notifies all related PHYs
> about the new mode.
> The USB2 PHY block is a bit different: I created one PHY driver which
> spans all "PHY ports" because the handling is a bit tricky. It turns
> out that for each available USB port in dwc3's hub the corresponding
> PHY must be enabled (even if there is no physical port - in my case
> port 3 is not connected to anything, but disabling the PHY breaks
> ports 1 and 2 as well).
> I decided not not pass the USB2 PHYs directly to dwc3 due to three
> reasons: 1. the USB3 PHY (which holds a reference to all relevant
> USB2 PHY ports) controls the mode of the USB2 PHY ports (since both
> are used with the same controller and thus it makes sense to keep the
> mode consistent across all ports) 2. the dwc3 driver does not support
> passing multiple USB2 PHYs (only one USB2 and one USB3 PHY can be
> passed to it) 3. it is similar to how the vendor reference driver
> manages the PHYs. Please note that this coupling is not a fixed, this
> is all configurable via devicetree (so if the third USB2 PHY has to
> be passed two the dwc2 controller then this is still possible by
> just moving on PHY reference in the .dts).
after not staring at my own code for 24 hours I realized this:
(I went through quite a few iterations before getting these drivers to work)
I'm basically re-modelling an "USB PHY hub" with my USB3 PHY driver
(there's one "upstream" PHY interface which is passed to dwc3 and
multiple downstream PHYs, each for one port on dwc3's internal hub).
With this approach I could split each of the the USB2s into separate
nodes again (instead of one devicetree node with #phy-cells = <1>) as
the USB3 PHY is taking care of that special "we have to enable all
ports or no port will be usable".
We could go even one step further: why implement this in the Meson GXL
specific PHY driver - why not implement a generic "phy-hub" driver
(which would be valid whenever the PHY controller has to manage
multiple PHYs at once, but wants to keep them all in a consistent
state).
The devicetree could look like this:
usb2_phy_hub: phy@0 {
compatible = "phy-hub";
phys = <&other_phy1>, <&other_phy 2>;
};
&dwc3 {
phys = <&usb2_phy_hub>, <&usb3_phy0>;
phy-names = "usb2-phy", "usb3-phy";
};
The generic phy-hub driver would then implement all phy_ops callbacks
and pass then to each of it's downstream PHYs.
That's just what came into my head - please let me know what you think
of this or share your ideas on how to approach this!
> The coupling of the USB2 and USB3 PHYs is the reason why I sent the
> two drivers in one patch, even though they are handling different IP
> blocks (different registers, etc.).
>
> Unfortunately there are no datasheets available for any of these PHYs.
> Both drivers were written by reading the reference drivers provided by
> Amlogic and analyzing the registers on the kernel that was shipped with
> my board.
>
> As a last note: the dwc3 driver currently only explicitly enables the
> first USB port "DWC3_GUSB2PHYCFG(0)" in the internal hub. The hardware
> seems to enable the other two (DWC3_GUSB2PHYCFG(1) and
> DWC3_GUSB2PHYCFG(2)) automatically. I will ask the dwc3 maintainers if
> changes to dwc3 are desired any how these should look like, but for now
> it's working fine even without changes there.
>
> lsusb output on GXM for the dwc3 hub:
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> ...
> Hub Port Status:
> Port 1: 0000.0100 power
> Port 2: 0000.0100 power
> Port 3: 0000.0100 power
>
> NOTE: The devicetree changes depend on my previous series:
> "[PATCH 0/2] minor GXL and GXM improvements" - see [0]
>
> NOTE2: This series depends on an upstream dwc3/xhci-plat DMA fix
> (special thanks to Arnd Bergmann and Sriram Dash for fixing that):
> "[PATCH v5 0/6] inherit dma configuration from parent dev" - see [1]
>
> I have a tree with all dependencies applied available at [2] if
> someone wants a quick way to test this (I don't take any responsibility
> if anything explodes though).
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001665.html
> [1] http://marc.info/?l=linux-usb&m=147938307209685&w=2
> [2] https://github.com/xdarklight/linux/commits/meson-gx-integration-4.10-20161126
>
> Martin Blumenstingl (5):
> Documentation: dt-bindings: Add documentation for Meson GXL USB2/3
> PHYs
> phy: meson: add USB2 and USB3 PHY support for Meson GXL
> arm64: dts: meson-gxl: add USB support
> ARM64: dts: meson-gxm: add GXM specific USB configuration
> ARM64: dts: meson-gx-p23x-q20x: enable USB on P23x and Q20x boards
>
> .../devicetree/bindings/phy/meson-gxl-usb2-phy.txt | 25 ++
> .../devicetree/bindings/phy/meson-gxl-usb3-phy.txt | 27 ++
> .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 12 +
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 49 +++
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 17 +
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 10 +
> drivers/phy/Kconfig | 13 +
> drivers/phy/Makefile | 2 +
> drivers/phy/phy-meson-gxl-usb2.c | 374 ++++++++++++++++++++
> drivers/phy/phy-meson-gxl-usb3.c | 377 +++++++++++++++++++++
> 10 files changed, 906 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
> create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt
> create mode 100644 drivers/phy/phy-meson-gxl-usb2.c
> create mode 100644 drivers/phy/phy-meson-gxl-usb3.c
>
> --
> 2.10.2
>
--
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
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Fix armada-385-turris-omnia stdout-path
From: Uwe Kleine-König @ 2016-11-27 22:30 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Andrew Lunn, Jason Cooper, devicetree-u79uwXL29TY76Z2rM5mHXA,
Tomas Hlavacek, Russell King, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Gregory Clement, Sebastian Hesselbarth,
Bedřicha Košatu, Michal Hrusecki
In-Reply-To: <0f51c7a1-6d52-3e3e-edfe-e7b10917ecab-l3A5Bk7waGM@public.gmane.org>
Hello,
On Sun, Nov 27, 2016 at 11:14:37PM +0100, Andreas Färber wrote:
> Am 27.11.2016 um 22:25 schrieb Uwe Kleine-König:
> > On Sun, Nov 27, 2016 at 08:37:24PM +0100, Andreas Färber wrote:
> >> Specify the baudrate.
> >>
> >> Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
> >> Cc: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> >> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> >
> > You said with plain &uart0 the kernel uses a wrong baud rate? That's
> > strange. For me it works and I think it's the intended behaviour to
> > dermine the baud rate setup by the bootloader and use this.
>
> IIRC the 8250 driver defaults to 9600n8 if unspecified.
>
> Kernel tested: 4.9.0-rc2-next-20161028-00010-g4fb44d9-dirty
>
> Maybe you used some console= argument overriding it?
Yes, you're right.
> > I'd prefer it this way over hard coding the baud rate.
> >
> >> arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> >> index f53cb8b73610..2eff012287d4 100644
> >> --- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> >> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> >> @@ -52,7 +52,7 @@
> >> compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
> >>
> >> chosen {
> >> - stdout-path = &uart0;
> >> + stdout-path = "serial0:115200n8";
> >> };
> >>
> >> memory {
> >
> > This has the downside to depend on the alias. Not sure this is
> > considered modern. An alternative would be:
> >
> > stdout-path = "/soc/internal-regs/serial@12000:115200n8";
>
> Please don't unroll the path I'm trying to abstract elsewhere.
Yeah, specifying the path isn't nice.
> Like I said, the "serialX:115200n8" syntax is what all other Armada 38x
> boards use:
This isn't a reason to not think about better alternatives. An if
something like:
stdout-path = &uart0 + ":115200n8";
would be possible, I'd definitely prefer it over "serial0:115200n8".
> git grep stdout-path -- arch/arm/boot/dts/ | grep armada-38
> arch/arm/boot/dts/armada-385-db-ap.dts: stdout-path = "serial1:115200n8";
> arch/arm/boot/dts/armada-385-linksys.dtsi: stdout-path =
> "serial0:115200n8";
> arch/arm/boot/dts/armada-388-clearfog.dts: stdout-path =
> "serial0:115200n8";
> arch/arm/boot/dts/armada-388-db.dts: stdout-path = "serial0:115200n8";
> arch/arm/boot/dts/armada-388-gp.dts: stdout-path = "serial0:115200n8";
> arch/arm/boot/dts/armada-388-rd.dts: stdout-path = "serial0:115200n8";
>
> The alias is needed to reliably determine the tty device number and is
> set "globally" in armada-38x.dtsi, so why is it a problem to rely on?
AFAIK aliases are seen as (still necessary) evil by the dt people. So if
you can stop making use of them, that would be nice.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Fix armada-385-turris-omnia stdout-path
From: Andreas Färber @ 2016-11-27 22:14 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Andrew Lunn, Jason Cooper, devicetree-u79uwXL29TY76Z2rM5mHXA,
Tomas Hlavacek, Russell King, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Gregory Clement, Sebastian Hesselbarth,
Bedřicha Košatu, Michal Hrusecki
In-Reply-To: <20161127212528.wmqbwciz5ltnfws3-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Am 27.11.2016 um 22:25 schrieb Uwe Kleine-König:
> On Sun, Nov 27, 2016 at 08:37:24PM +0100, Andreas Färber wrote:
>> Specify the baudrate.
>>
>> Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
>> Cc: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
>> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
>
> You said with plain &uart0 the kernel uses a wrong baud rate? That's
> strange. For me it works and I think it's the intended behaviour to
> dermine the baud rate setup by the bootloader and use this.
IIRC the 8250 driver defaults to 9600n8 if unspecified.
Kernel tested: 4.9.0-rc2-next-20161028-00010-g4fb44d9-dirty
Maybe you used some console= argument overriding it?
> I'd prefer it this way over hard coding the baud rate.
>
>> arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> index f53cb8b73610..2eff012287d4 100644
>> --- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> @@ -52,7 +52,7 @@
>> compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
>>
>> chosen {
>> - stdout-path = &uart0;
>> + stdout-path = "serial0:115200n8";
>> };
>>
>> memory {
>
> This has the downside to depend on the alias. Not sure this is
> considered modern. An alternative would be:
>
> stdout-path = "/soc/internal-regs/serial@12000:115200n8";
Please don't unroll the path I'm trying to abstract elsewhere.
Like I said, the "serialX:115200n8" syntax is what all other Armada 38x
boards use:
git grep stdout-path -- arch/arm/boot/dts/ | grep armada-38
arch/arm/boot/dts/armada-385-db-ap.dts: stdout-path = "serial1:115200n8";
arch/arm/boot/dts/armada-385-linksys.dtsi: stdout-path =
"serial0:115200n8";
arch/arm/boot/dts/armada-388-clearfog.dts: stdout-path =
"serial0:115200n8";
arch/arm/boot/dts/armada-388-db.dts: stdout-path = "serial0:115200n8";
arch/arm/boot/dts/armada-388-gp.dts: stdout-path = "serial0:115200n8";
arch/arm/boot/dts/armada-388-rd.dts: stdout-path = "serial0:115200n8";
The alias is needed to reliably determine the tty device number and is
set "globally" in armada-38x.dtsi, so why is it a problem to rely on?
Regards,
Andreas
>
> (maybe there even exists syntactic sugar to express this using &uart0?)
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
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
^ permalink raw reply
* Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline
From: Andrew Lunn @ 2016-11-27 21:35 UTC (permalink / raw)
To: Andreas Färber
Cc: Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
David S . Miller, Sascha Hauer, Stefan Agner, Rob Herring,
Mark Rutland, Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e9336935-264e-5d1c-656e-a48f89d1b015-l3A5Bk7waGM@public.gmane.org>
On Sun, Nov 27, 2016 at 10:30:54PM +0100, Andreas Färber wrote:
> Hi,
>
> Am 27.11.2016 um 22:17 schrieb Andrew Lunn:
> > On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas Färber wrote:
> >> Found while reviewing Marvell dsa bindings usage.
> >
> > Hi Andreas
> >
> > It is good practice to put the maintainer you expect to accept the
> > patch on the To: line. You have at least two different maintainers on
> > Cc: so it is currently ambiguous. And these lists can be high volume,
> > so without a copy in the maintainers inbox, patches can be overlooked.
>
> As a vf610 DT patch with LAKML in To I am expecting it to be handled by
> Shawn or anyone from the NXP/ARM side.
So please have Shawn as To:
The patch you are fixing went through Dave Miller, who is also on Cc:,
hence the ambiguity.
Andrew
--
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
^ permalink raw reply
* Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline
From: Andreas Färber @ 2016-11-27 21:30 UTC (permalink / raw)
To: Andrew Lunn, Shawn Guo
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
David S . Miller, Sascha Hauer, Stefan Agner, Rob Herring,
Mark Rutland, Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161127211727.GB13318-g2DYL2Zd6BY@public.gmane.org>
Hi,
Am 27.11.2016 um 22:17 schrieb Andrew Lunn:
> On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas Färber wrote:
>> Found while reviewing Marvell dsa bindings usage.
>
> Hi Andreas
>
> It is good practice to put the maintainer you expect to accept the
> patch on the To: line. You have at least two different maintainers on
> Cc: so it is currently ambiguous. And these lists can be high volume,
> so without a copy in the maintainers inbox, patches can be overlooked.
As a vf610 DT patch with LAKML in To I am expecting it to be handled by
Shawn or anyone from the NXP/ARM side.
>> Fixes: f283745b3caf ("arm: vf610: zii devel b: Add support for switch interrupts")
>> Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>> Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
>
> Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
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
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Fix armada-385-turris-omnia stdout-path
From: Uwe Kleine-König @ 2016-11-27 21:25 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Andrew Lunn, Jason Cooper, devicetree-u79uwXL29TY76Z2rM5mHXA,
Tomas Hlavacek, Russell King, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Gregory Clement, Sebastian Hesselbarth,
Bedřicha Košatu, Michal Hrusecki
In-Reply-To: <1480275444-4220-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org>
On Sun, Nov 27, 2016 at 08:37:24PM +0100, Andreas Färber wrote:
> Specify the baudrate.
>
> Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
> Cc: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
You said with plain &uart0 the kernel uses a wrong baud rate? That's
strange. For me it works and I think it's the intended behaviour to
dermine the baud rate setup by the bootloader and use this.
I'd prefer it this way over hard coding the baud rate.
> arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> index f53cb8b73610..2eff012287d4 100644
> --- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -52,7 +52,7 @@
> compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
>
> chosen {
> - stdout-path = &uart0;
> + stdout-path = "serial0:115200n8";
> };
>
> memory {
This has the downside to depend on the alias. Not sure this is
considered modern. An alternative would be:
stdout-path = "/soc/internal-regs/serial@12000:115200n8";
(maybe there even exists syntactic sugar to express this using &uart0?)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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
^ permalink raw reply
* Re: [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Andreas Färber @ 2016-11-27 21:22 UTC (permalink / raw)
To: Uwe Kleine-König, Andrew Lunn
Cc: Gregory CLEMENT, Mark Rutland, Michal Hrusecky, Jason Cooper,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tomas Hlavacek, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Bedřicha Košatu, Sebastian Hesselbarth
In-Reply-To: <a7f47999-ec83-6cc8-8119-0087dee17bac-l3A5Bk7waGM@public.gmane.org>
Am 27.11.2016 um 17:00 schrieb Andreas Färber:
> @Uwe: Note that I had already told CZ.NIC's Michal ~two weeks ago that I
> have a WIP .dts for the Omnia - looks like no one knows what the other
> is doing. :( My branch includes cleanups for 385 .dtsi and bug fixes for
> the switch that I am not seeing in your series:
>
> https://github.com/afaerber/linux/commits/omnia-next
Archived at https://github.com/afaerber/linux/commits/omnia-next.pre-uwe
It seems like four out of my five switch probing bug fixes were already
resolved by Andrew in the meantime. Remaining one plus 88E6176
mini-series sent out.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
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
^ permalink raw reply
* Re: [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline
From: Andrew Lunn @ 2016-11-27 21:17 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
David S . Miller, Shawn Guo, Sascha Hauer, Stefan Agner,
Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480276484-5482-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org>
On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas Färber wrote:
> Found while reviewing Marvell dsa bindings usage.
Hi Andreas
It is good practice to put the maintainer you expect to accept the
patch on the To: line. You have at least two different maintainers on
Cc: so it is currently ambiguous. And these lists can be high volume,
so without a copy in the maintainers inbox, patches can be overlooked.
> Fixes: f283745b3caf ("arm: vf610: zii devel b: Add support for switch interrupts")
> Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
> ---
> arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> index 7ea617e47fe4..958b4c42d320 100644
> --- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> +++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> @@ -153,7 +153,8 @@
> switch0phy1: switch1phy0@1 {
> reg = <1>;
> interrupt-parent = <&switch0>;
> - interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; };
> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
> + };
> switch0phy2: switch1phy0@2 {
> reg = <2>;
> interrupt-parent = <&switch0>;
> --
> 2.6.6
>
--
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
^ permalink raw reply
* Re: [PATCH] ARM: dts: mvebu: Fix armada-385-turris-omnia stdout-path
From: Andrew Lunn @ 2016-11-27 21:10 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König, Michal Hrusecki, Tomas Hlavacek,
Bed??icha Ko??atu, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480275444-4220-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org>
On Sun, Nov 27, 2016 at 08:37:24PM +0100, Andreas Färber wrote:
> Specify the baudrate.
Hi Andreas
Please put each patch/patchset in a new thread.
> Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
> Cc: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
--
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
^ permalink raw reply
* [PATCH 1/2] Documentation: net: dsa: marvell: Add 88E6176
From: Andreas Färber @ 2016-11-27 20:57 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König, Michal Hrusecki, Tomas Hlavacek,
Bedřicha Košatu, Andreas Färber, Rob Herring,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
---
Documentation/devicetree/bindings/net/dsa/marvell.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt b/Documentation/devicetree/bindings/net/dsa/marvell.txt
index b3dd6b40e0de..000bc3b16edd 100644
--- a/Documentation/devicetree/bindings/net/dsa/marvell.txt
+++ b/Documentation/devicetree/bindings/net/dsa/marvell.txt
@@ -15,6 +15,7 @@ Additional required and optional properties can be found in dsa.txt.
Required properties:
- compatible : Should be one of "marvell,mv88e6085" or
+ "marvell,mv88e6176" or
"marvell,mv88e6190"
- reg : Address on the MII bus for the switch.
--
2.6.6
--
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
^ permalink raw reply related
* [PATCH v3 2/2] of: resolver: Fix checkpatch warnings
From: Moritz Fischer @ 2016-11-27 20:20 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w,
mdf-DgEjT+Ai2ygdnm+yROfE0A, Moritz Fischer
In-Reply-To: <1480278058-19688-1-git-send-email-moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
Fix two line over 80 character warnings that checkpatch spit out:
Before:
total: 0 errors, 2 warnings, 374 lines checked
drivers/of/resolver.c has style problems, please review.
After:
total: 0 errors, 0 warnings, 376 lines checked
Signed-off-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
---
Hi,
this one just silences two checkpatch warnings that I ran
into when running checkpatch against my patches.
There's a bunch of 'CHECK' level things in this file that
I could address in a follow up patch if desired.
Cheers,
Moritz
---
drivers/of/resolver.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 5f51a4a..71f98dc 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -311,7 +311,8 @@ int of_resolve_phandles(struct device_node *overlay)
if (!of_node_cmp(local_fixups->name, "__local_fixups__"))
break;
- err = adjust_local_phandle_references(local_fixups, overlay, phandle_delta);
+ err = adjust_local_phandle_references(local_fixups, overlay,
+ phandle_delta);
if (err) {
pr_err("overlay phandle fixup failed: %d\n", err);
return err;
@@ -356,7 +357,8 @@ int of_resolve_phandles(struct device_node *overlay)
phandle = refnode->phandle;
of_node_put(refnode);
- err = update_usages_of_a_phandle_reference(overlay, prop, phandle);
+ err = update_usages_of_a_phandle_reference(overlay, prop,
+ phandle);
if (err)
break;
}
--
2.7.4
--
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
^ permalink raw reply related
* [PATCH v3 1/2] of: Fix issue where code would fall through to error case.
From: Moritz Fischer @ 2016-11-27 20:20 UTC (permalink / raw)
To: devicetree
Cc: linux-kernel, frowand.list, robh+dt, pantelis.antoniou, mdf,
Moritz Fischer
No longer fall through into the error case that prints out
an error if no error (err = 0) occurred.
Rework error handling to print error where it occured instead
of having a global catch-all at the end of the function.
Fixes d9181b20a83(of: Add back an error message, restructured)
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Reviewed-by: Frank Rowand <frank.rowand@am.sony.com>
---
Hi Rob, Frank
this has already Frank's Reviewed-by: tag on it, but since I changed around the
earlier part (before tree_node gets assigned) Frank might wanna take another look
at this.
Changes from v2:
* Change error printouts to print error where it's produced
* Before tree_symbols gets assigned a non-NULL value, directly return error
instead of goto out, since of_put_node will be a no-op for !tree_symbols
Changes from v1:
* Implemented Frank's suggestion
Cheers,
Moritz
---
drivers/of/resolver.c | 38 ++++++++++++++++++--------------------
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 783bd09..5f51a4a 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -296,14 +296,12 @@ int of_resolve_phandles(struct device_node *overlay)
tree_symbols = NULL;
if (!overlay) {
- pr_err("null overlay\n");
- err = -EINVAL;
- goto err_out;
+ pr_err("overlay phandle fixup failed: null overlay\n");
+ return -EINVAL;
}
if (!of_node_check_flag(overlay, OF_DETACHED)) {
- pr_err("overlay not detached\n");
- err = -EINVAL;
- goto err_out;
+ pr_err("overlay phandle fixup failed: overlay not detached\n");
+ return -EINVAL;
}
phandle_delta = live_tree_max_phandle() + 1;
@@ -314,8 +312,10 @@ int of_resolve_phandles(struct device_node *overlay)
break;
err = adjust_local_phandle_references(local_fixups, overlay, phandle_delta);
- if (err)
- goto err_out;
+ if (err) {
+ pr_err("overlay phandle fixup failed: %d\n", err);
+ return err;
+ }
overlay_fixups = NULL;
@@ -324,16 +324,13 @@ int of_resolve_phandles(struct device_node *overlay)
overlay_fixups = child;
}
- if (!overlay_fixups) {
- err = 0;
- goto out;
- }
+ if (!overlay_fixups)
+ return 0;
tree_symbols = of_find_node_by_path("/__symbols__");
if (!tree_symbols) {
- pr_err("no symbols in root of device tree.\n");
- err = -EINVAL;
- goto err_out;
+ pr_err("overlay phandle fixup failed: no symbols in root\n");
+ return -EINVAL;
}
for_each_property_of_node(overlay_fixups, prop) {
@@ -344,13 +341,16 @@ int of_resolve_phandles(struct device_node *overlay)
err = of_property_read_string(tree_symbols,
prop->name, &refpath);
- if (err)
- goto err_out;
+ if (err) {
+ pr_err("overlay phandle fixup failed: %d\n", err);
+ goto out;
+ }
refnode = of_find_node_by_path(refpath);
if (!refnode) {
err = -ENOENT;
- goto err_out;
+ pr_err("overlay phandle fixup failed: !refnode\n");
+ goto out;
}
phandle = refnode->phandle;
@@ -361,8 +361,6 @@ int of_resolve_phandles(struct device_node *overlay)
break;
}
-err_out:
- pr_err("overlay phandle fixup failed: %d\n", err);
out:
of_node_put(tree_symbols);
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline
From: Andreas Färber @ 2016-11-27 19:54 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Andreas Färber, Andrew Lunn, David S . Miller, Shawn Guo,
Sascha Hauer, Stefan Agner, Rob Herring, Mark Rutland,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Found while reviewing Marvell dsa bindings usage.
Fixes: f283745b3caf ("arm: vf610: zii devel b: Add support for switch interrupts")
Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
---
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 7ea617e47fe4..958b4c42d320 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -153,7 +153,8 @@
switch0phy1: switch1phy0@1 {
reg = <1>;
interrupt-parent = <&switch0>;
- interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; };
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
+ };
switch0phy2: switch1phy0@2 {
reg = <2>;
interrupt-parent = <&switch0>;
--
2.6.6
--
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
^ permalink raw reply related
* Re: [PATCH v5 2/2] ARM: dts: add support for Turris Omnia
From: Andreas Färber @ 2016-11-27 19:39 UTC (permalink / raw)
To: Uwe Kleine-König, Gregory Clement
Cc: Mark Rutland, Andrew Lunn, Jason Cooper,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tomas Hlavacek, Rob Herring,
Bedřicha Košatu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <71af60f5-b657-cab4-32a8-00a604fc656e-l3A5Bk7waGM@public.gmane.org>
Am 27.11.2016 um 20:22 schrieb Andreas Färber:
> Am 25.11.2016 um 15:26 schrieb Uwe Kleine-König:
>> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> new file mode 100644
>> index 000000000000..bcc10c285889
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> [...]
>> + chosen {
>> + stdout-path = &uart0;
>> + };
>
> I notice that the other 38x boards (and thus my previous Omnia .dts) use
> "serial0:115200n8". Can we really rely on the driver defaults here?
Answering my own question: No, with the mvebu/dt .dts I do not get any
serial output. Patch sent.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox