Devicetree
 help / color / mirror / Atom feed
* [PATCH v7 2/9] of_graph: add of_graph_get_remote_endpoint()
From: Kuninori Morimoto @ 2017-04-20  1:31 UTC (permalink / raw)
  To: Mark Brown, Rob Herring; +Cc: Linux-ALSA, Simon, Linux-DT
In-Reply-To: <87fuh3oon8.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>
---
v6 -> v7

 - 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 d9adaa9..1ae2510 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2457,6 +2457,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
  *
@@ -2470,7 +2484,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--) {
@@ -2494,7 +2508,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

* [PATCH v7 1/9] of-graph: export symbol of_phandle_iterator_init/next
From: Kuninori Morimoto @ 2017-04-20  1:31 UTC (permalink / raw)
  To: Mark Brown, Rob Herring; +Cc: Linux-ALSA, Simon, Linux-DT
In-Reply-To: <87fuh3oon8.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>


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

of_for_each_phandle() uses of_phandle_iterator_init/next
but it isn'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 solved this issue

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
v6 -> v7

 - no change

 drivers/of/base.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index d7c4629..d9adaa9 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

--
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 v7 0/9] ASoC: add OF-graph base simple-card
From: Kuninori Morimoto @ 2017-04-20  1:30 UTC (permalink / raw)
  To: Mark Brown, Rob Herring; +Cc: Linux-ALSA, Simon, Linux-DT


Hi Mark, Rob

These are v7 of OF-graph sound card support.
Main change from v6 "label" doesn't allow [prefix]label (in [6/9])

1) - 4) : OF-graph base functions
5) - 9) : OF-graph + simple-card (= audio_graph_card)

Kuninori Morimoto (9):
  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: soc-core: enable "dai-format" on snd_soc_of_parse_daifmt()
  ASoC: simple-card-utils: enable "label" on asoc_simple_card_parse_card_name
  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                                  |  62 ++++-
 include/linux/of_graph.h                           |  21 ++
 include/sound/simple_card_utils.h                  |  10 +
 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              |  73 ++++-
 sound/soc/soc-core.c                               |  10 +-
 9 files changed, 600 insertions(+), 18 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 2/2] mmc: dw_mmc-rockchip: parse rockchip,default-num-phases from DT
From: Shawn Lin @ 2017-04-20  1:21 UTC (permalink / raw)
  To: Doug Anderson
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ulf Hansson,
	Ziyuan Xu, linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jaehoon Chung, open list:ARM/Rockchip SoC..., Rob Herring
In-Reply-To: <CAD=FV=X6PRe1u+s4Nnt=9gJD2T4=YyLdMWnKe5rZg2KgWGNAvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Doug,

在 2017/4/20 4:19, Doug Anderson 写道:
> Hi,
>
> On Wed, Apr 19, 2017 at 2:00 AM, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>> Currently we unconditionally do tuning for each degree, which
>> costs 900ms for each boot and resume.
>>
>> May someone argue that this is a question of accuracy VS time. But I
>> would say it's a trick of how we need to do decision for our boards.
>> If we don't care the time we spend at all, we could definitely do tuning
>> for each degree. But when we need to improve the user experience, for
>> instance, speed up resuming from S3, we should also have the right to
>> do that. This patch add parsing "rockchip,default-num-phases", for folks
>> to specify the number of doing tuning. If not specified, 360 will be used
>> as before.
>>
>> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>>
>> ---
>>
>>  drivers/mmc/host/dw_mmc-rockchip.c | 48 ++++++++++++++++++++++++--------------
>>  1 file changed, 30 insertions(+), 18 deletions(-)
>
> No huge objection here, but I do remember we ended up at the 360
> phases due to some of the craziness with dw_mmc delay elements on
> rk3288.  IIRC one of the big problems was that the delay elements
> changed _a lot_ with the "LOGIC" voltage and we tweaked the voltage at
> runtime for DDR DVFS.  That imposed an extra need to be very accurate
> on that SoC, at least on any board that was designed to support DDR
> DVFS.
>

Not just with the vdd_logic but also with the process of Soc.
To better guaratee the accuracy, firstly we use delay element to do
tuning and then convert it to be combination of degree + delay element.
But as the dalay elements aren't accuracy themself, so all the math we
do here is trick.

> I also remember there being some weirdness on the Rockchip
> implementation where there was a certain set of phases that the MMC
> controller was essentially "blind".  This blind spot was in the middle
> of an otherwise good range of points.  Unfortunately this blind spot
> was somewhat hard to detect properly because it was not very big.
> ...the variability of the delay elements meant that there could be big
> ranges where we weren't getting any good test coverage, but also the
> fact that they changed with the LOGIC voltage might mean that we
> weren't in the "blind" spot and then suddenly we were.

I undertand all of these as I was suffering from it when bringing up
RK3288.

>
> One other note is that i remember that the vast majority of time spent
> tuning was dealing with "bad" phases, not dealing with "good" phases.
> If you're looking to speed things up, maybe finding a way to make
> "bad" phases fail faster would be wise?  I think one of the reasons
> bad phases failed so slowly is because the dw_mmc timeouts are all so
> long.

Good point. I haven't thought of speeding up the handle of bad phases,
but I will take a look at this.

