* [resend][PATCH v5 05/10] ASoC: simple-card-utils: enable "label" on asoc_simple_card_parse_card_name
From: Kuninori Morimoto @ 2017-04-03 8:13 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: Linux-ALSA, Simon, Linux-DT
In-Reply-To: <87vaqlnceg.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Current asoc_simple_card_parse_card_name() detect [prefix]name,
but in generally, we uses "label" for user visible names.
This patch enables [prefix]label too.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
---
v4 -> v5
- don't exchange simle-xxx-card side
sound/soc/generic/simple-card-utils.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c
index 4924575..4dfd9a2 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -82,14 +82,24 @@ int asoc_simple_card_parse_card_name(struct snd_soc_card *card,
char *prefix)
{
char prop[128];
+ char *names[] = {
+ "label", "name"
+ };
+ int i;
int ret;
- snprintf(prop, sizeof(prop), "%sname", prefix);
+ if (!prefix)
+ prefix = "";
/* Parse the card name from DT */
- ret = snd_soc_of_parse_card_name(card, prop);
- if (ret < 0)
- return ret;
+ for (i = 0; i < ARRAY_SIZE(names); i++) {
+ snprintf(prop, sizeof(prop), "%s%s", prefix, names[i]);
+ ret = snd_soc_of_parse_card_name(card, prop);
+ if (ret < 0)
+ return ret;
+ if (card->name)
+ break;
+ }
if (!card->name && card->dai_link)
card->name = card->dai_link->name;
--
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
* [resend][PATCH v5 04/10] of_graph: add of_graph_get_endpoint_count()
From: Kuninori Morimoto @ 2017-04-03 8:12 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: Linux-DT, Linux-ALSA, Simon
In-Reply-To: <87vaqlnceg.wl%kuninori.morimoto.gx@renesas.com>
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()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v4 -> v5
- no change
drivers/of/base.c | 12 ++++++++++++
include/linux/of_graph.h | 6 ++++++
2 files changed, 18 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index eac37014..812edb9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2527,6 +2527,18 @@ struct device_node *of_graph_get_remote_port(const struct device_node *node)
}
EXPORT_SYMBOL(of_graph_get_remote_port);
+int of_graph_get_endpoint_count(const struct device_node *np)
+{
+ struct device_node *endpoint;
+ int num = 0;
+
+ for_each_endpoint_of_node(np, endpoint)
+ num++;
+
+ return num;
+}
+EXPORT_SYMBOL(of_graph_get_endpoint_count);
+
/**
* of_graph_get_remote_node() - get remote parent device_node for given port/endpoint
* @node: pointer to parent device_node containing graph port/endpoint
diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index 9db632d..3e058f0 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -43,6 +43,7 @@ struct of_endpoint {
#ifdef CONFIG_OF
int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
+int of_graph_get_endpoint_count(const struct device_node *np);
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);
@@ -64,6 +65,11 @@ static inline int of_graph_parse_endpoint(const struct device_node *node,
return -ENOSYS;
}
+static inline int of_graph_get_endpoint_count(const struct device_node *np)
+{
+ return 0;
+}
+
static inline struct device_node *of_graph_get_port_by_id(
struct device_node *node, u32 id)
{
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Neil Armstrong @ 2017-04-03 8:12 UTC (permalink / raw)
To: Guillaume Tucker, Rob Herring, Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sjoerd Simons, Wookey,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, John Reitan,
Enric Balletbo i Serra,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <db45d0d68957d699f13a0d92f4f84d8ebfd0270e.1491118230.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 04/02/2017 09:59 AM, Guillaume Tucker wrote:
> The ARM Mali Midgard GPU family is present in a number of SoCs
> from many different vendors such as Samsung Exynos and Rockchip.
>
> Import the device tree bindings documentation from the r16p0
> release of the Mali Midgard GPU kernel driver:
>
> https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
>
> The following optional bindings have been omitted in this initial
> version as they are only used in very specific cases:
>
> * snoop_enable_smc
> * snoop_disable_smc
> * jm_config
> * power_model
> * system-coherency
> * ipa-model
>
> The example has been simplified accordingly.
>
> The compatible string definition has been limited to
> "arm,mali-midgard" to avoid checkpatch.pl warnings and to match
> what the driver actually expects (as of r16p0 out-of-tree).
>
> CC: John Reitan <john.reitan-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> .../devicetree/bindings/gpu/arm,mali-midgard.txt | 53 ++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> new file mode 100644
> index 000000000000..da8fc6d21bbf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -0,0 +1,53 @@
> +#
> +# (C) COPYRIGHT 2013-2016 ARM Limited.
> +# Copyright (C) 2017 Collabora Ltd
> +#
> +# This program is free software and is provided to you under the terms of the
> +# GNU General Public License version 2 as published by the Free Software
> +# Foundation, and any use by you of this program is subject to the terms
> +# of such GNU licence.
> +#
Hi Guillaume,
This is unnecessary, please remove.
> +
> +
> +ARM Mali Midgard GPU
> +====================
> +
> +Required properties:
> +
> +- compatible : Should be "arm,mali-midgard".
> +- reg : Physical base address of the device and length of the register area.
> +- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
> +- interrupt-names : Contains the names of IRQ resources in the order they were
> + provided in the interrupts property. Must contain: "JOB, "MMU", "GPU".
Please follow the bindings introduced for the utgard family :
https://patchwork.kernel.org/patch/9553745/
- an entry for each mali-midgard revision, i.e. "arm,mali-t820"
- an entry for each vendor specific wrapping if necessary, i.e. "amlogic,meson-gxm-mali"
- low-case for interrupt names
> +
> +Optional:
> +
> +- clocks : Phandle to clock for the Mali Midgard device.
> +- clock-names : Shall be "clk_mali".
> +- mali-supply : Phandle to regulator for the Mali device. Refer to
> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
> + for details.
Please add :
* Must be one of the following:
"arm,mali-t820"
* And, optionally, one of the vendor specific compatible:
"amlogic,meson-gxm-mali"
with my Ack for the amlogic platform.
> +
> +Example for a Mali-T602:
> +
> +gpu@0xfc010000 {
> + compatible = "arm,mali-midgard";
> + reg = <0xfc010000 0x4000>;
> + interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
> + interrupt-names = "JOB", "MMU", "GPU";
> +
> + clocks = <&pclk_mali>;
> + clock-names = "clk_mali";
> + mali-supply = <&vdd_mali>;
> + operating-points = <
> + /* KHz uV */
> + 533000 1250000,
> + 450000 1150000,
> + 400000 1125000,
> + 350000 1075000,
> + 266000 1025000,
> + 160000 925000,
> + 100000 912500,
> + >;
> +};
>
Thanks,
Neil
--
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
* [resend][PATCH v5 03/10] of_graph: add of_graph_get_port_parent()
From: Kuninori Morimoto @ 2017-04-03 8:12 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: Linux-ALSA, Simon, Linux-DT
In-Reply-To: <87vaqlnceg.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>
---
v4 -> v5
- 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 3fad47f..eac37014 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2469,6 +2469,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
*
@@ -2479,18 +2500,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 0c9473a..9db632d 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -50,6 +50,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);
@@ -88,6 +89,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
* [resend][PATCH v5 02/10] of_graph: add of_graph_get_remote_endpoint()
From: Kuninori Morimoto @ 2017-04-03 8:11 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: Linux-ALSA, Simon, Linux-DT
In-Reply-To: <87vaqlnceg.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>
---
v4 -> v5
- 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 d7c4629..3fad47f 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2455,6 +2455,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
*
@@ -2468,7 +2482,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--) {
@@ -2492,7 +2506,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 abdb02e..0c9473a 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);
@@ -80,6 +82,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
* [resend][PATCH v5 01/10] of_graph: export symbol of_phandle_iterator_init/next
From: Kuninori Morimoto @ 2017-04-03 8:11 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: Linux-DT, Linux-ALSA, Simon
In-Reply-To: <87vaqlnceg.wl%kuninori.morimoto.gx@renesas.com>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
of_for_each_phandle() uses of_phandle_iterator_init/next
but these aren't exported. So kernel module complile will say
ERROR: "of_phandle_iterator_init" [xxx.ko] undefined!
ERROR: "of_phandle_iterator_next" [xxx.ko] undefined!
This patch solves this issue
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
This patch is related to this patch-set
Subject: [PATCH v5 0/9] ASoC: add OF-graph base simple-card
Date: Tue, 21 Mar 2017 14:17:03 +0900
drivers/of/base.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 812edb9..bc42f91 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1570,6 +1570,7 @@ int of_phandle_iterator_init(struct of_phandle_iterator *it,
return 0;
}
+EXPORT_SYMBOL_GPL(of_phandle_iterator_init);
int of_phandle_iterator_next(struct of_phandle_iterator *it)
{
@@ -1639,6 +1640,7 @@ int of_phandle_iterator_next(struct of_phandle_iterator *it)
return -EINVAL;
}
+EXPORT_SYMBOL_GPL(of_phandle_iterator_next);
int of_phandle_iterator_args(struct of_phandle_iterator *it,
uint32_t *args,
--
1.9.1
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply related
* [resend][PATCH v5 00/10] ASoC: add OF-graph base simple-card
From: Kuninori Morimoto @ 2017-04-03 8:10 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: Linux-DT, Linux-ALSA, Simon
Hi Rob, Mark
2 weeks passed. I will re-post these patches.
I added already posted "base: export symbol of_phandle_iterator_init/next"
as [01/10] patch which is needed on this series.
Kuninori Morimoto (10):
of_graph: export symbol of_phandle_iterator_init/next
of_graph: add of_graph_get_remote_endpoint()
of_graph: add of_graph_get_port_parent()
of_graph: add of_graph_get_endpoint_count()
ASoC: simple-card-utils: enable "label" on asoc_simple_card_parse_card_name
ASoC: soc-core: enable "dai-name" on snd_soc_of_parse_daifmt()
ASoC: add snd_soc_get_dai_id()
ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()
ASoC: add audio-graph-card document
ASoC: add audio-graph-card support
.../devicetree/bindings/sound/audio-graph-card.txt | 124 +++++++++
drivers/of/base.c | 60 +++-
include/linux/of_graph.h | 21 ++
include/sound/simple_card_utils.h | 10 +
include/sound/soc.h | 1 +
sound/soc/generic/Kconfig | 8 +
sound/soc/generic/Makefile | 2 +
sound/soc/generic/audio-graph-card.c | 308 +++++++++++++++++++++
sound/soc/generic/simple-card-utils.c | 54 +++-
sound/soc/soc-core.c | 32 ++-
10 files changed, 604 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/audio-graph-card.txt
create mode 100644 sound/soc/generic/audio-graph-card.c
--
1.9.1
^ permalink raw reply
* Re: [PATCH v3 03/11] dt-bindings: add bindings for DE2 on V3s SoC
From: Maxime Ripard @ 2017-04-03 8:00 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20170329194613.55548-4-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]
On Thu, Mar 30, 2017 at 03:46:05AM +0800, Icenowy Zheng wrote:
> From: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>
> Allwinner V3s SoC have a display engine which have a different pipeline
> with older SoCs.
>
> Add document for it (new compatibles and the new "mixer" part).
>
> The paragraph of TCON is also refactored, for furtherly add TCONs in
> A83T/H3/A64/H5 that have only a channel 1 (used for HDMI or TV Encoder).
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> Changes in v3:
> - Remove the description of having a BE directly as allwinner,pipeline.
>
> .../bindings/display/sunxi/sun4i-drm.txt | 37 +++++++++++++++++++---
> 1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index b82c00449468..38de5e96f359 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -31,11 +31,11 @@ Required properties:
> * allwinner,sun6i-a31-tcon
> * allwinner,sun6i-a31s-tcon
> * allwinner,sun8i-a33-tcon
> + * allwinner,sun8i-v3s-tcon
> - reg: base address and size of memory-mapped region
> - interrupts: interrupt associated to this IP
> - - clocks: phandles to the clocks feeding the TCON. Three are needed:
> + - clocks: phandles to the clocks feeding the TCON
> - 'ahb': the interface clocks
> - - 'tcon-ch0': The clock driving the TCON channel 0
> - resets: phandles to the reset controllers driving the encoder
> - "lcd": the reset line for the TCON channel 0
>
> @@ -52,7 +52,12 @@ Required properties:
> second the block connected to the TCON channel 1 (usually the TV
> encoder)
>
> -On SoCs other than the A33, there is one more clock required:
> +On TCONs that have a channel 0 (currently all TCONs supported), there
> +is one more clock required:
> + - 'tcon-ch0': The clock driving the TCON channel 0
> +
Why did you change that if they all have a channel 0?
> +On TCONs that have a channel 1 (currently all TCONs except the ones in
> +A33 and V3s), there is one more clock required:
> - 'tcon-ch1': The clock driving the TCON channel 1
And that can be added too just by saying "On SoCs other than the A33
and V3".
Looks good otherwise, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [resend][PATCH v5 0/9] ASoC: add OF-graph base simple-card
From: Kuninori Morimoto @ 2017-04-03 7:59 UTC (permalink / raw)
To: Kuninori Morimoto; +Cc: Simon, Linux-ALSA, Mark Brown, Rob Herring, Linux-DT
In-Reply-To: <871stanczz.wl%kuninori.morimoto.gx@renesas.com>
Hi Rob, Mark
I posted this patch-set, but I had mistaken on mail header.
I will repost these
> Hi Rob, Mark
>
> 2 weeks passed. I will resend this patch-set.
>
> These are v5 of OF-graph base audio card patch-set.
> It fixed small things which was pointed by Rob.
>
> 1) - 3) : new OF-graph helper functions
> 4) - 5) : expand "label", "dai-format"
> 6) - 9) : OF-graph base simple-card
>
> Kuninori Morimoto (9):
> of_graph: add of_graph_get_remote_endpoint()
> of_graph: add of_graph_get_port_parent()
> of_graph: add of_graph_get_endpoint_count()
> ASoC: simple-card-utils: enable "label" on asoc_simple_card_parse_card_name
> ASoC: soc-core: enable "dai-name" on snd_soc_of_parse_daifmt()
> ASoC: add snd_soc_get_dai_id()
> ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()
> ASoC: add audio-graph-card document
> ASoC: add audio-graph-card support
>
> .../devicetree/bindings/sound/audio-graph-card.txt | 124 +++++++++
> drivers/of/base.c | 60 +++-
> include/linux/of_graph.h | 21 ++
> include/sound/simple_card_utils.h | 10 +
> include/sound/soc.h | 1 +
> sound/soc/generic/Kconfig | 8 +
> sound/soc/generic/Makefile | 2 +
> sound/soc/generic/audio-graph-card.c | 308 +++++++++++++++++++++
> sound/soc/generic/simple-card-utils.c | 54 +++-
> sound/soc/soc-core.c | 32 ++-
> 10 files changed, 604 insertions(+), 16 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/sound/audio-graph-card.txt
> create mode 100644 sound/soc/generic/audio-graph-card.c
>
> --
> 1.9.1
>
^ permalink raw reply
* [resend][PATCH v5 2/9] of_graph: add of_graph_get_port_parent()
From: Kuninori Morimoto @ 2017-04-03 7:57 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: Linux-ALSA, Simon, Linux-DT
In-Reply-To: <8737e79pkq.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>
---
v4 -> v5
- 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 3fad47f..eac37014 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2469,6 +2469,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
*
@@ -2479,18 +2500,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 0c9473a..9db632d 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -50,6 +50,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);
@@ -88,6 +89,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
* [resend][PATCH v5 1/9] of_graph: add of_graph_get_remote_endpoint()
From: Kuninori Morimoto @ 2017-04-03 7:57 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: Linux-DT, Linux-ALSA, Simon
In-Reply-To: <8737e79pkq.wl%kuninori.morimoto.gx@renesas.com>
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>
---
v4 -> v5
- 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 d7c4629..3fad47f 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2455,6 +2455,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
*
@@ -2468,7 +2482,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--) {
@@ -2492,7 +2506,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 abdb02e..0c9473a 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);
@@ -80,6 +82,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
^ permalink raw reply related
* [resend][PATCH v5 0/9] ASoC: add OF-graph base simple-card
From: Kuninori Morimoto @ 2017-04-03 7:57 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: Linux-ALSA, Simon, Linux-DT
Hi Rob, Mark
2 weeks passed. I will resend this patch-set.
These are v5 of OF-graph base audio card patch-set.
It fixed small things which was pointed by Rob.
1) - 3) : new OF-graph helper functions
4) - 5) : expand "label", "dai-format"
6) - 9) : OF-graph base simple-card
Kuninori Morimoto (9):
of_graph: add of_graph_get_remote_endpoint()
of_graph: add of_graph_get_port_parent()
of_graph: add of_graph_get_endpoint_count()
ASoC: simple-card-utils: enable "label" on asoc_simple_card_parse_card_name
ASoC: soc-core: enable "dai-name" on snd_soc_of_parse_daifmt()
ASoC: add snd_soc_get_dai_id()
ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()
ASoC: add audio-graph-card document
ASoC: add audio-graph-card support
.../devicetree/bindings/sound/audio-graph-card.txt | 124 +++++++++
drivers/of/base.c | 60 +++-
include/linux/of_graph.h | 21 ++
include/sound/simple_card_utils.h | 10 +
include/sound/soc.h | 1 +
sound/soc/generic/Kconfig | 8 +
sound/soc/generic/Makefile | 2 +
sound/soc/generic/audio-graph-card.c | 308 +++++++++++++++++++++
sound/soc/generic/simple-card-utils.c | 54 +++-
sound/soc/soc-core.c | 32 ++-
10 files changed, 604 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/audio-graph-card.txt
create mode 100644 sound/soc/generic/audio-graph-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 v3 0/5] Add support for the R_CCU on Allwinner H3/A64 SoCs
From: Maxime Ripard @ 2017-04-03 7:36 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Michael Turquette,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai, Rob Herring,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <alpine.LNX.2.20.1704030029590.823@x220i>
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]
On Mon, Apr 03, 2017 at 12:32:08AM +0800, Icenowy Zheng wrote:
>
>
> On Sun, 2 Apr 2017, Maxime Ripard wrote:
>
> > Hi,
> >
> > On Wed, Mar 29, 2017 at 06:42:41PM +0800, Icenowy Zheng wrote:
> > > Allwinner SoCs after sun6i-a31 nearly all have a R_CCU in PRCM part.
> > > (V3s and R40 do not have it, as they have even no PRCM)
> > >
> > > This patch adds support for the ones on H3/A64.
> > >
> > > Some clock/reset values are reserved for easier extending the support to
> > > A31/A23, but for this I think some changes to the PRCM MFD should be made,
> > > see [1] (Although this is only a sketch).
> > >
> > > The r_pio device node is also added for A64, as the driver is already
> > > merged, and its depends (r_ccu) is now met.
> > >
> > > [1] https://github.com/wens/linux/commits/sunxi-ng-prcm
> >
> > It looks good now, thanks.
> >
> > Beside from the minor fix you've mentionned, please don't use the
> > defined IDs (yet) in your DT patches (3 to 5).
>
> Thanks! (I think it's the same question we meet when merging V3s patchset,
> right? :-) )
Exactly. When doing that kind of conversion, in order to not break the
compilation, we would take the DT patches through the clock
tree.
However, this doesn't work very well when we also have DT patches that
conflicts with those clock conversion ones that would need to get
through arm-soc.
And in this case, this is even more complex since you have the H3/H5
split patches that would need to go through yet another branch.
Not using the defines for now, and sending a fix later fixes all these
issues.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/2] drivers/serial: Add driver for Aspeed virtual UART
From: Joel Stanley @ 2017-04-03 7:11 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Greg Kroah-Hartman, Jiri Slaby, Mark Rutland, Rob Herring,
Jeremy Kerr, linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
OpenBMC Maillist, devicetree, Benjamin Herrenschmidt
In-Reply-To: <CAHp75VfmbHrPFXO3UFmSciCnVuoB+5vFxy7iOnwVS5YBSPO3+Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Andy,
Thanks for the review. I've incorporatd most of your comments in a v2
that I'll send out once I've given it a spin on hardware.
On Sun, Apr 2, 2017 at 10:37 PM, Andy Shevchenko
<andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> +static ssize_t ast_vuart_show_addr(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct ast_vuart *vuart = dev_get_drvdata(dev);
>> + u16 addr;
>> +
>
>> + addr = (readb(vuart->regs + AST_VUART_ADDRH) << 8) |
>> + (readb(vuart->regs + AST_VUART_ADDRL));
>
> It looks like you have register shift 2 bits and byte accessors. We
> have some helpers for that (serial_in() / serial_out() or alike).
Thanks for the pointer. I took a look at this. It looks like I need to
define my own accessor?
I don't think it's worth it for the one read and one write we have in
this driver.
>
>> +
>> + return snprintf(buf, PAGE_SIZE - 1, "0x%x\n", addr);
>> +}
>> +
>> +static int ast_vuart_probe(struct platform_device *pdev)
>> +{
>> + struct uart_8250_port port;
>> + struct resource resource;
>> + struct ast_vuart *vuart;
>> + struct device_node *np;
>> + u32 clk, prop;
>> + int rc;
>> +
>
>> + np = pdev->dev.of_node;
>
> And if np == NULL?
The driver will fail to probe due to the of_property_read_u32 calls
returning an error.
>> + /* If current-speed was set, then try not to change it. */
>> + if (of_property_read_u32(np, "current-speed", &prop) == 0)
>> + port.port.custom_divisor = clk / (16 * prop);
>> +
>> + /* Check for shifted address mapping */
>> + if (of_property_read_u32(np, "reg-offset", &prop) == 0)
>> + port.port.mapbase += prop;
>> +
>> + /* Check for registers offset within the devices address range */
>> + if (of_property_read_u32(np, "reg-shift", &prop) == 0)
>> + port.port.regshift = prop;
>> +
>> + /* Check for fifo size */
>> + if (of_property_read_u32(np, "fifo-size", &prop) == 0)
>> + port.port.fifosize = prop;
>
> Perhaps you need other way around, check for error and supply a
> default in such case.
We leave port.fifosize unmodified (set to zero) if there is no valid
device tree property. As the property is optional, it's not an error
if it's not present.
>> +
>> + /* Check for a fixed line number */
>> + rc = of_alias_get_id(np, "serial");
>> + if (rc >= 0)
>> + port.port.line = rc;
>> +
>> + port.port.irq = irq_of_parse_and_map(np, 0);
>
>> + port.port.irqflags = IRQF_SHARED;
>
> This is set by core. You already supplied correct flag for that below.
By setting UPF_SHARE_IRQ the core does correctly requset_irq with
IRQF_SHARED set. However, it does not store this in in port->irqflags,
so other tests in eg. serial8250_do_startup that test for IRQF_SHARED
will fail. This is a bug that we hit the other day.
Would you like a patch to the core that either tests for
UPF_SHARE_IRQ, or set IRQF_SHARED early on?
>
>> + port.port.iotype = UPIO_MEM;
>> + if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {
>
> You hide an error code from of_property_read_u32() here. Why?
The property is optional, so if it doesn't exist we want to continue
without error.
We return EINVAL if the property is invalid, as the device tree code
will give us ENODATA or EOVERFLOW, which I don't think is informative
for a driver to return.
> And if there is an error you are continuing with what? 0?
we continue with port.port.iotype = UPIO_MEM from above.
>> + switch (prop) {
>> + case 1:
>> + port.port.iotype = UPIO_MEM;
>> + break;
>> + case 4:
>> + port.port.iotype = of_device_is_big_endian(np) ?
>> + UPIO_MEM32BE : UPIO_MEM32;
>> + break;
>> + default:
>> + dev_warn(&pdev->dev, "unsupported reg-io-width (%d)\n",
>> + prop);
>> + rc = -EINVAL;
>> + goto err_clk_disable;
>> + }
>> + }
Cheers,
Joel
--
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: [RFC PATCH v2 4/4] ARM: sun8i: h3: add support for the thermal sensor in H3
From: Maxime Ripard @ 2017-04-03 6:42 UTC (permalink / raw)
To: Quentin Schulz
Cc: icenowy-h8G6r0blFSE, Lee Jones, Chen-Yu Tsai, Jonathan Cameron,
Zhang Rui, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <3f13c07d-be6a-0350-6d86-de1a4d4e33a8-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]
On Sun, Apr 02, 2017 at 04:34:55PM +0200, Quentin Schulz wrote:
> Hi Icenowy,
>
> On 02/04/2017 15:33, Icenowy Zheng wrote:
> > As we have gained the support for the thermal sensor in H3, we can now
> > add its device nodes to the device tree.
> >
> > Add them to the H3 device tree.
> >
> > The H5 thermal sensor has some differences, and will be added furtherly.
> >
> > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> > ---
> > arch/arm/boot/dts/sun8i-h3.dtsi | 26 ++++++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index b36f9f423c39..552217bb9266 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -72,6 +72,32 @@
> > };
> > };
> >
> > + iio-hwmon {
> > + compatible = "iio-hwmon";
> > + io-channels = <&ths>;
> > + };
> > +
> > + soc {
> > + ths: ths@01c25000 {
> > + compatible = "allwinner,sun8i-h3-ths";
> > + reg = <0x01c25000 0x100>;
> > + clocks = <&ccu CLK_BUS_THS>, <&ccu CLK_THS>;
> > + clock-names = "bus", "ths";
> > + resets = <&ccu RST_BUS_THS>;
> > + #thermal-sensor-cells = <0>;
> > + #io-channel-cells = <0>;
> > + };
> > + };
> > +
> > + thermal-zones {
> > + cpu_thermal {
> > + /* milliseconds */
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > + thermal-sensors = <&ths>;
> > + };
>
> Would it make sense to add the CPU temp trip points in this patch?
No.
This is a separate, unrelated, change that has nothing to do with what
is described either in the commit title or the commit log.
The thermal zone itself shouldn't even be in this patch.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] arm64: dts: uniphier: add input-delay properties to Cadence eMMC node
From: Masahiro Yamada @ 2017-04-03 6:28 UTC (permalink / raw)
To: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Piotr Sroka, Masahiro Yamada, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, Rob Herring, Will Deacon, Mark Rutland,
Catalin Marinas, linux-arm-kernel
In-Reply-To: <1490934045-18874-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
MTD developers,
Please ignore this patch.
I accidentally sent this patch to a wrong ML.
Sorry for the noise.
2017-03-31 13:20 GMT+09:00 Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>:
> Since commit a04e2b383401 ("mmc: sdhci-cadence: Update PHY delay
> configuration"), PHY parameters must be specified by DT.
>
> The hard-coded settings have been converted as follows:
> - SDHCI_CDNS_PHY_DLY_SD_DEFAULT -> cdns,phy-input-delay-legacy
> - SDHCI_CDNS_PHY_DLY_EMMC_SDR -> cdns,phy-input-delay-mmc-highspeed
> - SDHCI_CDNS_PHY_DLY_EMMC_DDR -> cdns,phy-input-delay-mmc-ddr
>
> The following have not been moved:
> - SDHCI_CDNS_PHY_DLY_SD_HS
> this is unneeded in the eMMC configuration
> - SDHCI_CDNS_PHY_DLY_EMMC_LEGACY
> this is never enabled by the driver as it is covered by
> SDHCI_CDNS_PHY_DLY_SD_DEFAULT
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
> ---
>
> arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 3 +++
> arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
> index 5dc5124..b6ebdc9 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
> @@ -310,6 +310,9 @@
> bus-width = <8>;
> mmc-ddr-1_8v;
> mmc-hs200-1_8v;
> + cdns,phy-input-delay-legacy = <4>;
> + cdns,phy-input-delay-mmc-highspeed = <2>;
> + cdns,phy-input-delay-mmc-ddr = <3>;
> };
>
> usb0: usb@5a800100 {
> diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> index 6c9a72d..0ab6c2e 100644
> --- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> +++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
> @@ -394,6 +394,9 @@
> bus-width = <8>;
> mmc-ddr-1_8v;
> mmc-hs200-1_8v;
> + cdns,phy-input-delay-legacy = <4>;
> + cdns,phy-input-delay-mmc-highspeed = <2>;
> + cdns,phy-input-delay-mmc-ddr = <3>;
> };
>
> sd: sdhc@5a400000 {
> --
> 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
--
Best Regards
Masahiro Yamada
--
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
* (unknown),
From: Adrian Gillian Bayford @ 2017-04-03 6:14 UTC (permalink / raw)
To: Recipients
£1.5 Million Has Been Granted To You As A Donation Visit www.bbc.co.uk/news/uk-england-19254228 Sendname Address Phone for more info
--
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 net-next v3 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch
From: kbuild test robot @ 2017-04-03 5:06 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, andrew-g2DYL2Zd6BY,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, sean.wang-NuS5LvNUpcJWk0Htik3J/w,
Landen.Chao-NuS5LvNUpcJWk0Htik3J/w,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w, objelf-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1490780303-18598-6-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4576 bytes --]
Hi Sean,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/net-next-dsa-add-Mediatek-MT7530-support/20170330-135532
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All errors (new ones prefixed by >>):
In file included from net//dsa/tag_mtk.c:16:0:
net//dsa/dsa_priv.h:51:16: warning: 'struct dsa_switch' declared inside parameter list
struct dsa_port *dport, int port);
^
net//dsa/dsa_priv.h:51:16: warning: its scope is only this definition or declaration, which is probably not what you want
net//dsa/dsa_priv.h:54:39: warning: 'struct dsa_switch' declared inside parameter list
int dsa_cpu_port_ethtool_setup(struct dsa_switch *ds);
^
net//dsa/dsa_priv.h:55:42: warning: 'struct dsa_switch' declared inside parameter list
void dsa_cpu_port_ethtool_restore(struct dsa_switch *ds);
^
net//dsa/dsa_priv.h:59:36: warning: 'struct dsa_switch' declared inside parameter list
void dsa_slave_mii_bus_init(struct dsa_switch *ds);
^
net//dsa/dsa_priv.h:62:8: warning: 'struct dsa_switch' declared inside parameter list
int port, const char *name);
^
net//dsa/dsa_priv.h:70:41: warning: 'struct dsa_switch' declared inside parameter list
int dsa_switch_register_notifier(struct dsa_switch *ds);
^
net//dsa/dsa_priv.h:71:44: warning: 'struct dsa_switch' declared inside parameter list
void dsa_switch_unregister_notifier(struct dsa_switch *ds);
^
net//dsa/tag_mtk.c: In function 'mtk_tag_xmit':
>> net//dsa/tag_mtk.c:38:26: error: dereferencing pointer to incomplete type
mtk_tag[1] = (1 << p->dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
^
net//dsa/tag_mtk.c: In function 'mtk_tag_rcv':
net//dsa/tag_mtk.c:85:10: error: dereferencing pointer to incomplete type
ds = dst->ds[0];
^
net//dsa/tag_mtk.c:91:9: error: dereferencing pointer to incomplete type
if (!ds->ports[port].netdev)
^
net//dsa/tag_mtk.c:98:15: error: dereferencing pointer to incomplete type
skb->dev = ds->ports[port].netdev;
^
vim +38 net//dsa/tag_mtk.c
2faad9d7 Sean Wang 2017-03-29 22 static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
2faad9d7 Sean Wang 2017-03-29 23 struct net_device *dev)
2faad9d7 Sean Wang 2017-03-29 24 {
2faad9d7 Sean Wang 2017-03-29 25 struct dsa_slave_priv *p = netdev_priv(dev);
2faad9d7 Sean Wang 2017-03-29 26 u8 *mtk_tag;
2faad9d7 Sean Wang 2017-03-29 27
2faad9d7 Sean Wang 2017-03-29 28 if (skb_cow_head(skb, MTK_HDR_LEN) < 0)
2faad9d7 Sean Wang 2017-03-29 29 goto out_free;
2faad9d7 Sean Wang 2017-03-29 30
2faad9d7 Sean Wang 2017-03-29 31 skb_push(skb, MTK_HDR_LEN);
2faad9d7 Sean Wang 2017-03-29 32
2faad9d7 Sean Wang 2017-03-29 33 memmove(skb->data, skb->data + MTK_HDR_LEN, 2 * ETH_ALEN);
2faad9d7 Sean Wang 2017-03-29 34
2faad9d7 Sean Wang 2017-03-29 35 /* Build the tag after the MAC Source Address */
2faad9d7 Sean Wang 2017-03-29 36 mtk_tag = skb->data + 2 * ETH_ALEN;
2faad9d7 Sean Wang 2017-03-29 37 mtk_tag[0] = 0;
2faad9d7 Sean Wang 2017-03-29 @38 mtk_tag[1] = (1 << p->dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
2faad9d7 Sean Wang 2017-03-29 39 mtk_tag[2] = 0;
2faad9d7 Sean Wang 2017-03-29 40 mtk_tag[3] = 0;
2faad9d7 Sean Wang 2017-03-29 41
2faad9d7 Sean Wang 2017-03-29 42 return skb;
2faad9d7 Sean Wang 2017-03-29 43
2faad9d7 Sean Wang 2017-03-29 44 out_free:
2faad9d7 Sean Wang 2017-03-29 45 kfree_skb(skb);
2faad9d7 Sean Wang 2017-03-29 46 return NULL;
:::::: The code at line 38 was first introduced by commit
:::::: 2faad9d71e4c0544e3cf43b24439517c95df301f net-next: dsa: add Mediatek tag RX/TX handler
:::::: TO: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
:::::: CC: 0day robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 39990 bytes --]
^ permalink raw reply
* Re: [PATCH v6 0/4] phy: USB and PCIe phy drivers for Qcom chipsets
From: Vivek Gautam @ 2017-04-03 3:31 UTC (permalink / raw)
To: kishon, robh+dt
Cc: linux-arm-kernel, linux-arm-msm, linux-kernel, linux-usb,
devicetree, mark.rutland, sboyd, bjorn.andersson,
srinivas.kandagatla
In-Reply-To: <1490018046-8549-1-git-send-email-vivek.gautam@codeaurora.org>
On 03/20/2017 07:24 PM, Vivek Gautam wrote:
> This patch series adds couple of PHY drivers for Qualcomm chipsets.
> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
> b) qcom-qmp phy driver: that is a combo phy providing support for
> USB3, PCIe, UFS and few other controllers.
>
> The patches are based on next branch of linux-phy tree, and depends
> on phy driver grouping series[1]:
> [PATCH v4 0/3] phy: Group phy drivers based on vendor listing.
>
> These patches have been tested on Dragon board db820c hardware with
> required set of dt patches and the patches to get rpm up on msm8996.
> Couple of other patches [2, 3] fixing DMA config for XHCI are also
> pulled in for testing.
> The complete branch is available in github [4].
>
> Changes since v5:
> - Addressed review comments from Bjorn:
> - Removed instances of readl/wirtel_relaxed calls from the drivers.
> Instead, using simple readl/writel. Inserting a readl after a writel
> to ensure the write is through to the device.
> - Replaced regulator handling with regulator_bulk_** apis. This helps
> in cutting down a lot of regulator handling code.
> - Fixed minor return statements.
>
> Changes since v4:
> - Addressed comment to add child nodes for qmp phy driver. Each phy lane
> now has a separate child node under the main qmp node.
> - Modified the clock and reset initialization and enable methods.
> Different phys - pcie, usb and later ufs, have varying number of clocks
> and resets that are mandatory. So adding provision for clocks and reset
> lists helps in requesting all mandatory resources for individual phys
> and handle their failure cases accordingly.
>
> Changes since v3:
> - Addressed review comments given by Rob and Stephen for qusb2 phy
> and qmp phy bindings respectively.
> - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
>
> Changes since v2:
> - Addressed review comments given by Rob and Stephen for bindings.
> - Addressed the review comments given by Stephen for the qusb2 and qmp
> phy drivers.
>
> Changes since v1:
> - Moved device tree binding documentation to separate patches, as suggested
> by Rob.
> - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
> given by Rob.
> - Addressed review comments from Kishon.
> - Addressed review comments from Srinivas for QMP phy driver.
> - Addressed kbuild warning.
>
> Please see individual patches for detailed changelogs.
>
> [1] https://www.spinics.net/lists/arm-kernel/msg569990.html
> [2] https://patchwork.kernel.org/patch/9567767/
> [3] https://patchwork.kernel.org/patch/9567779/
> [4] https://github.com/vivekgautam1/linux/tree/linux-phy-next-qcom-phy-db820c
>
> Vivek Gautam (4):
> dt-bindings: phy: Add support for QUSB2 phy
> phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
> dt-bindings: phy: Add support for QMP phy
> phy: qcom-qmp: new qmp phy driver for qcom-chipsets
Gentle ping!
Any more comments on this series, or are we planning to get this in for
4.12 ?
Regards
Vivek
>
> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 ++
> .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 45 +
> drivers/phy/qualcomm/Kconfig | 18 +
> drivers/phy/qualcomm/Makefile | 2 +
> drivers/phy/qualcomm/phy-qcom-qmp.c | 1153 ++++++++++++++++++++
> drivers/phy/qualcomm/phy-qcom-qusb2.c | 491 +++++++++
> 6 files changed, 1815 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
> create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp.c
> create mode 100644 drivers/phy/qualcomm/phy-qcom-qusb2.c
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v3 14/37] mtd: nand: denali: support "nand-ecc-strength" DT property
From: Masahiro Yamada @ 2017-04-03 3:16 UTC (permalink / raw)
To: Boris Brezillon
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Enrico Jorns,
Artem Bityutskiy, Dinh Nguyen, Marek Vasut, Graham Moore,
David Woodhouse, Masami Hiramatsu, Chuanxiao Dong, Jassi Brar,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
Brian Norris, Richard Weinberger, Cyrille Pitchen, Rob Herring,
Mark Rutland
In-Reply-To: <20170331114659.4964be35@bbrezillon>
Hi Boris,
2017-03-31 18:46 GMT+09:00 Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> You can try something like that when no explicit ecc.strength and
> ecc.size has been set in the DT and when ECC_MAXIMIZE was not passed.
>
> static int
> denali_get_closest_ecc_strength(struct denali_nand_info *denali,
> int strength)
> {
> /*
> * Whatever you need to select a strength that is greater than
> * or equal to strength.
> */
>
> return X;
> }
Is here anything specific to Denali?
> static int denali_try_to_match_ecc_req(struct denali_nand_info *denali)
> {
> struct nand_chip *chip = &denali->nand;
> struct mtd_info *mtd = nand_to_mtd(chip);
> int max_ecc_bytes = mtd->oobsize - denali->bbtskipbytes;
> int ecc_steps, ecc_strength, ecc_bytes;
> int ecc_size = chip->ecc_step_ds;
> int ecc_strength = chip->ecc_strength_ds;
>
> /*
> * No information provided by the NAND chip, let the core
> * maximize the strength.
> */
> if (!ecc_size || !ecc_strength)
> return -ENOTSUPP;
>
> if (ecc_size > 512)
> ecc_size = 1024;
> else
> ecc_size = 512;
>
> /* Adjust ECC step size based on hardware support. */
> if (ecc_size == 1024 &&
> !(denali->caps & DENALI_CAP_ECC_SIZE_1024))
> ecc_size = 512;
> else if(ecc_size == 512 &&
> !(denali->caps & DENALI_CAP_ECC_SIZE_512))
> ecc_size = 1024;
>
> if (ecc_size < chip->ecc_size_ds) {
> /*
> * When the selected size if smaller than the expected
> * one we try to use the same strength but on 512 blocks
> * so that we can still fix the same number of errors
> * even if they are concentrated in the first 512bytes
> * of a 1024bytes portion.
> */
> ecc_strength = chip->ecc_strength_ds;
> ecc_strength = denali_get_closest_ecc_strength(denali,
> ecc_strength);
> } else {
> /* Always prefer 1024bytes ECC blocks when possible. */
> if (ecc_size != 1024 &&
> (denali->caps & DENALI_CAP_ECC_SIZE_1024) &&
> mtd->writesize > 1024)
> ecc_size = 1024;
>
> /*
> * Adjust the strength based on the selected ECC step
> * size.
> */
> ecc_strength = DIV_ROUND_UP(ecc_size,
> chip->ecc_step_ds) *
> chip->ecc_strength_ds;
> }
>
> ecc_bytes = denali_calc_ecc_bytes(ecc_size,
> ecc_strength);
> ecc_bytes *= mtd->writesize / ecc_size;
>
> /*
> * If we don't have enough space, let the core maximize
> * the strength.
> */
> if (ecc_bytes > max_ecc_bytes)
> return -ENOTSUPP;
>
> chip->ecc.strength = ecc_strength;
> chip->ecc.size = ecc_size;
>
> return 0;
> }
As a whole, this does not seem to driver-specific.
[1] A driver provides some pairs of (ecc_strength, ecc_size)
it can support.
[2] The core framework knows the chip's requirement
(ecc_strength_ds, ecc_size_ds).
Then, the core framework provides a function
to return a most recommended (ecc_strength, ecc_size).
struct nand_ecc_spec {
int ecc_strength;
int ecc_size;
};
/*
* This function choose the most recommented (ecc_str, ecc_size)
* "recommended" means: minimum ecc stregth that meets
* the chip's requirment.
*
*
* @chip - nand_chip
* @controller_ecc_spec - Array of (ecc_str, ecc_size) supported by the
controller. (terminated by NULL as sentinel)
*/
struct nand_ecc_spec * nand_try_to_match_ecc_req(struct nand_chip *chip,
struct nand_ecc_spec
*controller_ecc_spec)
{
/*
* Return the pointer to the most recommended
* struct nand_ecc_spec.
* If nothing suitable found, return NULL.
*/
}
Then, Denali driver can call it:
recommended_ecc_spec = nand_try_to_match_ecc_req(chip,
denali->ecc_spec);
if (recommended_ecc_spec) {
chip->ecc.strength = recommended_ecc_spec.ecc_strength;
chip->ecc.size = recommended_ecc_spec.ecc_size;
} else {
/*
* Do something (for example, maximize the ECC)
*/
}
It seems weird to force this to the Denali driver.
--
Best Regards
Masahiro Yamada
--
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 V4 1/2] dt-bindings: thermal: add support for Broadcom's Northstar thermal
From: Jon Mason @ 2017-04-03 3:07 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Eduardo Valentin, Florian Fainelli, Zhang Rui, Rob Herring,
Mark Rutland, Stephen Warren, Lee Jones, Eric Anholt, Ray Jui,
Scott Branden, BCM Kernel Feedback, linux-pm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-rpi-kernel, linux-arm-kernel, Rafał Miłecki
In-Reply-To: <6dd907e4-c213-3174-8613-99427e6ea0e9@gmail.com>
On Sat, Apr 1, 2017 at 5:50 PM, Rafał Miłecki <zajec5@gmail.com> wrote:
> On 04/01/2017 09:51 PM, Eduardo Valentin wrote:
>>
>> On Fri, Mar 31, 2017 at 10:11:23PM +0200, Rafał Miłecki wrote:
>>>
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> This commit documents binding for thermal used in Northstar family SoCs.
>>>
>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>> ---
>>> V3: Add thermal-zones to the example
>>> Rob: Because of this update, I didn't include Acked-by I got for V2
>>> ---
>>> .../devicetree/bindings/thermal/brcm,ns-thermal | 26
>>> ++++++++++++++++++++++
>>> 1 file changed, 26 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>>
>>> diff --git a/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>> b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>> new file mode 100644
>>> index 000000000000..c561c7349f17
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/thermal/brcm,ns-thermal
>>> @@ -0,0 +1,26 @@
>>> +* Broadcom Northstar Thermal
>>> +
>>> +This binding describes thermal sensor that is part of Northstar's DMU
>>> (Device
>>> +Management Unit).
>>> +
>>> +Required properties:
>>> +- compatible : Must be "brcm,ns-thermal"
>>> +- reg : iomem address range of PVTMON registers
>>> +- #thermal-sensor-cells : Should be <0>
>>> +
>>> +Example:
>>> +
>>> +thermal: thermal@1800c2c0 {
>>> + compatible = "brcm,ns-thermal";
>>> + reg = <0x1800c2c0 0x10>;
>>> + #thermal-sensor-cells = <0>;
>>> +};
>>> +
>>> +thermal-zones {
>>> + cpu_thermal: cpu-thermal {
>>> + polling-delay-passive = <0>;
>>> + polling-delay = <1000>;
>>> + coefficients = <(-556) 418000>;
>>> + thermal-sensors = <&thermal>;
>>
>>
>> You need to define trips and cooling devices here. Otherwise, makes
>> little sense to have this device in thermal subsystem. Here is an
>> example of minimal set:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=linus&id=1e2ac9821de6a85d3e8358f238436708d1d46869
>>
>> The above has no passive action. It is just gonna shutdown the system if
>> temperature crosses a threshold.
>>
>> But, a typical cooling device would be CPU frequency throttling. Do you
>> have
>> that up and running in your routers?
>
>
> I don't have CPU freq throttling, so shutdown will be the only solution for
> critical temp right now.
>
> I know I should have at least a trip for critical temperature, but the
> problem
> is I don't know what value to use. There isn't any info about this in public
> datasheets. Broadcom's SDK doesn't mention it. Vendors share only the max
> environment temp, not the max CPU temp.
>
> So for now I only meant to provide user space access to reading current CPU
> temperature. I could do some stress tests and ask other users to do it as
> well.
>
> Or maybe I could just put in Documentation some round value that makes more
> or
> less sense and then work on a proper content of real DTS files?
>
> Unless we can get some hint from Broadcom people. Jon? Florian? Anyone?
I'll poke around and see if I can find a datasheet for NS/NSP. Worst
case, I can ask one of the HW engineers for NSP, and we can use the
same value for NS.
^ permalink raw reply
* [PATCH v35 13/14] Documentation: dt: chosen properties for arm64 kdump
From: AKASHI Takahiro @ 2017-04-03 2:26 UTC (permalink / raw)
To: catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: james.morse-5wv7dgnIgG8, geoff-wEGCiKHe2LqWVfeAwA7xHQ,
bauerman-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
dyoung-H+wXaHxf7aLQT0dZR+AlfA,
ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A,
panand-H+wXaHxf7aLQT0dZR+AlfA, sgoel-sgV2jX0FEOL9JmXXK+q4OQ,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, AKASHI Takahiro
In-Reply-To: <20170403022139.12383-1-takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
From: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
Add documentation for DT properties:
linux,usable-memory-range
linux,elfcorehdr
used by arm64 kdump. Those are, respectively, a usable memory range
allocated to crash dump kernel and the elfcorehdr's location within it.
Signed-off-by: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
[takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org: update the text due to recent changes ]
Signed-off-by: AKASHI Takahiro <takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/chosen.txt | 45 ++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
index 6ae9d82d4c37..b5e39af4ddc0 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -52,3 +52,48 @@ This property is set (currently only on PowerPC, and only needed on
book3e) by some versions of kexec-tools to tell the new kernel that it
is being booted by kexec, as the booting environment may differ (e.g.
a different secondary CPU release mechanism)
+
+linux,usable-memory-range
+-------------------------
+
+This property (arm64 only) holds a base address and size, describing a
+limited region in which memory may be considered available for use by
+the kernel. Memory outside of this range is not available for use.
+
+This property describes a limitation: memory within this range is only
+valid when also described through another mechanism that the kernel
+would otherwise use to determine available memory (e.g. memory nodes
+or the EFI memory map). Valid memory may be sparse within the range.
+e.g.
+
+/ {
+ chosen {
+ linux,usable-memory-range = <0x9 0xf0000000 0x0 0x10000000>;
+ };
+};
+
+The main usage is for crash dump kernel to identify its own usable
+memory and exclude, at its boot time, any other memory areas that are
+part of the panicked kernel's memory.
+
+While this property does not represent a real hardware, the address
+and the size are expressed in #address-cells and #size-cells,
+respectively, of the root node.
+
+linux,elfcorehdr
+----------------
+
+This property (currently used only on arm64) holds the memory range,
+the address and the size, of the elf core header which mainly describes
+the panicked kernel's memory layout as PT_LOAD segments of elf format.
+e.g.
+
+/ {
+ chosen {
+ linux,elfcorehdr = <0x9 0xfffff000 0x0 0x800>;
+ };
+};
+
+While this property does not represent a real hardware, the address
+and the size are expressed in #address-cells and #size-cells,
+respectively, of the root node.
--
2.11.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
* Re: [PATCH net-next v3 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch
From: kbuild test robot @ 2017-04-03 1:16 UTC (permalink / raw)
Cc: kbuild-all, andrew, f.fainelli, vivien.didelot, matthias.bgg,
robh+dt, mark.rutland, devicetree, netdev, linux-kernel,
linux-mediatek, davem, sean.wang, Landen.Chao, keyhaede, objelf
In-Reply-To: <1490780303-18598-6-git-send-email-sean.wang@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 7184 bytes --]
Hi Sean,
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/net-next-dsa-add-Mediatek-MT7530-support/20170330-135532
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
In file included from net/dsa/tag_mtk.c:16:0:
net/dsa/dsa_priv.h:50:30: warning: 'struct dsa_switch' declared inside parameter list will not be visible outside of this definition or declaration
int dsa_cpu_dsa_setup(struct dsa_switch *ds, struct device *dev,
^~~~~~~~~~
net/dsa/dsa_priv.h:54:39: warning: 'struct dsa_switch' declared inside parameter list will not be visible outside of this definition or declaration
int dsa_cpu_port_ethtool_setup(struct dsa_switch *ds);
^~~~~~~~~~
net/dsa/dsa_priv.h:55:42: warning: 'struct dsa_switch' declared inside parameter list will not be visible outside of this definition or declaration
void dsa_cpu_port_ethtool_restore(struct dsa_switch *ds);
^~~~~~~~~~
net/dsa/dsa_priv.h:59:36: warning: 'struct dsa_switch' declared inside parameter list will not be visible outside of this definition or declaration
void dsa_slave_mii_bus_init(struct dsa_switch *ds);
^~~~~~~~~~
net/dsa/dsa_priv.h:61:29: warning: 'struct dsa_switch' declared inside parameter list will not be visible outside of this definition or declaration
int dsa_slave_create(struct dsa_switch *ds, struct device *parent,
^~~~~~~~~~
net/dsa/dsa_priv.h:70:41: warning: 'struct dsa_switch' declared inside parameter list will not be visible outside of this definition or declaration
int dsa_switch_register_notifier(struct dsa_switch *ds);
^~~~~~~~~~
net/dsa/dsa_priv.h:71:44: warning: 'struct dsa_switch' declared inside parameter list will not be visible outside of this definition or declaration
void dsa_switch_unregister_notifier(struct dsa_switch *ds);
^~~~~~~~~~
net/dsa/tag_mtk.c: In function 'mtk_tag_xmit':
>> net/dsa/tag_mtk.c:38:26: error: dereferencing pointer to incomplete type 'struct dsa_port'
mtk_tag[1] = (1 << p->dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
^~
net/dsa/tag_mtk.c: In function 'mtk_tag_rcv':
>> net/dsa/tag_mtk.c:85:10: error: dereferencing pointer to incomplete type 'struct dsa_switch_tree'
ds = dst->ds[0];
^~
>> net/dsa/tag_mtk.c:91:9: error: dereferencing pointer to incomplete type 'struct dsa_switch'
if (!ds->ports[port].netdev)
^~
vim +91 net/dsa/tag_mtk.c
2faad9d7 Sean Wang 2017-03-29 32
2faad9d7 Sean Wang 2017-03-29 33 memmove(skb->data, skb->data + MTK_HDR_LEN, 2 * ETH_ALEN);
2faad9d7 Sean Wang 2017-03-29 34
2faad9d7 Sean Wang 2017-03-29 35 /* Build the tag after the MAC Source Address */
2faad9d7 Sean Wang 2017-03-29 36 mtk_tag = skb->data + 2 * ETH_ALEN;
2faad9d7 Sean Wang 2017-03-29 37 mtk_tag[0] = 0;
2faad9d7 Sean Wang 2017-03-29 @38 mtk_tag[1] = (1 << p->dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
2faad9d7 Sean Wang 2017-03-29 39 mtk_tag[2] = 0;
2faad9d7 Sean Wang 2017-03-29 40 mtk_tag[3] = 0;
2faad9d7 Sean Wang 2017-03-29 41
2faad9d7 Sean Wang 2017-03-29 42 return skb;
2faad9d7 Sean Wang 2017-03-29 43
2faad9d7 Sean Wang 2017-03-29 44 out_free:
2faad9d7 Sean Wang 2017-03-29 45 kfree_skb(skb);
2faad9d7 Sean Wang 2017-03-29 46 return NULL;
2faad9d7 Sean Wang 2017-03-29 47 }
2faad9d7 Sean Wang 2017-03-29 48
2faad9d7 Sean Wang 2017-03-29 49 static int mtk_tag_rcv(struct sk_buff *skb, struct net_device *dev,
2faad9d7 Sean Wang 2017-03-29 50 struct packet_type *pt, struct net_device *orig_dev)
2faad9d7 Sean Wang 2017-03-29 51 {
2faad9d7 Sean Wang 2017-03-29 52 struct dsa_switch_tree *dst = dev->dsa_ptr;
2faad9d7 Sean Wang 2017-03-29 53 struct dsa_switch *ds;
2faad9d7 Sean Wang 2017-03-29 54 int port;
2faad9d7 Sean Wang 2017-03-29 55 __be16 *phdr, hdr;
2faad9d7 Sean Wang 2017-03-29 56
2faad9d7 Sean Wang 2017-03-29 57 if (unlikely(!dst))
2faad9d7 Sean Wang 2017-03-29 58 goto out_drop;
2faad9d7 Sean Wang 2017-03-29 59
2faad9d7 Sean Wang 2017-03-29 60 skb = skb_unshare(skb, GFP_ATOMIC);
2faad9d7 Sean Wang 2017-03-29 61 if (!skb)
2faad9d7 Sean Wang 2017-03-29 62 goto out;
2faad9d7 Sean Wang 2017-03-29 63
2faad9d7 Sean Wang 2017-03-29 64 if (unlikely(!pskb_may_pull(skb, MTK_HDR_LEN)))
2faad9d7 Sean Wang 2017-03-29 65 goto out_drop;
2faad9d7 Sean Wang 2017-03-29 66
2faad9d7 Sean Wang 2017-03-29 67 /* The MTK header is added by the switch between src addr
2faad9d7 Sean Wang 2017-03-29 68 * and ethertype at this point, skb->data points to 2 bytes
2faad9d7 Sean Wang 2017-03-29 69 * after src addr so header should be 2 bytes right before.
2faad9d7 Sean Wang 2017-03-29 70 */
2faad9d7 Sean Wang 2017-03-29 71 phdr = (__be16 *)(skb->data - 2);
2faad9d7 Sean Wang 2017-03-29 72 hdr = ntohs(*phdr);
2faad9d7 Sean Wang 2017-03-29 73
2faad9d7 Sean Wang 2017-03-29 74 /* Remove MTK tag and recalculate checksum. */
2faad9d7 Sean Wang 2017-03-29 75 skb_pull_rcsum(skb, MTK_HDR_LEN);
2faad9d7 Sean Wang 2017-03-29 76
2faad9d7 Sean Wang 2017-03-29 77 memmove(skb->data - ETH_HLEN,
2faad9d7 Sean Wang 2017-03-29 78 skb->data - ETH_HLEN - MTK_HDR_LEN,
2faad9d7 Sean Wang 2017-03-29 79 2 * ETH_ALEN);
2faad9d7 Sean Wang 2017-03-29 80
2faad9d7 Sean Wang 2017-03-29 81 /* This protocol doesn't support cascading multiple
2faad9d7 Sean Wang 2017-03-29 82 * switches so it's safe to assume the switch is first
2faad9d7 Sean Wang 2017-03-29 83 * in the tree.
2faad9d7 Sean Wang 2017-03-29 84 */
2faad9d7 Sean Wang 2017-03-29 @85 ds = dst->ds[0];
2faad9d7 Sean Wang 2017-03-29 86 if (!ds)
2faad9d7 Sean Wang 2017-03-29 87 goto out_drop;
2faad9d7 Sean Wang 2017-03-29 88
2faad9d7 Sean Wang 2017-03-29 89 /* Get source port information */
2faad9d7 Sean Wang 2017-03-29 90 port = (hdr & MTK_HDR_RECV_SOURCE_PORT_MASK);
2faad9d7 Sean Wang 2017-03-29 @91 if (!ds->ports[port].netdev)
2faad9d7 Sean Wang 2017-03-29 92 goto out_drop;
2faad9d7 Sean Wang 2017-03-29 93
2faad9d7 Sean Wang 2017-03-29 94 /* Update skb & forward the frame accordingly */
:::::: The code at line 91 was first introduced by commit
:::::: 2faad9d71e4c0544e3cf43b24439517c95df301f net-next: dsa: add Mediatek tag RX/TX handler
:::::: TO: Sean Wang <sean.wang@mediatek.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61384 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: hi6220: enable DMA in spi0
From: kbuild test robot @ 2017-04-02 22:31 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wang Xiaoyin, Antonio Borneo,
Zhong Kaihua, Guodong Xu
In-Reply-To: <20170321070818.3247-1-guodong.xu-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
Hi Wang,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.11-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Guodong-Xu/arm64-dts-hi6220-enable-DMA-in-spi0/20170323-100144
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> ERROR: Input tree has errors, aborting (use -f to force output)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33980 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: BCM5301X: Specify MDIO bus in the DT
From: Rafał Miłecki @ 2017-04-02 21:25 UTC (permalink / raw)
To: Florian Fainelli, Rafał Miłecki
Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5a6ecda9-2cf6-2171-7210-6b3a1d4c6012-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 04/02/2017 11:14 PM, Florian Fainelli wrote:
> Le 04/02/17 à 14:08, Rafał Miłecki a écrit :
>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>
>> Northstar devices have MDIO bus that may contain various PHYs attached.
>> A common example is USB 3.0 PHY (that doesn't have an MDIO driver yet).
>>
>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>> ---
>> arch/arm/boot/dts/bcm5301x.dtsi | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
>> index acee36a61004..6a2afe7880ae 100644
>> --- a/arch/arm/boot/dts/bcm5301x.dtsi
>> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
>> @@ -320,6 +320,13 @@
>> };
>> };
>>
>> + mdio@18003000 {
>> + compatible = "brcm,iproc-mdio";
>> + reg = <0x18003000 0x8>;
>> + #size-cells = <1>;
>> + #address-cells = <0>;
>> + };
>
> This looks fine, but usually the block should be enabled on a per-board
> basis, such that there should be a status = "disabled" property here by
> default.
I think we have few blocks in bcm5301x.dtsi enabled by default. I guess it's
for stuff that is always present on every SoC family board: rng, nand, spi to
name few.
It makes some sense, consider e.g. spi. Every Northstar board has SPI
controller so it's enabled by default. Not every board has SPI flash, so it's
disabled by default.
It's there and it make sense to me. Is that OK or not?
I find MDIO situation quite simiar. It seems every Northstar board has MDIO bus
just devices may differ and should not be enabled by default.
--
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