>
> Oh, and I guess one last note is that I have no idea if folks will
> like the device bindings here.  Part of me thinks it should be
> something more "symbolic" like "rockchip,need-accurate-tuning" or
> something like that.  I guess I'd let the DT experts chime in.
>
>
> So I guess to summarize:
> * On rk3288 boards w/ DDR DVFS (or any other similar boards), 360
> seems to provide real benefit.
> * On other boards, probably you can get by with fewer phases.
>

I would try to say it's a question of "900ms for a single time" VS.
"some of discrete tuning cost for more chance to do retune".

(1)We could try to do a more accurate tuning process and spends 900ms.
Then we have less chance to do retune later.

(2)We do a rough tuning and have more chance to do retune later.

I also would say that this is a game , and we can't say which
one is better. Obvious now the "900ms" alwyas happens in the spot
routine, for instance, booting and resuming from S3.

>
> -Doug
>
>
>


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

^ permalink raw reply

* Re: [PATCH v3 00/21] eeprom: at24: Add OF device ID table
From: Rob Herring @ 2017-04-20  0:12 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: Mark Rutland, Andrew Lunn, Wolfram Sang, Tony Lindgren,
	Catalin Marinas, Will Deacon, linux-kernel, Masahiro Yamada,
	Alexandre Belloni, linux-i2c, Hongtao Jia, Russell King,
	Mark Jackson, Herbert Xu, Horia Geantă, Michael Ellerman,
	Magnus Damm, Michal Simek, Andy Shevchenko, linux-arm-kernel,
	Benjamin Herrenschmidt, Jason Cooper
In-Reply-To: <20170414010445.21727-1-javier@osg.samsung.com>

On Thu, Apr 13, 2017 at 10:04:24PM -0300, Javier Martinez Canillas wrote:
> Hello Wolfram,
> 
> This series is a follow-up to patch [0] that added an OF device ID table
> to the at24 EEPROM driver. As you suggested [1], this version instead of
> adding entries for every used <vendor,device> tuple, only adds a single
> entry for each chip type using the "atmel" vendor as a generic fallback.
> 
> The first patch adds the OF device ID table for the at24 driver and the
> next patches adds a generic fallback compatible string to each DTS that
> defines a compatible I2C EEPROM device node.
> 
> Patches can be applied independently since the DTS change without the
> driver change is a no-op and the OF device table won't be used without
> the DTS changes.
> 
> [0]: https://lkml.org/lkml/2017/3/14/589

I don't have this patch in my inbox, but the i2c core will still match 
on compatibles with no vendor prefix? If not, those need to be added to 
the match table too.

Rob

^ permalink raw reply

* Re: [PATCH v6 6/9] ASoC: simple-card-utils: enable "label" on asoc_simple_card_parse_card_name
From: Kuninori Morimoto @ 2017-04-19 23:59 UTC (permalink / raw)
  To: Rob Herring; +Cc: Mark Brown, Linux-ALSA, Simon, Linux-DT
In-Reply-To: <CAL_JsqKEuV38kGreCm4z4aEFVRjPaBhqRbELk9W2x1UL4KpMOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>


Hi Rob

> >  int asoc_simple_card_parse_card_name(struct snd_soc_card *card,
> >                                      char *prefix)
> >  {
> > +       char * const names[] = {
> > +               "label", "name"
> > +       };
> >         char prop[128];
> > +       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;
> > +       }
> 
> This is still wrong as you are allowing "<prefix>label" for property
> names. I think you want something like this:
> 
> ret = snd_soc_of_parse_card_name(card, "label");
> if (ret < 0) {
>   char prop[128];
>   snprintf(prop, sizeof(prop), "%sname", prefix);
>   /* Parse the card name from DT */
>   ret = snd_soc_of_parse_card_name(card, prop);
>   if (ret < 0)
>     return ret;
> }

OK, will fix

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

^ permalink raw reply

* Re: [PATCH v3 03/21] ARM: dts: omap: Add generic compatible string for I2C EEPROM
From: Rob Herring @ 2017-04-19 23:56 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Benoît Cousson, devicetree-u79uwXL29TY76Z2rM5mHXA,
	Tony Lindgren, Mark Rutland, linux-omap-u79uwXL29TY76Z2rM5mHXA,
	Russell King, Mark Jackson
In-Reply-To: <20170414010445.21727-4-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>

On Thu, Apr 13, 2017 at 10:04:27PM -0300, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
> 
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
> 
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
> 
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/boot/dts/am335x-baltos.dtsi            |  2 +-
>  arch/arm/boot/dts/am335x-base0033.dts           |  2 +-
>  arch/arm/boot/dts/am335x-bone-common.dtsi       | 10 +++++-----
>  arch/arm/boot/dts/am335x-nano.dts               |  2 +-
>  arch/arm/boot/dts/am335x-pepper.dts             |  2 +-
>  arch/arm/boot/dts/am335x-shc.dts                |  2 +-
>  arch/arm/boot/dts/am335x-sl50.dts               |  2 +-
>  arch/arm/boot/dts/am437x-idk-evm.dts            |  2 +-
>  arch/arm/boot/dts/am437x-sk-evm.dts             |  2 +-
>  arch/arm/boot/dts/am43x-epos-evm.dts            |  2 +-
>  arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi |  2 +-
>  arch/arm/boot/dts/omap3-cm-t3x.dtsi             |  2 +-
>  arch/arm/boot/dts/omap3-gta04.dtsi              |  2 +-
>  arch/arm/boot/dts/omap3-sb-t35.dtsi             |  2 +-
>  arch/arm/boot/dts/omap4-var-som-om44.dtsi       |  2 +-
>  arch/arm/boot/dts/omap5-cm-t54.dts              |  2 +-
>  arch/arm/boot/dts/omap5-sbc-t54.dts             |  2 +-
>  17 files changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
> index d42b98f15e8b..6ca780d0623f 100644
> --- a/arch/arm/boot/dts/am335x-baltos.dtsi
> +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
> @@ -255,7 +255,7 @@
>  	};
>  
>  	at24@50 {
> -		compatible = "at24,24c02";
> +		compatible = "at24,24c02", "atmel,24c02";

I think you can just drop the at24 compatibles. A new kernel doesn't 
need it. An old kernel ignores the manufacturer. I checked that u-boot 
only matches on "atmel,*", so okay there. Don't know about the *BSDs. I 
couldn't find anything.

Minimally, the deprecated compatible should come last.

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

^ permalink raw reply

* Re: [PATCH v4 04/18] dt-bindings: syscon: Add DT bindings documentation for Allwinner syscon
From: André Przywara @ 2017-04-19 23:38 UTC (permalink / raw)
  To: Corentin Labbe, robh+dt, mark.rutland, maxime.ripard, wens, linux,
	catalin.marinas, will.deacon, peppe.cavallaro, alexandre.torgue
  Cc: devicetree, netdev, linux-kernel, linux-sunxi, linux-arm-kernel
In-Reply-To: <20170412111400.2296-5-clabbe.montjoie@gmail.com>

On 12/04/17 12:13, Corentin Labbe wrote:
> This patch adds documentation for Device-Tree bindings for the
> syscon present in allwinner devices.
> 
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> ---
>  .../devicetree/bindings/misc/allwinner,syscon.txt     | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/allwinner,syscon.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/allwinner,syscon.txt b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
> new file mode 100644
> index 0000000..c056c5b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/allwinner,syscon.txt
> @@ -0,0 +1,19 @@
> +* Allwinner sun8i system controller
> +
> +This file describes the bindings for the system controller present in
> +Allwinner SoC H3, A83T and A64.
> +The principal function of this syscon is to control EMAC PHY choice and
> +config.
> +
> +Required properties for the system controller:
> +- reg: address and length of the register for the device.
> +- compatible: should be "syscon" and one of the following string:
> +		"allwinner,sun8i-h3-system-controller"
> +		"allwinner,sun8i-a64-system-controller"

While sun8i might make some sense technically, all 64-bit sunxi
compatible strings use the sun50i prefix to follow the Allwinner naming.
So this should read:
		"allwinner,sun50i-a64-system-controller"

Also I am wondering if we should add a compatible string for the H5
(support for that SoC is in -next already):
		"allwinner,sun50i-h5-system-controller"

Cheers,
Andre.

> +		"allwinner,sun8i-a83t-system-controller"
> +
> +Example:
> +syscon: syscon@01c00000 {
> +	compatible = "allwinner,sun8i-h3-system-controller", "syscon";
> +	reg = <0x01c00000 0x1000>;
> +};
> 

^ permalink raw reply

* Re: [PATCH v3 01/21] dt-bindings: i2c: eeprom: Document manufacturer used as generic fallback
From: Rob Herring @ 2017-04-19 23:35 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Wolfram Sang, Simon Horman,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sekhar Nori,
	David Lechner, Alexandre Belloni, Mark Rutland
In-Reply-To: <20170419232759.mw6g6fwy4xvjaopv@rob-hp-laptop>

On Wed, Apr 19, 2017 at 6:27 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Apr 13, 2017 at 10:04:25PM -0300, Javier Martinez Canillas wrote:
>> The at24 driver allows to register I2C EEPROM chips using different vendor
>> and devices, but the I2C subsystem does not take the vendor into account
>> when matching using the I2C table since it only has device entries.
>>
>> But when matching using an OF table, both the vendor and device has to be
>> taken into account so the driver defines only a set of compatible strings
>> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>>
>> Document in the Device Tree binding document that this manufacturer should
>> be used as the generic fallback.
>>
>> Suggested-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
>> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
>>
>> ---
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>>  Documentation/devicetree/bindings/eeprom/eeprom.txt | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> index 5696eb508e95..d0395f14e2b3 100644
>> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> @@ -17,7 +17,8 @@ Required properties:
>>       "renesas,r1ex24002"
>>
>>        If there is no specific driver for <manufacturer>, a generic
>> -      driver based on <type> is selected. Possible types are:
>> +      driver based on <type> and manufacturer "atmel" is selected.
>> +      Possible types are:
>
> This isn't quite right. What the driver does isn't really relevant to
> the binding.
>
> These types with no vendor are used as the compatible string, so we have
> to allow them. But it should be clear that no vendor is deprecated.
> Ironically, it is a lot of Atmel boards that do this.
>
> We should also explicitly list what are valid manufacturers. We also
> have "at" as a vendor prefix which perhaps we should explicitly say is
> deprecated.

I should perhaps look at the rest of the series before replying..

Based on that, the only comment that applies is listing the
manufacturers that are valid. From a DT perspective, I should not have
to know what the OS driver supports. If the device is compatible with
atmel, then that is required. If not, then the specific manufacturer's
compatible alone is enough and the OS has to match to that.

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

^ permalink raw reply

* Re: [PATCH v3 01/21] dt-bindings: i2c: eeprom: Document manufacturer used as generic fallback
From: Rob Herring @ 2017-04-19 23:27 UTC (permalink / raw)
  To: Javier Martinez Canillas
  Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Simon Horman,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Sekhar Nori, David Lechner,
	Alexandre Belloni, Mark Rutland
In-Reply-To: <20170414010445.21727-2-javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>

On Thu, Apr 13, 2017 at 10:04:25PM -0300, Javier Martinez Canillas wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
> 
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
> 
> Document in the Device Tree binding document that this manufacturer should
> be used as the generic fallback.
> 
> Suggested-by: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
> Signed-off-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> 
> ---
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/eeprom/eeprom.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> index 5696eb508e95..d0395f14e2b3 100644
> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -17,7 +17,8 @@ Required properties:
>  	"renesas,r1ex24002"
>  
>  	 If there is no specific driver for <manufacturer>, a generic
> -	 driver based on <type> is selected. Possible types are:
> +	 driver based on <type> and manufacturer "atmel" is selected.
> +	 Possible types are:

This isn't quite right. What the driver does isn't really relevant to 
the binding.

These types with no vendor are used as the compatible string, so we have 
to allow them. But it should be clear that no vendor is deprecated. 
Ironically, it is a lot of Atmel boards that do this. 

We should also explicitly list what are valid manufacturers. We also 
have "at" as a vendor prefix which perhaps we should explicitly say is 
deprecated.

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

^ permalink raw reply

* Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
From: Tyrel Datwyler @ 2017-04-19 23:27 UTC (permalink / raw)
  To: Michael Ellerman, Frank Rowand, Tyrel Datwyler,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A
  Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	nfont-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
	rostedt-nx8X9YLhiw1AfugRpC6u6w, mingo-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <87efwp6v4e.fsf-W0DJWXSxmBNbyGPkN3NxC2scP1bn1w/D@public.gmane.org>

On 04/18/2017 06:31 PM, Michael Ellerman wrote:
> Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
>> On 04/17/17 17:32, Tyrel Datwyler wrote:
>>> This patch introduces event tracepoints for tracking a device_nodes
>>> reference cycle as well as reconfig notifications generated in response
>>> to node/property manipulations.
>>>
>>> With the recent upstreaming of the refcount API several device_node
>>> underflows and leaks have come to my attention in the pseries (DLPAR) dynamic
>>> logical partitioning code (ie. POWER speak for hotplugging virtual and physcial
>>> resources at runtime such as cpus or IOAs). These tracepoints provide a
>>> easy and quick mechanism for validating the reference counting of
>>> device_nodes during their lifetime.
>>>
>>> Further, when pseries lpars are migrated to a different machine we
>>> perform a live update of our device tree to bring it into alignment with the
>>> configuration of the new machine. The of_reconfig_notify trace point
>>> provides a mechanism that can be turned for debuging the device tree
>>> modifications with out having to build a custom kernel to get at the
>>> DEBUG code introduced by commit 00aa3720.
>>
>> I do not like changing individual (or small groups of) printk() style
>> debugging information to tracepoint style.
> 
> I'm not quite sure which printks() you're referring to.
> 
> The only printks that are removed in this series are under #ifdef DEBUG,
> and so are essentially not there unless you build a custom kernel.
> 
> They also only cover the reconfig case, which is actually less
> interesting than the much more common and bug-prone get/put logic.
> 
>> As far as I know, there is no easy way to combine trace data and printk()
>> style data to create a single chronology of events.  If some of the
>> information needed to debug an issue is trace data and some is printk()
>> style data then it becomes more difficult to understand the overall
>> situation.
> 
> If you enable CONFIG_PRINTK_TIME then you should be able to just sort
> the trace and the printk output by the timestamp. If you're really
> trying to correlate the two then you should probably just be using
> trace_printk().
> 
> But IMO this level of detail, tracing every get/put, does not belong in
> printk. Trace points are absolutely the right solution for this type of
> debugging.

Something else to keep in mind is that while pr_debugs could be used to
provide feedback on the reference counts and of_reconfig events they
don't in anyway tell us where they are happening in the kernel. The
trace infrastructure provides the ability to stack trace those events.
The following example provides me a lot more information about who is
doing what and where after I hot-add an ethernet adapter:

# echo stacktrace > /sys/kernel/debug/tracing/trace_options
# cat trace | grep -A6 "/pci@800000020000018"
...
           drmgr-7349  [006] d...  7138.821875: of_node_get: refcount=8,
dn->full_name=/pci@800000020000018
           drmgr-7349  [006] d...  7138.821876: <stack trace>
 => .msi_quota_for_device
 => .rtas_setup_msi_irqs
 => .arch_setup_msi_irqs
 => .__pci_enable_msix
 => .pci_enable_msix_range
--
           drmgr-7349  [006] d...  7138.821876: of_node_put: refcount=2,
dn->full_name=/pci@800000020000018/ethernet@0
           drmgr-7349  [006] d...  7138.821877: <stack trace>
 => .msi_quota_for_device
 => .rtas_setup_msi_irqs
 => .arch_setup_msi_irqs
 => .__pci_enable_msix
 => .pci_enable_msix_range
--
           drmgr-7349  [006] ....  7138.821878: of_node_put: refcount=7,
dn->full_name=/pci@800000020000018
           drmgr-7349  [006] ....  7138.821879: <stack trace>
 => .rtas_setup_msi_irqs
 => .arch_setup_msi_irqs
 => .__pci_enable_msix
 => .pci_enable_msix_range
 => .bnx2x_enable_msix
--

To get that same info as far as I know is to add a dump_stack() after
each pr_debug.

Further, filters can be set on the tracepoint event fields such that
trace data could be restricted to a particular device_node or refcount
threshold. For example:

# cd /sys/kernel/debug/tracing# cat events/of/of_node_get/format
# echo "dn_name == /pci@800000020000018" > events/of/filter

# cat trace
           drmgr-10542 [003] ....  9630.677001: of_node_put: refcount=5,
dn->full_name=/pci@800000020000018
           drmgr-10542 [003] d...  9631.677368: of_node_get: refcount=6,
dn->full_name=/pci@800000020000018
           drmgr-10542 [003] ....  9631.677389: of_node_put: refcount=5,
dn->full_name=/pci@800000020000018
           drmgr-10542 [003] ....  9631.677390: of_reconfig_notify:
action=DETACH_NODE, dn->full_name=/pci@800000020000018, prop->name=null,
old_prop->name=null
           drmgr-10542 [003] .n..  9632.025656: of_node_put: refcount=4,
dn->full_name=/pci@800000020000018
           drmgr-10542 [003] .n..  9632.025657: of_node_put: refcount=3,
dn->full_name=/pci@800000020000018

After setting the filter and doing a hot-remove of the pci device in
question the trace quickly tells me 3 references are being leaked. In
combination with the stacktrace option I can quickly correlate call
sites that take references without releasing them.

-Tyrel

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

--
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] pinctrl: sh-pfc: r8a7794: add R8A7745 support
From: Rob Herring @ 2017-04-19 22:46 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: Mark Rutland, Laurent Pinchart, Geert Uytterhoeven, Linus Walleij,
	devicetree, linux-renesas-soc, linux-gpio
In-Reply-To: <20170413201932.890107963@cogentembedded.com>

On Thu, Apr 13, 2017 at 11:19:24PM +0300, Sergei Shtylyov wrote:
> Renesas  RZ/G1E (R8A7745) is pin compatible with R-Car E2 (R8A7794),
> however  it doesn't have several automotive specific peripherals.

Is a single space between words really so hard for you? You've been told 
to write proper sentences multiple times.

Yes, kernel developers suffer from OCD. Sorry.

> Annotate all the items that only exist on the R-Car SoCs and only
> supply the pin groups/functions existing on a given SoC (that required
> splitting  of the AVB function)...
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> ---
> This patch is  against the 'devel' branch of Linus Walleij's 'linux-pinctrl.git'
> repo plus  R8A7794 PFC fix and R8A7743 PFC support patch...
> 
> Changes in version 2:
> - fixed indentation to use tabs instead of spaces;
> - updated the PFC bindings.
> 
>  Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt |    1 

But given it's a one line DT change:

Acked-by: Rob Herring <robh@kernel.org>

>  drivers/pinctrl/sh-pfc/Kconfig                                    |    5 
>  drivers/pinctrl/sh-pfc/Makefile                                   |    1 
>  drivers/pinctrl/sh-pfc/core.c                                     |    6 
>  drivers/pinctrl/sh-pfc/pfc-r8a7794.c                              | 1970 +++++-----
>  drivers/pinctrl/sh-pfc/sh_pfc.h                                   |    1 
>  6 files changed, 1140 insertions(+), 844 deletions(-)

^ permalink raw reply

* Re: [PATCH v3] pinctrl: sh-pfc: r8a7791: add R8A7743 support
From: Rob Herring @ 2017-04-19 22:36 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: Mark Rutland, Laurent Pinchart, Geert Uytterhoeven, Linus Walleij,
	devicetree, linux-renesas-soc, linux-gpio
In-Reply-To: <20170413201346.358012116@cogentembedded.com>

On Thu, Apr 13, 2017 at 11:13:32PM +0300, Sergei Shtylyov wrote:
> Renesas RZ/G1M (R8A7743) is pin compatible with R-Car M2-W/N (R8A7791/3),
> however it doesn't have several automotive specific peripherals. Annotate
> all the items that only exist on the R-Car SoCs and only supply  the pin
> groups/functions existing on a given SoC...
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> 
> ---
> This patch is against the 'devel' branch of Linus Walleij's 'linux-pinctrl.git'
> repo plus  4  R8A7791 PFC fixes and the "grand I2C rename" patch...
> 
> Changes in version 3:
> - updated the PFC bindings.
> 
> Changes in version 2:
> - switch to supplying exactly the groups/functions existing on a given SoC,
>   update the patch descriptions accordingly;
> - resolved rejects due to the "grand I2C rename" patch being updated.
> 
>  Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt |    1 

Acked-by: Rob Herring <robh@kernel.org>

>  drivers/pinctrl/sh-pfc/Kconfig                                    |    5 
>  drivers/pinctrl/sh-pfc/Makefile                                   |    1 
>  drivers/pinctrl/sh-pfc/core.c                                     |    6 
>  drivers/pinctrl/sh-pfc/pfc-r8a7791.c                              | 1889 +++++-----
>  drivers/pinctrl/sh-pfc/sh_pfc.h                                   |    1 
>  6 files changed, 1023 insertions(+), 880 deletions(-)

^ permalink raw reply

* Re: [PATCH v4 1/2] dt-bindings: Document the STM32 QSPI bindings
From: Rob Herring @ 2017-04-19 22:35 UTC (permalink / raw)
  To: Ludovic Barre
  Cc: Cyrille Pitchen, Marek Vasut, David Woodhouse, Brian Norris,
	Boris Brezillon, Richard Weinberger, Alexandre Torgue,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1492103757-22375-2-git-send-email-ludovic.Barre-qxv4g6HH51o@public.gmane.org>

On Thu, Apr 13, 2017 at 07:15:56PM +0200, Ludovic Barre wrote:
> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> 
> This patch adds documentation of device tree bindings for the STM32
> QSPI controller.
> 
> Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> ---
>  .../devicetree/bindings/mtd/stm32-quadspi.txt      | 43 ++++++++++++++++++++++
>  1 file changed, 43 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/stm32-quadspi.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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] ASoC: cs35l35: Allow user to configure IMON SCALE
From: Rob Herring @ 2017-04-19 22:32 UTC (permalink / raw)
  To: Charles Keepax
  Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
	mark.rutland-5wv7dgnIgG8, brian.austin-jGc1dHjMKG3QT0dZR+AlfA,
	Paul.Handrigan-jGc1dHjMKG3QT0dZR+AlfA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
	patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E
In-Reply-To: <1492098729-30491-1-git-send-email-ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>

On Thu, Apr 13, 2017 at 04:52:09PM +0100, Charles Keepax wrote:
> On the chip the IMON signal is a full 24-bits however normally only
> some of the bits will be sent over the bus. The chip provides a field
> to select which bits of the IMON will be sent back, this is the only
> feedback signal that has this feature.
> 
> Add an additional entry to the cirrus,imon device tree property to
> allow the IMON scale parameter to be passed.
> 
> Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> ---
> 
> I realise this is changing the binding slightly, but thought
> we might be able to sneak it before cs35l35 ships as it hasn't
> shipped in a kernel yet.  However, it would be relatively simple
> (although makes the code a little messier) to support both the 3
> and 4 entry versions of the binding if people prefer?

Given it is new, I'm okay with the change if you are.

> 
> Thanks,
> Charles
> 
>  .../devicetree/bindings/sound/cs35l35.txt          |  4 ++--

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

>  include/sound/cs35l35.h                            |  1 +
>  sound/soc/codecs/cs35l35.c                         | 22 +++++++++++++++-------
>  sound/soc/codecs/cs35l35.h                         |  3 +++
>  4 files changed, 21 insertions(+), 9 deletions(-)
--
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 1/2] dt-bindings: add mmio-based syscon mux controller DT bindings
From: Rob Herring @ 2017-04-19 22:09 UTC (permalink / raw)
  To: Philipp Zabel
  Cc: Peter Rosin, Mark Rutland, Sakari Ailus, Steve Longerbeam,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <20170413154812.19597-1-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

On Thu, Apr 13, 2017 at 05:48:11PM +0200, Philipp Zabel wrote:
> This adds device tree binding documentation for mmio-based syscon
> multiplexers controlled by a single bitfield in a syscon register
> range.
> 
> Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/mux/mmio-mux.txt | 56 ++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mux/mmio-mux.txt
> 
> diff --git a/Documentation/devicetree/bindings/mux/mmio-mux.txt b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> new file mode 100644
> index 0000000000000..11d96f5d98583
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mux/mmio-mux.txt
> @@ -0,0 +1,56 @@
> +MMIO bitfield-based multiplexer controller bindings
> +
> +Define a syscon bitfield to be used to control a multiplexer. The parent
> +device tree node must be a syscon node to provide register access.
> +
> +Required properties:
> +- compatible : "gpio-mux"

?

> +- reg : register base of the register containing the control bitfield
> +- bit-mask : bitmask of the control bitfield in the control register
> +- bit-shift : bit offset of the control bitfield in the control register
> +- #mux-control-cells : <0>
> +* Standard mux-controller bindings as decribed in mux-controller.txt
> +
> +Optional properties:
> +- idle-state : if present, the state the mux will have when idle. The
> +	       special state MUX_IDLE_AS_IS is the default.
> +
> +The multiplexer state is defined as the value of the bitfield described
> +by the reg, bit-mask, and bit-shift properties, accessed through the parent
> +syscon.
> +
> +Example:
> +
> +	syscon {
> +		compatible = "syscon";
> +
> +		mux: mux-controller@3 {
> +			compatible = "mmio-mux";
> +			reg = <0x3>;
> +			bit-mask = <0x1>;
> +			bit-shift = <5>;

This pattern doesn't scale once you have multiple fields @ addr 3. I 
also don't really think a node per register field in DT really scales.

I think the parent should be declared as a mux controller instead. You 
could encode the mux addr and bit position in the mux cells.

> +			#mux-control-cells = <0>;
> +		};
> +	};
> +
> +	video-mux {
> +		compatible = "video-mux";
> +		mux-controls = <&mux>;

The mux binding was largely defined for a single control controling 
multiple muxes. This doesn't really fit that, but I guess this is an 
improvement over a custom syscon phandle.

> +
> +		ports {
> +			/* input 0 */
> +			port@0 {
> +				reg = <0>;
> +			};
> +
> +			/* input 1 */
> +			port@1 {
> +				reg = <1>;
> +			};
> +
> +			/* output */
> +			port@2 {
> +				reg = <2>;
> +			};
> +		};
> +	};
> -- 
> 2.11.0
> 
--
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] PM / OPP: Use - instead of @ for DT entries
From: Rafael J. Wysocki @ 2017-04-19 22:06 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Viresh Kumar, arm, Chanwoo Choi, MyungJoo Ham, Kyungmin Park,
	Kukjin Kim, Krzysztof Kozlowski, Javier Martinez Canillas,
	Viresh Kumar, Nishanth Menon, Stephen Boyd, Beno??t Cousson,
	Tony Lindgren, Rob Herring, Mark Rutland, Daniel Mack,
	Haojian Zhuang, Robert Jarzmik, Maxime Ripard, Chen-Yu Tsai,
	Masahiro
In-Reply-To: <20170419142215.GA12105@localhost>

On Wednesday, April 19, 2017 07:22:15 AM Olof Johansson wrote:
> Hi Viresh,
> 
> On Tue, Apr 18, 2017 at 10:44:50AM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> > 
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> > unit name, but no reg property
> > 
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> > 
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> (sunxi)
> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> (uniphier)
> > Acked-by: Rob Herring <robh@kernel.org>
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> We've already turned down other patches that does this in a sweeping manner
> like this, since they tend to be conflict prone with other DT changes.
> 
> Please split per platform and merge with each maintainer.

OK

So I'm assuming that you guys will take care of this going forward.

Thanks,
Rafael

^ permalink raw reply

* Re: [PATCH 2/4] net: macb: Add tsu_clk to device tree
From: Rob Herring @ 2017-04-19 21:57 UTC (permalink / raw)
  To: Rafal Ozieblo
  Cc: David Miller, nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	harinikatakamlinux-Re5JQEeQqe8AvxtiuMwx3w,
	harini.katakam-gjFFaj9aHVfQT0dZR+AlfA,
	richardcochran-Re5JQEeQqe8AvxtiuMwx3w,
	Andrei.Pistirica-UWL1GkI3JZL3oGB3hsPCZA
In-Reply-To: <1492090686-14778-1-git-send-email-rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>

On Thu, Apr 13, 2017 at 02:38:06PM +0100, Rafal Ozieblo wrote:
> Signed-off-by: Rafal Ozieblo <rafalo-vna1KIf7WgpBDgjK7y7TUQ@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/net/macb.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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 3/4] doc,dts - add XRA1403 DTS binding documentation
From: Rob Herring @ 2017-04-19 21:55 UTC (permalink / raw)
  To: Nandor Han
  Cc: gregkh, davem, geert, mchehab, daniel.vetter, linus.walleij,
	gnurou, mark.rutland, linux-gpio, devicetree, linux-kernel
In-Reply-To: <0d970c6a929597804eae3577ed24f57ee23b820a.1492077070.git.nandor.han@ge.com>

On Thu, Apr 13, 2017 at 01:27:50PM +0300, Nandor Han wrote:
> Add the XRA1403 DTS binding documentation.

"dt-bindings: gpio: ..." for the subject.

> 
> Signed-off-by: Nandor Han <nandor.han@ge.com>
> ---
>  .../devicetree/bindings/gpio/gpio-xra1403.txt      | 46 ++++++++++++++++++++++
>  1 file changed, 46 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-xra1403.txt

Otherwise,

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* [PATCH V2] ARM: dts: BCM5301X: Specify MDIO bus in the DT
From: Rafał Miłecki @ 2017-04-19 21:54 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Hauke Mehrtens, Rob Herring, Mark Rutland, Russell King,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170402210840.11429-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

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>
---
V2: Disable MDIO bus by default.
    Add mdio label to allow enabling it easily per board
---
 arch/arm/boot/dts/bcm5301x.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index acee36a61004..1f34bc6905f2 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -320,6 +320,14 @@
 		};
 	};
 
+	mdio: mdio@18003000 {
+		compatible = "brcm,iproc-mdio";
+		reg = <0x18003000 0x8>;
+		#size-cells = <1>;
+		#address-cells = <0>;
+		status = "disabled";
+	};
+
 	i2c0: i2c@18009000 {
 		compatible = "brcm,iproc-i2c";
 		reg = <0x18009000 0x50>;
-- 
2.11.0

--
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 v2 1/4] dt-bindings: gpio - add exar to vendor prefixes list
From: Rob Herring @ 2017-04-19 21:48 UTC (permalink / raw)
  To: Nandor Han
  Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q, geert-Td1EMuHUCqxL1ZNQvxDV9g,
	mchehab-DgEjT+Ai2ygdnm+yROfE0A, daniel.vetter-/w4YWyX8dFk,
	linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
	gnurou-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
	linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f02af49f4d72326c455c9137ffb2714e7236cbab.1492077070.git.nandor.han-JJi787mZWgc@public.gmane.org>

On Thu, Apr 13, 2017 at 01:27:48PM +0300, Nandor Han wrote:
> Add Exar Corporation to vendors list.

This patch has nothing to do with gpio, so that should be dropped from 
the subject.

> 
> Signed-off-by: Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +

Otherwise,

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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 1/3] dt-bindings: mt8173: Fix mdp device tree
From: Rob Herring @ 2017-04-19 21:35 UTC (permalink / raw)
  To: Minghsiu Tsai
  Cc: Hans Verkuil, daniel.thompson-QSEj5FYQhm4dnm+yROfE0A,
	Mauro Carvalho Chehab, Matthias Brugger, Daniel Kurtz,
	Pawel Osciak, Houlong Wei, srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
	Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-media-u79uwXL29TY76Z2rM5mHXA,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1492068787-17838-2-git-send-email-minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> If the mdp_* nodes are under an mdp sub-node, their corresponding
> platform device does not automatically get its iommu assigned properly.
> 
> Fix this by moving the mdp component nodes up a level such that they are
> siblings of mdp and all other SoC subsystems.  This also simplifies the
> device tree.

It may simplify the DT, but it also breaks compatibility with old DT. 
Not sure if that's a problem on Mediatek platforms, but please be 
explicit here that you are breaking compatibility and why that is okay.

> 
> Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

Should this have Daniel as the author?

> 
> ---
>  Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++---------
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> index 4182063..0d03e3a 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> @@ -2,7 +2,7 @@
>  
>  Media Data Path is used for scaling and color space conversion.
>  
> -Required properties (controller (parent) node):
> +Required properties (controller node):
>  - compatible: "mediatek,mt8173-mdp"
>  - mediatek,vpu: the node of video processor unit, see
>    Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
>    for details.
>  
>  Example:
> -mdp {
> -	compatible = "mediatek,mt8173-mdp";
> -	#address-cells = <2>;
> -	#size-cells = <2>;
> -	ranges;
> -	mediatek,vpu = <&vpu>;
> -
>  	mdp_rdma0: rdma@14001000 {
>  		compatible = "mediatek,mt8173-mdp-rdma";
> +			     "mediatek,mt8173-mdp";
>  		reg = <0 0x14001000 0 0x1000>;
>  		clocks = <&mmsys CLK_MM_MDP_RDMA0>,
>  			 <&mmsys CLK_MM_MUTEX_32K>;
>  		power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
>  		iommus = <&iommu M4U_PORT_MDP_RDMA0>;
>  		mediatek,larb = <&larb0>;
> +		mediatek,vpu = <&vpu>;
>  	};
>  
>  	mdp_rdma1: rdma@14002000 {
> @@ -106,4 +101,3 @@ mdp {
>  		iommus = <&iommu M4U_PORT_MDP_WROT1>;
>  		mediatek,larb = <&larb4>;
>  	};
> -};
> -- 
> 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 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings
From: Rob Herring @ 2017-04-19 21:23 UTC (permalink / raw)
  To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
  Cc: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
	mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ, mark.rutland-5wv7dgnIgG8,
	clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
	prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w,
	romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
	shannon.nelson-QHcLZuEGTsvQT0dZR+AlfA,
	weiyongjun1-hv44wF8Li93QT0dZR+AlfA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-crypto-u79uwXL29TY76Z2rM5mHXA,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1492067108-14748-2-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

On Thu, Apr 13, 2017 at 03:05:07PM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> 
> Document the devicetree bindings for Mediatek random number
> generator which could be found on MT7623 SoC or other similar
> Mediatek SoCs.
> 
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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 2/2] drm/panel: simple: add support for NLT NL192108AC18-02D
From: Rob Herring @ 2017-04-19 21:15 UTC (permalink / raw)
  To: Lucas Stach; +Cc: Mark Rutland, devicetree, dri-devel, patchwork-lst, kernel
In-Reply-To: <20170412171526.32393-2-l.stach@pengutronix.de>

On Wed, Apr 12, 2017 at 07:15:26PM +0200, Lucas Stach wrote:
> This adds support for the NLT Technologies NL192108AC18-02D
> 15.6" LVDS FullHD TFT LCD panel, which can be supported
> by the simple panel driver.
> 
> Timings are taken from the preliminary datasheet, as a final
> one is not yet available.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
>  .../display/panel/nlt,nl192108ac18-02d.txt         |  7 ++++++
>  drivers/gpu/drm/panel/panel-simple.c               | 29 ++++++++++++++++++++++
>  2 files changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt b/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> new file mode 100644
> index 000000000000..edc34fbd2131
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/nlt,nl192108ac18-02d.txt
> @@ -0,0 +1,7 @@
> +NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "nlt,nl192108ac18-02d"

Please define the power supply. Is power-supply used or are there 
multiple supplies?

> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: add vendor prefix for NLT Technologies, Ltd.
From: Rob Herring @ 2017-04-19 21:14 UTC (permalink / raw)
  To: Lucas Stach; +Cc: Mark Rutland, devicetree, dri-devel, patchwork-lst, kernel
In-Reply-To: <20170412171526.32393-1-l.stach@pengutronix.de>

On Wed, Apr 12, 2017 at 07:15:25PM +0200, Lucas Stach wrote:
> NLT technologies is the former NEC display business, but changed its
> name to NLT Technologies when forming a joint venture with
> Shenzhen AVIC OPTOELECTRONICS, Ltd.
> 
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox