[PATCH 1/3] dt-bindings: add power domains to Tegra BPMP firmware

[PATCH 1/3] dt-bindings: add power domains to Tegra BPMP firmware

[Stephen Warren]

From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

The Tegra186 BPMP is also a provider of power domains. Enhance the device
tree binding to describe this.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
These patches all build on top of Joseph Lo's baseline BPMP binding patches[1]
and enhance them to represent a few more features of the firmware.

[1] https://lkml.org/lkml/2016/7/19/280
"[PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox"

 .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 10 ++++--
 include/dt-bindings/power/tegra186-powergate.h     | 39 ++++++++++++++++++++++
 2 files changed, 46 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/power/tegra186-powergate.h

diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
index 23782c84d093..9a3864f56955 100644
--- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
+++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
@@ -17,6 +17,7 @@ Required properties:
 - shmem : List of the phandle of the TX and RX shared memory area that
 	  the IPC between CPU and BPMP is based on.
 - #clock-cells : Should be 1.
+- #power-domain-cells : Should be 1.
 - #reset-cells : Should be 1.
 
 This node is a mailbox consumer. See the following files for details of
@@ -26,12 +27,14 @@ provider(s):
 - .../mailbox/mailbox.txt
 - .../mailbox/nvidia,tegra186-hsp.txt
 
-This node is a clock and reset provider. See the following files for
-general documentation of those features, and the specifiers implemented
-by this node:
+This node is a clock, power domain, and reset provider. See the following
+files for general documentation of those features, and the specifiers
+implemented by this node:
 
 - .../clock/clock-bindings.txt
 - <dt-bindings/clock/tegra186-clock.h>
+- ../power/power_domain.txt
+- <dt-bindings/power/tegra186-powergate.h>
 - .../reset/reset.txt
 - <dt-bindings/reset/tegra186-reset.h>
 
@@ -73,5 +76,6 @@ bpmp {
 	mboxes = <&hsp_top0 HSP_MBOX_TYPE_DB HSP_DB_MASTER_BPMP>;
 	shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
 	#clock-cells = <1>;
+	#power-domain-cells = <1>;
 	#reset-cells = <1>;
 };
diff --git a/include/dt-bindings/power/tegra186-powergate.h b/include/dt-bindings/power/tegra186-powergate.h
new file mode 100644
index 000000000000..388d6e228dc8
--- /dev/null
+++ b/include/dt-bindings/power/tegra186-powergate.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2015-2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
+#define _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
+
+#define TEGRA186_POWER_DOMAIN_AUD	0
+#define TEGRA186_POWER_DOMAIN_DFD	1
+#define TEGRA186_POWER_DOMAIN_DISP	2
+#define TEGRA186_POWER_DOMAIN_DISPB	3
+#define TEGRA186_POWER_DOMAIN_DISPC	4
+#define TEGRA186_POWER_DOMAIN_ISPA	5
+#define TEGRA186_POWER_DOMAIN_NVDEC	6
+#define TEGRA186_POWER_DOMAIN_NVJPG	7
+#define TEGRA186_POWER_DOMAIN_MPE	8
+#define TEGRA186_POWER_DOMAIN_PCX	9
+#define TEGRA186_POWER_DOMAIN_SAX	10
+#define TEGRA186_POWER_DOMAIN_VE	11
+#define TEGRA186_POWER_DOMAIN_VIC	12
+#define TEGRA186_POWER_DOMAIN_XUSBA	13
+#define TEGRA186_POWER_DOMAIN_XUSBB	14
+#define TEGRA186_POWER_DOMAIN_XUSBC	15
+#define TEGRA186_POWER_DOMAIN_GPU	43
+#define TEGRA186_POWER_DOMAIN_MAX	44
+
+#endif
-- 
2.9.2

[PATCH 1/3] dt-bindings: add power domains to Tegra BPMP firmware

[Stephen Warren]

From: Stephen Warren <swarren@nvidia.com>

The Tegra186 BPMP is also a provider of power domains. Enhance the device
tree binding to describe this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
These patches all build on top of Joseph Lo's baseline BPMP binding patches[1]
and enhance them to represent a few more features of the firmware.

[1] https://lkml.org/lkml/2016/7/19/280
"[PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox"

 .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 10 ++++--
 include/dt-bindings/power/tegra186-powergate.h     | 39 ++++++++++++++++++++++
 2 files changed, 46 insertions(+), 3 deletions(-)
 create mode 100644 include/dt-bindings/power/tegra186-powergate.h

diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
index 23782c84d093..9a3864f56955 100644
--- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
+++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
@@ -17,6 +17,7 @@ Required properties:
 - shmem : List of the phandle of the TX and RX shared memory area that
 	  the IPC between CPU and BPMP is based on.
 - #clock-cells : Should be 1.
+- #power-domain-cells : Should be 1.
 - #reset-cells : Should be 1.
 
 This node is a mailbox consumer. See the following files for details of
@@ -26,12 +27,14 @@ provider(s):
 - .../mailbox/mailbox.txt
 - .../mailbox/nvidia,tegra186-hsp.txt
 
-This node is a clock and reset provider. See the following files for
-general documentation of those features, and the specifiers implemented
-by this node:
+This node is a clock, power domain, and reset provider. See the following
+files for general documentation of those features, and the specifiers
+implemented by this node:
 
 - .../clock/clock-bindings.txt
 - <dt-bindings/clock/tegra186-clock.h>
+- ../power/power_domain.txt
+- <dt-bindings/power/tegra186-powergate.h>
 - .../reset/reset.txt
 - <dt-bindings/reset/tegra186-reset.h>
 
@@ -73,5 +76,6 @@ bpmp {
 	mboxes = <&hsp_top0 HSP_MBOX_TYPE_DB HSP_DB_MASTER_BPMP>;
 	shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
 	#clock-cells = <1>;
+	#power-domain-cells = <1>;
 	#reset-cells = <1>;
 };
diff --git a/include/dt-bindings/power/tegra186-powergate.h b/include/dt-bindings/power/tegra186-powergate.h
new file mode 100644
index 000000000000..388d6e228dc8
--- /dev/null
+++ b/include/dt-bindings/power/tegra186-powergate.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2015-2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
+#define _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
+
+#define TEGRA186_POWER_DOMAIN_AUD	0
+#define TEGRA186_POWER_DOMAIN_DFD	1
+#define TEGRA186_POWER_DOMAIN_DISP	2
+#define TEGRA186_POWER_DOMAIN_DISPB	3
+#define TEGRA186_POWER_DOMAIN_DISPC	4
+#define TEGRA186_POWER_DOMAIN_ISPA	5
+#define TEGRA186_POWER_DOMAIN_NVDEC	6
+#define TEGRA186_POWER_DOMAIN_NVJPG	7
+#define TEGRA186_POWER_DOMAIN_MPE	8
+#define TEGRA186_POWER_DOMAIN_PCX	9
+#define TEGRA186_POWER_DOMAIN_SAX	10
+#define TEGRA186_POWER_DOMAIN_VE	11
+#define TEGRA186_POWER_DOMAIN_VIC	12
+#define TEGRA186_POWER_DOMAIN_XUSBA	13
+#define TEGRA186_POWER_DOMAIN_XUSBB	14
+#define TEGRA186_POWER_DOMAIN_XUSBC	15
+#define TEGRA186_POWER_DOMAIN_GPU	43
+#define TEGRA186_POWER_DOMAIN_MAX	44
+
+#endif
-- 
2.9.2

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

The BPMP implements some services which must be represented by separate
nodes. For example, it can provide access to certain I2C controllers, and
the I2C bindings represent each I2C controller as a device tree node.
Update the binding to describe how the BPMP supports this.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
index 9a3864f56955..142d363406f6 100644
--- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
+++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
@@ -38,6 +38,24 @@ implemented by this node:
 - .../reset/reset.txt
 - <dt-bindings/reset/tegra186-reset.h>
 
+The BPMP implements some services which must be represented by separate nodes.
+For example, it can provide access to certain I2C controllers, and the I2C
+bindings represent each I2C controller as a device tree node. Such nodes should
+be nested directly inside the main BPMP node.
+
+Software can determine whether a child node of the BPMP node represents a device
+by checking for a compatible property. Any node with a compatible property
+represents a device that can be instantiated. Nodes without a compatible
+property may be used to provide configuration information regarding the BPMP
+itself, although no such configuration nodes are currently defined by this
+binding.
+
+The BPMP firmware defines no single global name-/numbering-space for such
+services. Put another way, the numbering scheme for I2C buses is distinct from
+the numbering scheme for any other service the BPMP may provide (e.g. a future
+hypothetical SPI bus service). As such, child device nodes will have no reg
+property, and the BPMP node will have no #address-cells or #size-cells property.
+
 The shared memory bindings for BPMP
 -----------------------------------
 
@@ -78,4 +96,9 @@ bpmp {
 	#clock-cells = <1>;
 	#power-domain-cells = <1>;
 	#reset-cells = <1>;
+
+	bpmp-i2c {
+		compatible = "...";
+		...
+	};
 };
-- 
2.9.2

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

From: Stephen Warren <swarren@nvidia.com>

The BPMP implements some services which must be represented by separate
nodes. For example, it can provide access to certain I2C controllers, and
the I2C bindings represent each I2C controller as a device tree node.
Update the binding to describe how the BPMP supports this.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
index 9a3864f56955..142d363406f6 100644
--- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
+++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
@@ -38,6 +38,24 @@ implemented by this node:
 - .../reset/reset.txt
 - <dt-bindings/reset/tegra186-reset.h>
 
+The BPMP implements some services which must be represented by separate nodes.
+For example, it can provide access to certain I2C controllers, and the I2C
+bindings represent each I2C controller as a device tree node. Such nodes should
+be nested directly inside the main BPMP node.
+
+Software can determine whether a child node of the BPMP node represents a device
+by checking for a compatible property. Any node with a compatible property
+represents a device that can be instantiated. Nodes without a compatible
+property may be used to provide configuration information regarding the BPMP
+itself, although no such configuration nodes are currently defined by this
+binding.
+
+The BPMP firmware defines no single global name-/numbering-space for such
+services. Put another way, the numbering scheme for I2C buses is distinct from
+the numbering scheme for any other service the BPMP may provide (e.g. a future
+hypothetical SPI bus service). As such, child device nodes will have no reg
+property, and the BPMP node will have no #address-cells or #size-cells property.
+
 The shared memory bindings for BPMP
 -----------------------------------
 
@@ -78,4 +96,9 @@ bpmp {
 	#clock-cells = <1>;
 	#power-domain-cells = <1>;
 	#reset-cells = <1>;
+
+	bpmp-i2c {
+		compatible = "...";
+		...
+	};
 };
-- 
2.9.2

[PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Stephen Warren]

From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
HW devices, such as the I2C controller for the power management I2C bus.
Software running on other CPUs must perform IPC to the BPMP in order to
execute transactions on that I2C bus. This binding describes an I2C bus
that is accessed in such a fashion.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt

diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
new file mode 100644
index 000000000000..fecb549bc250
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
@@ -0,0 +1,42 @@
+NVIDIA Tegra186 BPMP I2C controller
+
+In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
+devices, such as the I2C controller for the power management I2C bus. Software
+running on other CPUs must perform IPC to the BPMP in order to execute
+transactions on that I2C bus. This binding describes an I2C bus that is
+accessed in such a fashion.
+
+The BPMP I2C node must be located directly inside the main BPMP node. See
+../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
+
+This node represents an I2C controller. See ../i2c/i2c.txt for details of the
+core I2C binding.
+
+Required properties:
+- compatible:
+    Array of strings.
+    One of:
+    - "nvidia,tegra186-bpmp-i2c".
+- #address-cells: Address cells for I2C device address.
+    Single-cell integer.
+    Must be <1>.
+- #size-cells:
+    Single-cell integer.
+    Must be <0>.
+- nvidia,bpmp-bus-id:
+    Single-cell integer.
+    Indicates the I2C bus number this DT node represent, as defined by the
+    BPMP firmware.
+
+Example:
+
+/ bpmp {
+	...
+
+	bpmp-i2c {
+		compatible = "nvidia,tegra186-bpmp-i2c";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		nvidia,bpmp-bus-id = <5>;
+	};
+};
-- 
2.9.2

[PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Stephen Warren]

From: Stephen Warren <swarren@nvidia.com>

In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
HW devices, such as the I2C controller for the power management I2C bus.
Software running on other CPUs must perform IPC to the BPMP in order to
execute transactions on that I2C bus. This binding describes an I2C bus
that is accessed in such a fashion.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt

diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
new file mode 100644
index 000000000000..fecb549bc250
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
@@ -0,0 +1,42 @@
+NVIDIA Tegra186 BPMP I2C controller
+
+In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
+devices, such as the I2C controller for the power management I2C bus. Software
+running on other CPUs must perform IPC to the BPMP in order to execute
+transactions on that I2C bus. This binding describes an I2C bus that is
+accessed in such a fashion.
+
+The BPMP I2C node must be located directly inside the main BPMP node. See
+../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
+
+This node represents an I2C controller. See ../i2c/i2c.txt for details of the
+core I2C binding.
+
+Required properties:
+- compatible:
+    Array of strings.
+    One of:
+    - "nvidia,tegra186-bpmp-i2c".
+- #address-cells: Address cells for I2C device address.
+    Single-cell integer.
+    Must be <1>.
+- #size-cells:
+    Single-cell integer.
+    Must be <0>.
+- nvidia,bpmp-bus-id:
+    Single-cell integer.
+    Indicates the I2C bus number this DT node represent, as defined by the
+    BPMP firmware.
+
+Example:
+
+/ bpmp {
+	...
+
+	bpmp-i2c {
+		compatible = "nvidia,tegra186-bpmp-i2c";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		nvidia,bpmp-bus-id = <5>;
+	};
+};
-- 
2.9.2

Re: [PATCH 1/3] dt-bindings: add power domains to Tegra BPMP firmware

[Rob Herring]

On Tue, Jul 19, 2016 at 01:14:40PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> The Tegra186 BPMP is also a provider of power domains. Enhance the device
> tree binding to describe this.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> These patches all build on top of Joseph Lo's baseline BPMP binding patches[1]
> and enhance them to represent a few more features of the firmware.
> 
> [1] https://lkml.org/lkml/2016/7/19/280
> "[PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox"
> 
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 10 ++++--
>  include/dt-bindings/power/tegra186-powergate.h     | 39 ++++++++++++++++++++++
>  2 files changed, 46 insertions(+), 3 deletions(-)
>  create mode 100644 include/dt-bindings/power/tegra186-powergate.h

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

[PATCH 1/3] dt-bindings: add power domains to Tegra BPMP firmware

[Rob Herring]

On Tue, Jul 19, 2016 at 01:14:40PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> The Tegra186 BPMP is also a provider of power domains. Enhance the device
> tree binding to describe this.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> These patches all build on top of Joseph Lo's baseline BPMP binding patches[1]
> and enhance them to represent a few more features of the firmware.
> 
> [1] https://lkml.org/lkml/2016/7/19/280
> "[PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox"
> 
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 10 ++++--
>  include/dt-bindings/power/tegra186-powergate.h     | 39 ++++++++++++++++++++++
>  2 files changed, 46 insertions(+), 3 deletions(-)
>  create mode 100644 include/dt-bindings/power/tegra186-powergate.h

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

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Rob Herring]

On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> The BPMP implements some services which must be represented by separate
> nodes. For example, it can provide access to certain I2C controllers, and
> the I2C bindings represent each I2C controller as a device tree node.
> Update the binding to describe how the BPMP supports this.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> index 9a3864f56955..142d363406f6 100644
> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> @@ -38,6 +38,24 @@ implemented by this node:
>  - .../reset/reset.txt
>  - <dt-bindings/reset/tegra186-reset.h>
>  
> +The BPMP implements some services which must be represented by separate nodes.
> +For example, it can provide access to certain I2C controllers, and the I2C
> +bindings represent each I2C controller as a device tree node. Such nodes should
> +be nested directly inside the main BPMP node.
> +
> +Software can determine whether a child node of the BPMP node represents a device
> +by checking for a compatible property. Any node with a compatible property
> +represents a device that can be instantiated. Nodes without a compatible
> +property may be used to provide configuration information regarding the BPMP
> +itself, although no such configuration nodes are currently defined by this
> +binding.
> +
> +The BPMP firmware defines no single global name-/numbering-space for such
> +services. Put another way, the numbering scheme for I2C buses is distinct from
> +the numbering scheme for any other service the BPMP may provide (e.g. a future
> +hypothetical SPI bus service). As such, child device nodes will have no reg
> +property, and the BPMP node will have no #address-cells or #size-cells property.
> +
>  The shared memory bindings for BPMP
>  -----------------------------------
>  
> @@ -78,4 +96,9 @@ bpmp {
>  	#clock-cells = <1>;
>  	#power-domain-cells = <1>;
>  	#reset-cells = <1>;
> +
> +	bpmp-i2c {

Just 'i2c' here. With that:

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

> +		compatible = "...";
> +		...
> +	};
>  };
> -- 
> 2.9.2
> 

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Rob Herring]

On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> The BPMP implements some services which must be represented by separate
> nodes. For example, it can provide access to certain I2C controllers, and
> the I2C bindings represent each I2C controller as a device tree node.
> Update the binding to describe how the BPMP supports this.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> index 9a3864f56955..142d363406f6 100644
> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> @@ -38,6 +38,24 @@ implemented by this node:
>  - .../reset/reset.txt
>  - <dt-bindings/reset/tegra186-reset.h>
>  
> +The BPMP implements some services which must be represented by separate nodes.
> +For example, it can provide access to certain I2C controllers, and the I2C
> +bindings represent each I2C controller as a device tree node. Such nodes should
> +be nested directly inside the main BPMP node.
> +
> +Software can determine whether a child node of the BPMP node represents a device
> +by checking for a compatible property. Any node with a compatible property
> +represents a device that can be instantiated. Nodes without a compatible
> +property may be used to provide configuration information regarding the BPMP
> +itself, although no such configuration nodes are currently defined by this
> +binding.
> +
> +The BPMP firmware defines no single global name-/numbering-space for such
> +services. Put another way, the numbering scheme for I2C buses is distinct from
> +the numbering scheme for any other service the BPMP may provide (e.g. a future
> +hypothetical SPI bus service). As such, child device nodes will have no reg
> +property, and the BPMP node will have no #address-cells or #size-cells property.
> +
>  The shared memory bindings for BPMP
>  -----------------------------------
>  
> @@ -78,4 +96,9 @@ bpmp {
>  	#clock-cells = <1>;
>  	#power-domain-cells = <1>;
>  	#reset-cells = <1>;
> +
> +	bpmp-i2c {

Just 'i2c' here. With that:

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

> +		compatible = "...";
> +		...
> +	};
>  };
> -- 
> 2.9.2
> 

Re: [PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Rob Herring]

On Tue, Jul 19, 2016 at 01:14:42PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
> HW devices, such as the I2C controller for the power management I2C bus.
> Software running on other CPUs must perform IPC to the BPMP in order to
> execute transactions on that I2C bus. This binding describes an I2C bus
> that is accessed in such a fashion.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt

Same node name comment, otherwise:

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

[PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Rob Herring]

On Tue, Jul 19, 2016 at 01:14:42PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
> HW devices, such as the I2C controller for the power management I2C bus.
> Software running on other CPUs must perform IPC to the BPMP in order to
> execute transactions on that I2C bus. This binding describes an I2C bus
> that is accessed in such a fashion.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
>  .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt

Same node name comment, otherwise:

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

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/20/2016 07:16 AM, Rob Herring wrote:
> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>
>> The BPMP implements some services which must be represented by separate
>> nodes. For example, it can provide access to certain I2C controllers, and
>> the I2C bindings represent each I2C controller as a device tree node.
>> Update the binding to describe how the BPMP supports this.
>>
>> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>>   .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>>   1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> index 9a3864f56955..142d363406f6 100644
>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> @@ -38,6 +38,24 @@ implemented by this node:
>>   - .../reset/reset.txt
>>   - <dt-bindings/reset/tegra186-reset.h>
>>
>> +The BPMP implements some services which must be represented by separate nodes.
>> +For example, it can provide access to certain I2C controllers, and the I2C
>> +bindings represent each I2C controller as a device tree node. Such nodes should
>> +be nested directly inside the main BPMP node.
>> +
>> +Software can determine whether a child node of the BPMP node represents a device
>> +by checking for a compatible property. Any node with a compatible property
>> +represents a device that can be instantiated. Nodes without a compatible
>> +property may be used to provide configuration information regarding the BPMP
>> +itself, although no such configuration nodes are currently defined by this
>> +binding.
>> +
>> +The BPMP firmware defines no single global name-/numbering-space for such
>> +services. Put another way, the numbering scheme for I2C buses is distinct from
>> +the numbering scheme for any other service the BPMP may provide (e.g. a future
>> +hypothetical SPI bus service). As such, child device nodes will have no reg
>> +property, and the BPMP node will have no #address-cells or #size-cells property.
>> +
>>   The shared memory bindings for BPMP
>>   -----------------------------------
>>
>> @@ -78,4 +96,9 @@ bpmp {
>>   	#clock-cells = <1>;
>>   	#power-domain-cells = <1>;
>>   	#reset-cells = <1>;
>> +
>> +	bpmp-i2c {
>
> Just 'i2c' here. With that:
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

What if we have multiple BPMP I2C buses? The node names need to be 
unique, and there's no concept of register number so we can't use a unit 
address to do that.

I guess we could go for plain "i2c" for now and defer the more general 
naming discussion until some later point if/when we actually instantiate 
multiple buses, but I would like to confirm we can solve the problem 
if/when that time comes.

(As an aside, "pwr-i2c" might be a better name for the current bus, when 
the time comes, since any/all I2C nodes inside the BPMP would be BPMP 
I2C buses).

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/20/2016 07:16 AM, Rob Herring wrote:
> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> The BPMP implements some services which must be represented by separate
>> nodes. For example, it can provide access to certain I2C controllers, and
>> the I2C bindings represent each I2C controller as a device tree node.
>> Update the binding to describe how the BPMP supports this.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> ---
>>   .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>>   1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> index 9a3864f56955..142d363406f6 100644
>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> @@ -38,6 +38,24 @@ implemented by this node:
>>   - .../reset/reset.txt
>>   - <dt-bindings/reset/tegra186-reset.h>
>>
>> +The BPMP implements some services which must be represented by separate nodes.
>> +For example, it can provide access to certain I2C controllers, and the I2C
>> +bindings represent each I2C controller as a device tree node. Such nodes should
>> +be nested directly inside the main BPMP node.
>> +
>> +Software can determine whether a child node of the BPMP node represents a device
>> +by checking for a compatible property. Any node with a compatible property
>> +represents a device that can be instantiated. Nodes without a compatible
>> +property may be used to provide configuration information regarding the BPMP
>> +itself, although no such configuration nodes are currently defined by this
>> +binding.
>> +
>> +The BPMP firmware defines no single global name-/numbering-space for such
>> +services. Put another way, the numbering scheme for I2C buses is distinct from
>> +the numbering scheme for any other service the BPMP may provide (e.g. a future
>> +hypothetical SPI bus service). As such, child device nodes will have no reg
>> +property, and the BPMP node will have no #address-cells or #size-cells property.
>> +
>>   The shared memory bindings for BPMP
>>   -----------------------------------
>>
>> @@ -78,4 +96,9 @@ bpmp {
>>   	#clock-cells = <1>;
>>   	#power-domain-cells = <1>;
>>   	#reset-cells = <1>;
>> +
>> +	bpmp-i2c {
>
> Just 'i2c' here. With that:
>
> Acked-by: Rob Herring <robh@kernel.org>

What if we have multiple BPMP I2C buses? The node names need to be 
unique, and there's no concept of register number so we can't use a unit 
address to do that.

I guess we could go for plain "i2c" for now and defer the more general 
naming discussion until some later point if/when we actually instantiate 
multiple buses, but I would like to confirm we can solve the problem 
if/when that time comes.

(As an aside, "pwr-i2c" might be a better name for the current bus, when 
the time comes, since any/all I2C nodes inside the BPMP would be BPMP 
I2C buses).

Re: [PATCH 1/3] dt-bindings: add power domains to Tegra BPMP firmware

[Jon Hunter]

On 19/07/16 20:14, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> The Tegra186 BPMP is also a provider of power domains. Enhance the device
> tree binding to describe this.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> These patches all build on top of Joseph Lo's baseline BPMP binding patches[1]
> and enhance them to represent a few more features of the firmware.
> 
> [1] https://lkml.org/lkml/2016/7/19/280
> "[PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox"
> 
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 10 ++++--
>  include/dt-bindings/power/tegra186-powergate.h     | 39 ++++++++++++++++++++++
>  2 files changed, 46 insertions(+), 3 deletions(-)
>  create mode 100644 include/dt-bindings/power/tegra186-powergate.h

Acked-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Jon

-- 
nvpublic

[PATCH 1/3] dt-bindings: add power domains to Tegra BPMP firmware

[Jon Hunter]

On 19/07/16 20:14, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> The Tegra186 BPMP is also a provider of power domains. Enhance the device
> tree binding to describe this.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> These patches all build on top of Joseph Lo's baseline BPMP binding patches[1]
> and enhance them to represent a few more features of the firmware.
> 
> [1] https://lkml.org/lkml/2016/7/19/280
> "[PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox"
> 
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 10 ++++--
>  include/dt-bindings/power/tegra186-powergate.h     | 39 ++++++++++++++++++++++
>  2 files changed, 46 insertions(+), 3 deletions(-)
>  create mode 100644 include/dt-bindings/power/tegra186-powergate.h

Acked-by: Jon Hunter <jonathanh@nvidia.com>

Jon

-- 
nvpublic

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Jon Hunter]

On 19/07/16 20:14, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> The BPMP implements some services which must be represented by separate
> nodes. For example, it can provide access to certain I2C controllers, and
> the I2C bindings represent each I2C controller as a device tree node.
> Update the binding to describe how the BPMP supports this.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)

Acked-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Jon

-- 
nvpublic

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Jon Hunter]

On 19/07/16 20:14, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> The BPMP implements some services which must be represented by separate
> nodes. For example, it can provide access to certain I2C controllers, and
> the I2C bindings represent each I2C controller as a device tree node.
> Update the binding to describe how the BPMP supports this.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)

Acked-by: Jon Hunter <jonathanh@nvidia.com>

Jon

-- 
nvpublic

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Thierry Reding]

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

On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> The BPMP implements some services which must be represented by separate
> nodes. For example, it can provide access to certain I2C controllers, and
> the I2C bindings represent each I2C controller as a device tree node.
> Update the binding to describe how the BPMP supports this.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> index 9a3864f56955..142d363406f6 100644
> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> @@ -38,6 +38,24 @@ implemented by this node:
>  - .../reset/reset.txt
>  - <dt-bindings/reset/tegra186-reset.h>
>  
> +The BPMP implements some services which must be represented by separate nodes.
> +For example, it can provide access to certain I2C controllers, and the I2C
> +bindings represent each I2C controller as a device tree node. Such nodes should
> +be nested directly inside the main BPMP node.
> +
> +Software can determine whether a child node of the BPMP node represents a device
> +by checking for a compatible property. Any node with a compatible property
> +represents a device that can be instantiated. Nodes without a compatible
> +property may be used to provide configuration information regarding the BPMP
> +itself, although no such configuration nodes are currently defined by this
> +binding.
> +
> +The BPMP firmware defines no single global name-/numbering-space for such
> +services. Put another way, the numbering scheme for I2C buses is distinct from
> +the numbering scheme for any other service the BPMP may provide (e.g. a future
> +hypothetical SPI bus service). As such, child device nodes will have no reg
> +property, and the BPMP node will have no #address-cells or #size-cells property.

My understanding is that the I2C bus number is passed as part of the
request to the BPMP firmware. Does that not count as addressing? Could
we not represent that generically using a device tree hierarchy? I'm
thinking something along these lines:

	bpmp {
		...

		services {
			i2c {
				i2c@0 {
					reg = <0>;
					...
				};

				i2c@1 {
					reg = <1>;
					...
				};

				...
			};

			spi {
				...
			};

			...
		};

		...
	};

Note that we could probably do without the "services" node, but this is
explicit in categorizing these as services exposed by the BPMP. We might
need the extra node to work around the issue that some child nodes of
the BPMP node don't have a reg property (configuration nodes), whereas
any of the services would have those. Although you could make the top-
level "i2c" and "spi" nodes take #address-cells and #size-cells
properties.

Thierry

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

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Thierry Reding]

On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> The BPMP implements some services which must be represented by separate
> nodes. For example, it can provide access to certain I2C controllers, and
> the I2C bindings represent each I2C controller as a device tree node.
> Update the binding to describe how the BPMP supports this.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> index 9a3864f56955..142d363406f6 100644
> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> @@ -38,6 +38,24 @@ implemented by this node:
>  - .../reset/reset.txt
>  - <dt-bindings/reset/tegra186-reset.h>
>  
> +The BPMP implements some services which must be represented by separate nodes.
> +For example, it can provide access to certain I2C controllers, and the I2C
> +bindings represent each I2C controller as a device tree node. Such nodes should
> +be nested directly inside the main BPMP node.
> +
> +Software can determine whether a child node of the BPMP node represents a device
> +by checking for a compatible property. Any node with a compatible property
> +represents a device that can be instantiated. Nodes without a compatible
> +property may be used to provide configuration information regarding the BPMP
> +itself, although no such configuration nodes are currently defined by this
> +binding.
> +
> +The BPMP firmware defines no single global name-/numbering-space for such
> +services. Put another way, the numbering scheme for I2C buses is distinct from
> +the numbering scheme for any other service the BPMP may provide (e.g. a future
> +hypothetical SPI bus service). As such, child device nodes will have no reg
> +property, and the BPMP node will have no #address-cells or #size-cells property.

My understanding is that the I2C bus number is passed as part of the
request to the BPMP firmware. Does that not count as addressing? Could
we not represent that generically using a device tree hierarchy? I'm
thinking something along these lines:

	bpmp {
		...

		services {
			i2c {
				i2c at 0 {
					reg = <0>;
					...
				};

				i2c at 1 {
					reg = <1>;
					...
				};

				...
			};

			spi {
				...
			};

			...
		};

		...
	};

Note that we could probably do without the "services" node, but this is
explicit in categorizing these as services exposed by the BPMP. We might
need the extra node to work around the issue that some child nodes of
the BPMP node don't have a reg property (configuration nodes), whereas
any of the services would have those. Although you could make the top-
level "i2c" and "spi" nodes take #address-cells and #size-cells
properties.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160726/a1f4f97b/attachment.sig>

Re: [PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Jon Hunter]

On 19/07/16 20:14, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
> HW devices, such as the I2C controller for the power management I2C bus.
> Software running on other CPUs must perform IPC to the BPMP in order to
> execute transactions on that I2C bus. This binding describes an I2C bus
> that is accessed in such a fashion.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
> 
> diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
> new file mode 100644
> index 000000000000..fecb549bc250
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
> @@ -0,0 +1,42 @@
> +NVIDIA Tegra186 BPMP I2C controller
> +
> +In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
> +devices, such as the I2C controller for the power management I2C bus. Software
> +running on other CPUs must perform IPC to the BPMP in order to execute
> +transactions on that I2C bus. This binding describes an I2C bus that is
> +accessed in such a fashion.
> +
> +The BPMP I2C node must be located directly inside the main BPMP node. See
> +../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
> +
> +This node represents an I2C controller. See ../i2c/i2c.txt for details of the
> +core I2C binding.
> +
> +Required properties:
> +- compatible:
> +    Array of strings.
> +    One of:
> +    - "nvidia,tegra186-bpmp-i2c".
> +- #address-cells: Address cells for I2C device address.
> +    Single-cell integer.
> +    Must be <1>.
> +- #size-cells:
> +    Single-cell integer.
> +    Must be <0>.
> +- nvidia,bpmp-bus-id:
> +    Single-cell integer.
> +    Indicates the I2C bus number this DT node represent, as defined by the
> +    BPMP firmware.
> +
> +Example:
> +
> +/ bpmp {

Is this "/" intentional?

> +	...
> +
> +	bpmp-i2c {
> +		compatible = "nvidia,tegra186-bpmp-i2c";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		nvidia,bpmp-bus-id = <5>;
> +	};
> +};
> 

Acked-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Jon

-- 
nvpublic

[PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Jon Hunter]

On 19/07/16 20:14, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
> HW devices, such as the I2C controller for the power management I2C bus.
> Software running on other CPUs must perform IPC to the BPMP in order to
> execute transactions on that I2C bus. This binding describes an I2C bus
> that is accessed in such a fashion.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
>  .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
> 
> diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
> new file mode 100644
> index 000000000000..fecb549bc250
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
> @@ -0,0 +1,42 @@
> +NVIDIA Tegra186 BPMP I2C controller
> +
> +In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
> +devices, such as the I2C controller for the power management I2C bus. Software
> +running on other CPUs must perform IPC to the BPMP in order to execute
> +transactions on that I2C bus. This binding describes an I2C bus that is
> +accessed in such a fashion.
> +
> +The BPMP I2C node must be located directly inside the main BPMP node. See
> +../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
> +
> +This node represents an I2C controller. See ../i2c/i2c.txt for details of the
> +core I2C binding.
> +
> +Required properties:
> +- compatible:
> +    Array of strings.
> +    One of:
> +    - "nvidia,tegra186-bpmp-i2c".
> +- #address-cells: Address cells for I2C device address.
> +    Single-cell integer.
> +    Must be <1>.
> +- #size-cells:
> +    Single-cell integer.
> +    Must be <0>.
> +- nvidia,bpmp-bus-id:
> +    Single-cell integer.
> +    Indicates the I2C bus number this DT node represent, as defined by the
> +    BPMP firmware.
> +
> +Example:
> +
> +/ bpmp {

Is this "/" intentional?

> +	...
> +
> +	bpmp-i2c {
> +		compatible = "nvidia,tegra186-bpmp-i2c";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		nvidia,bpmp-bus-id = <5>;
> +	};
> +};
> 

Acked-by: Jon Hunter <jonathanh@nvidia.com>

Jon

-- 
nvpublic

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/26/2016 04:03 AM, Thierry Reding wrote:
> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>
>> The BPMP implements some services which must be represented by separate
>> nodes. For example, it can provide access to certain I2C controllers, and
>> the I2C bindings represent each I2C controller as a device tree node.
>> Update the binding to describe how the BPMP supports this.
>>
>> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> index 9a3864f56955..142d363406f6 100644
>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> @@ -38,6 +38,24 @@ implemented by this node:
>>  - .../reset/reset.txt
>>  - <dt-bindings/reset/tegra186-reset.h>
>>
>> +The BPMP implements some services which must be represented by separate nodes.
>> +For example, it can provide access to certain I2C controllers, and the I2C
>> +bindings represent each I2C controller as a device tree node. Such nodes should
>> +be nested directly inside the main BPMP node.
>> +
>> +Software can determine whether a child node of the BPMP node represents a device
>> +by checking for a compatible property. Any node with a compatible property
>> +represents a device that can be instantiated. Nodes without a compatible
>> +property may be used to provide configuration information regarding the BPMP
>> +itself, although no such configuration nodes are currently defined by this
>> +binding.
>> +
>> +The BPMP firmware defines no single global name-/numbering-space for such
>> +services. Put another way, the numbering scheme for I2C buses is distinct from
>> +the numbering scheme for any other service the BPMP may provide (e.g. a future
>> +hypothetical SPI bus service). As such, child device nodes will have no reg
>> +property, and the BPMP node will have no #address-cells or #size-cells property.
>
> My understanding is that the I2C bus number is passed as part of the
> request to the BPMP firmware. Does that not count as addressing? Could
> we not represent that generically using a device tree hierarchy? I'm
> thinking something along these lines:
>
> 	bpmp {
> 		...
>
> 		services {
> 			i2c {
> 				i2c@0 {
> 					reg = <0>;

Technically, that is possible. However, Rob Herring rejected the idea of 
multiple levels of sub-nodes.

Can we please just go with what we have? DT bindings are frankly an 
obstacle to getting anything done:-(

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/26/2016 04:03 AM, Thierry Reding wrote:
> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> The BPMP implements some services which must be represented by separate
>> nodes. For example, it can provide access to certain I2C controllers, and
>> the I2C bindings represent each I2C controller as a device tree node.
>> Update the binding to describe how the BPMP supports this.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> ---
>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> index 9a3864f56955..142d363406f6 100644
>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>> @@ -38,6 +38,24 @@ implemented by this node:
>>  - .../reset/reset.txt
>>  - <dt-bindings/reset/tegra186-reset.h>
>>
>> +The BPMP implements some services which must be represented by separate nodes.
>> +For example, it can provide access to certain I2C controllers, and the I2C
>> +bindings represent each I2C controller as a device tree node. Such nodes should
>> +be nested directly inside the main BPMP node.
>> +
>> +Software can determine whether a child node of the BPMP node represents a device
>> +by checking for a compatible property. Any node with a compatible property
>> +represents a device that can be instantiated. Nodes without a compatible
>> +property may be used to provide configuration information regarding the BPMP
>> +itself, although no such configuration nodes are currently defined by this
>> +binding.
>> +
>> +The BPMP firmware defines no single global name-/numbering-space for such
>> +services. Put another way, the numbering scheme for I2C buses is distinct from
>> +the numbering scheme for any other service the BPMP may provide (e.g. a future
>> +hypothetical SPI bus service). As such, child device nodes will have no reg
>> +property, and the BPMP node will have no #address-cells or #size-cells property.
>
> My understanding is that the I2C bus number is passed as part of the
> request to the BPMP firmware. Does that not count as addressing? Could
> we not represent that generically using a device tree hierarchy? I'm
> thinking something along these lines:
>
> 	bpmp {
> 		...
>
> 		services {
> 			i2c {
> 				i2c at 0 {
> 					reg = <0>;

Technically, that is possible. However, Rob Herring rejected the idea of 
multiple levels of sub-nodes.

Can we please just go with what we have? DT bindings are frankly an 
obstacle to getting anything done:-(

Re: [PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Stephen Warren]

On 07/26/2016 04:03 AM, Jon Hunter wrote:
>
> On 19/07/16 20:14, Stephen Warren wrote:
>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>
>> In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
>> HW devices, such as the I2C controller for the power management I2C bus.
>> Software running on other CPUs must perform IPC to the BPMP in order to
>> execute transactions on that I2C bus. This binding describes an I2C bus
>> that is accessed in such a fashion.
>>
>> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>>  .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
>>  1 file changed, 42 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
>> new file mode 100644
>> index 000000000000..fecb549bc250
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
>> @@ -0,0 +1,42 @@
>> +NVIDIA Tegra186 BPMP I2C controller
>> +
>> +In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
>> +devices, such as the I2C controller for the power management I2C bus. Software
>> +running on other CPUs must perform IPC to the BPMP in order to execute
>> +transactions on that I2C bus. This binding describes an I2C bus that is
>> +accessed in such a fashion.
>> +
>> +The BPMP I2C node must be located directly inside the main BPMP node. See
>> +../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
>> +
>> +This node represents an I2C controller. See ../i2c/i2c.txt for details of the
>> +core I2C binding.
>> +
>> +Required properties:
>> +- compatible:
>> +    Array of strings.
>> +    One of:
>> +    - "nvidia,tegra186-bpmp-i2c".
>> +- #address-cells: Address cells for I2C device address.
>> +    Single-cell integer.
>> +    Must be <1>.
>> +- #size-cells:
>> +    Single-cell integer.
>> +    Must be <0>.
>> +- nvidia,bpmp-bus-id:
>> +    Single-cell integer.
>> +    Indicates the I2C bus number this DT node represent, as defined by the
>> +    BPMP firmware.
>> +
>> +Example:
>> +
>> +/ bpmp {
>
> Is this "/" intentional?

I think I meant to write "/bpmp" (i.e. without the space) to highlight 
where the node is in the overall hierarchy, but admittedly that's 
unusual. Yes, the "/ " should probably simply be removed.

>> +	...
>> +
>> +	bpmp-i2c {
>> +		compatible = "nvidia,tegra186-bpmp-i2c";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		nvidia,bpmp-bus-id = <5>;
>> +	};
>> +};
>>
>
> Acked-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Jon

[PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Stephen Warren]

On 07/26/2016 04:03 AM, Jon Hunter wrote:
>
> On 19/07/16 20:14, Stephen Warren wrote:
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
>> HW devices, such as the I2C controller for the power management I2C bus.
>> Software running on other CPUs must perform IPC to the BPMP in order to
>> execute transactions on that I2C bus. This binding describes an I2C bus
>> that is accessed in such a fashion.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>> ---
>>  .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
>>  1 file changed, 42 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
>> new file mode 100644
>> index 000000000000..fecb549bc250
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt
>> @@ -0,0 +1,42 @@
>> +NVIDIA Tegra186 BPMP I2C controller
>> +
>> +In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW
>> +devices, such as the I2C controller for the power management I2C bus. Software
>> +running on other CPUs must perform IPC to the BPMP in order to execute
>> +transactions on that I2C bus. This binding describes an I2C bus that is
>> +accessed in such a fashion.
>> +
>> +The BPMP I2C node must be located directly inside the main BPMP node. See
>> +../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding.
>> +
>> +This node represents an I2C controller. See ../i2c/i2c.txt for details of the
>> +core I2C binding.
>> +
>> +Required properties:
>> +- compatible:
>> +    Array of strings.
>> +    One of:
>> +    - "nvidia,tegra186-bpmp-i2c".
>> +- #address-cells: Address cells for I2C device address.
>> +    Single-cell integer.
>> +    Must be <1>.
>> +- #size-cells:
>> +    Single-cell integer.
>> +    Must be <0>.
>> +- nvidia,bpmp-bus-id:
>> +    Single-cell integer.
>> +    Indicates the I2C bus number this DT node represent, as defined by the
>> +    BPMP firmware.
>> +
>> +Example:
>> +
>> +/ bpmp {
>
> Is this "/" intentional?

I think I meant to write "/bpmp" (i.e. without the space) to highlight 
where the node is in the overall hierarchy, but admittedly that's 
unusual. Yes, the "/ " should probably simply be removed.

>> +	...
>> +
>> +	bpmp-i2c {
>> +		compatible = "nvidia,tegra186-bpmp-i2c";
>> +		#address-cells = <1>;
>> +		#size-cells = <0>;
>> +		nvidia,bpmp-bus-id = <5>;
>> +	};
>> +};
>>
>
> Acked-by: Jon Hunter <jonathanh@nvidia.com>
>
> Jon

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/26/2016 10:21 AM, Stephen Warren wrote:
> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>
>>> The BPMP implements some services which must be represented by separate
>>> nodes. For example, it can provide access to certain I2C controllers,
>>> and
>>> the I2C bindings represent each I2C controller as a device tree node.
>>> Update the binding to describe how the BPMP supports this.
>>>
>>> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>> ++++++++++++++++++++++
>>>  1 file changed, 23 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> index 9a3864f56955..142d363406f6 100644
>>> ---
>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> +++
>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>  - .../reset/reset.txt
>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>
>>> +The BPMP implements some services which must be represented by
>>> separate nodes.
>>> +For example, it can provide access to certain I2C controllers, and
>>> the I2C
>>> +bindings represent each I2C controller as a device tree node. Such
>>> nodes should
>>> +be nested directly inside the main BPMP node.
>>> +
>>> +Software can determine whether a child node of the BPMP node
>>> represents a device
>>> +by checking for a compatible property. Any node with a compatible
>>> property
>>> +represents a device that can be instantiated. Nodes without a
>>> compatible
>>> +property may be used to provide configuration information regarding
>>> the BPMP
>>> +itself, although no such configuration nodes are currently defined
>>> by this
>>> +binding.
>>> +
>>> +The BPMP firmware defines no single global name-/numbering-space for
>>> such
>>> +services. Put another way, the numbering scheme for I2C buses is
>>> distinct from
>>> +the numbering scheme for any other service the BPMP may provide
>>> (e.g. a future
>>> +hypothetical SPI bus service). As such, child device nodes will have
>>> no reg
>>> +property, and the BPMP node will have no #address-cells or
>>> #size-cells property.
>>
>> My understanding is that the I2C bus number is passed as part of the
>> request to the BPMP firmware. Does that not count as addressing? Could
>> we not represent that generically using a device tree hierarchy? I'm
>> thinking something along these lines:
>>
>>     bpmp {
>>         ...
>>
>>         services {
>>             i2c {
>>                 i2c@0 {
>>                     reg = <0>;
>
> Technically, that is possible. However, Rob Herring rejected the idea of
> multiple levels of sub-nodes.
>
> Can we please just go with what we have? DT bindings are frankly an
> obstacle to getting anything done:-(

Thierry, any further thoughts here? I really need to get these DT 
bindings finalized so that I can use them in U-Boot, which is very 
urgent. Thanks.

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/26/2016 10:21 AM, Stephen Warren wrote:
> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>> From: Stephen Warren <swarren@nvidia.com>
>>>
>>> The BPMP implements some services which must be represented by separate
>>> nodes. For example, it can provide access to certain I2C controllers,
>>> and
>>> the I2C bindings represent each I2C controller as a device tree node.
>>> Update the binding to describe how the BPMP supports this.
>>>
>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>> ---
>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>> ++++++++++++++++++++++
>>>  1 file changed, 23 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> index 9a3864f56955..142d363406f6 100644
>>> ---
>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> +++
>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>  - .../reset/reset.txt
>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>
>>> +The BPMP implements some services which must be represented by
>>> separate nodes.
>>> +For example, it can provide access to certain I2C controllers, and
>>> the I2C
>>> +bindings represent each I2C controller as a device tree node. Such
>>> nodes should
>>> +be nested directly inside the main BPMP node.
>>> +
>>> +Software can determine whether a child node of the BPMP node
>>> represents a device
>>> +by checking for a compatible property. Any node with a compatible
>>> property
>>> +represents a device that can be instantiated. Nodes without a
>>> compatible
>>> +property may be used to provide configuration information regarding
>>> the BPMP
>>> +itself, although no such configuration nodes are currently defined
>>> by this
>>> +binding.
>>> +
>>> +The BPMP firmware defines no single global name-/numbering-space for
>>> such
>>> +services. Put another way, the numbering scheme for I2C buses is
>>> distinct from
>>> +the numbering scheme for any other service the BPMP may provide
>>> (e.g. a future
>>> +hypothetical SPI bus service). As such, child device nodes will have
>>> no reg
>>> +property, and the BPMP node will have no #address-cells or
>>> #size-cells property.
>>
>> My understanding is that the I2C bus number is passed as part of the
>> request to the BPMP firmware. Does that not count as addressing? Could
>> we not represent that generically using a device tree hierarchy? I'm
>> thinking something along these lines:
>>
>>     bpmp {
>>         ...
>>
>>         services {
>>             i2c {
>>                 i2c at 0 {
>>                     reg = <0>;
>
> Technically, that is possible. However, Rob Herring rejected the idea of
> multiple levels of sub-nodes.
>
> Can we please just go with what we have? DT bindings are frankly an
> obstacle to getting anything done:-(

Thierry, any further thoughts here? I really need to get these DT 
bindings finalized so that I can use them in U-Boot, which is very 
urgent. Thanks.

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Thierry Reding]

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

On Wed, Jul 27, 2016 at 03:50:52PM -0600, Stephen Warren wrote:
> On 07/26/2016 10:21 AM, Stephen Warren wrote:
> > On 07/26/2016 04:03 AM, Thierry Reding wrote:
> > > On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> > > > From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > > 
> > > > The BPMP implements some services which must be represented by separate
> > > > nodes. For example, it can provide access to certain I2C controllers,
> > > > and
> > > > the I2C bindings represent each I2C controller as a device tree node.
> > > > Update the binding to describe how the BPMP supports this.
> > > > 
> > > > Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > > ---
> > > >  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
> > > > ++++++++++++++++++++++
> > > >  1 file changed, 23 insertions(+)
> > > > 
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > index 9a3864f56955..142d363406f6 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > @@ -38,6 +38,24 @@ implemented by this node:
> > > >  - .../reset/reset.txt
> > > >  - <dt-bindings/reset/tegra186-reset.h>
> > > > 
> > > > +The BPMP implements some services which must be represented by
> > > > separate nodes.
> > > > +For example, it can provide access to certain I2C controllers, and
> > > > the I2C
> > > > +bindings represent each I2C controller as a device tree node. Such
> > > > nodes should
> > > > +be nested directly inside the main BPMP node.
> > > > +
> > > > +Software can determine whether a child node of the BPMP node
> > > > represents a device
> > > > +by checking for a compatible property. Any node with a compatible
> > > > property
> > > > +represents a device that can be instantiated. Nodes without a
> > > > compatible
> > > > +property may be used to provide configuration information regarding
> > > > the BPMP
> > > > +itself, although no such configuration nodes are currently defined
> > > > by this
> > > > +binding.
> > > > +
> > > > +The BPMP firmware defines no single global name-/numbering-space for
> > > > such
> > > > +services. Put another way, the numbering scheme for I2C buses is
> > > > distinct from
> > > > +the numbering scheme for any other service the BPMP may provide
> > > > (e.g. a future
> > > > +hypothetical SPI bus service). As such, child device nodes will have
> > > > no reg
> > > > +property, and the BPMP node will have no #address-cells or
> > > > #size-cells property.
> > > 
> > > My understanding is that the I2C bus number is passed as part of the
> > > request to the BPMP firmware. Does that not count as addressing? Could
> > > we not represent that generically using a device tree hierarchy? I'm
> > > thinking something along these lines:
> > > 
> > >     bpmp {
> > >         ...
> > > 
> > >         services {
> > >             i2c {
> > >                 i2c@0 {
> > >                     reg = <0>;
> > 
> > Technically, that is possible. However, Rob Herring rejected the idea of
> > multiple levels of sub-nodes.
> > 
> > Can we please just go with what we have? DT bindings are frankly an
> > obstacle to getting anything done:-(
> 
> Thierry, any further thoughts here? I really need to get these DT bindings
> finalized so that I can use them in U-Boot, which is very urgent. Thanks.

If everyone else is fine with these bindings, let's go ahead with them.

Thierry

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

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Thierry Reding]

On Wed, Jul 27, 2016 at 03:50:52PM -0600, Stephen Warren wrote:
> On 07/26/2016 10:21 AM, Stephen Warren wrote:
> > On 07/26/2016 04:03 AM, Thierry Reding wrote:
> > > On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> > > > From: Stephen Warren <swarren@nvidia.com>
> > > > 
> > > > The BPMP implements some services which must be represented by separate
> > > > nodes. For example, it can provide access to certain I2C controllers,
> > > > and
> > > > the I2C bindings represent each I2C controller as a device tree node.
> > > > Update the binding to describe how the BPMP supports this.
> > > > 
> > > > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > > > ---
> > > >  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
> > > > ++++++++++++++++++++++
> > > >  1 file changed, 23 insertions(+)
> > > > 
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > index 9a3864f56955..142d363406f6 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > @@ -38,6 +38,24 @@ implemented by this node:
> > > >  - .../reset/reset.txt
> > > >  - <dt-bindings/reset/tegra186-reset.h>
> > > > 
> > > > +The BPMP implements some services which must be represented by
> > > > separate nodes.
> > > > +For example, it can provide access to certain I2C controllers, and
> > > > the I2C
> > > > +bindings represent each I2C controller as a device tree node. Such
> > > > nodes should
> > > > +be nested directly inside the main BPMP node.
> > > > +
> > > > +Software can determine whether a child node of the BPMP node
> > > > represents a device
> > > > +by checking for a compatible property. Any node with a compatible
> > > > property
> > > > +represents a device that can be instantiated. Nodes without a
> > > > compatible
> > > > +property may be used to provide configuration information regarding
> > > > the BPMP
> > > > +itself, although no such configuration nodes are currently defined
> > > > by this
> > > > +binding.
> > > > +
> > > > +The BPMP firmware defines no single global name-/numbering-space for
> > > > such
> > > > +services. Put another way, the numbering scheme for I2C buses is
> > > > distinct from
> > > > +the numbering scheme for any other service the BPMP may provide
> > > > (e.g. a future
> > > > +hypothetical SPI bus service). As such, child device nodes will have
> > > > no reg
> > > > +property, and the BPMP node will have no #address-cells or
> > > > #size-cells property.
> > > 
> > > My understanding is that the I2C bus number is passed as part of the
> > > request to the BPMP firmware. Does that not count as addressing? Could
> > > we not represent that generically using a device tree hierarchy? I'm
> > > thinking something along these lines:
> > > 
> > >     bpmp {
> > >         ...
> > > 
> > >         services {
> > >             i2c {
> > >                 i2c at 0 {
> > >                     reg = <0>;
> > 
> > Technically, that is possible. However, Rob Herring rejected the idea of
> > multiple levels of sub-nodes.
> > 
> > Can we please just go with what we have? DT bindings are frankly an
> > obstacle to getting anything done:-(
> 
> Thierry, any further thoughts here? I really need to get these DT bindings
> finalized so that I can use them in U-Boot, which is very urgent. Thanks.

If everyone else is fine with these bindings, let's go ahead with them.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160728/e2991667/attachment.sig>

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Rob Herring]

On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>
>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>
>>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>
>>> The BPMP implements some services which must be represented by separate
>>> nodes. For example, it can provide access to certain I2C controllers, and
>>> the I2C bindings represent each I2C controller as a device tree node.
>>> Update the binding to describe how the BPMP supports this.
>>>
>>> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>> ++++++++++++++++++++++
>>>  1 file changed, 23 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> index 9a3864f56955..142d363406f6 100644
>>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>  - .../reset/reset.txt
>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>
>>> +The BPMP implements some services which must be represented by separate
>>> nodes.
>>> +For example, it can provide access to certain I2C controllers, and the
>>> I2C
>>> +bindings represent each I2C controller as a device tree node. Such nodes
>>> should
>>> +be nested directly inside the main BPMP node.
>>> +
>>> +Software can determine whether a child node of the BPMP node represents
>>> a device
>>> +by checking for a compatible property. Any node with a compatible
>>> property
>>> +represents a device that can be instantiated. Nodes without a compatible
>>> +property may be used to provide configuration information regarding the
>>> BPMP
>>> +itself, although no such configuration nodes are currently defined by
>>> this
>>> +binding.
>>> +
>>> +The BPMP firmware defines no single global name-/numbering-space for
>>> such
>>> +services. Put another way, the numbering scheme for I2C buses is
>>> distinct from
>>> +the numbering scheme for any other service the BPMP may provide (e.g. a
>>> future
>>> +hypothetical SPI bus service). As such, child device nodes will have no
>>> reg
>>> +property, and the BPMP node will have no #address-cells or #size-cells
>>> property.
>>
>>
>> My understanding is that the I2C bus number is passed as part of the
>> request to the BPMP firmware. Does that not count as addressing? Could
>> we not represent that generically using a device tree hierarchy? I'm
>> thinking something along these lines:
>>
>>         bpmp {
>>                 ...
>>
>>                 services {
>>                         i2c {
>>                                 i2c@0 {
>>                                         reg = <0>;
>
>
> Technically, that is possible. However, Rob Herring rejected the idea of
> multiple levels of sub-nodes.

I think I questioned the need, not rejected. What about the above, but
remove serivces level:

         bpmp {
                 ...

                 i2c {
                         i2c@0 {
                                 reg = <0>;

Rob

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Rob Herring]

On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>
>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>
>>> From: Stephen Warren <swarren@nvidia.com>
>>>
>>> The BPMP implements some services which must be represented by separate
>>> nodes. For example, it can provide access to certain I2C controllers, and
>>> the I2C bindings represent each I2C controller as a device tree node.
>>> Update the binding to describe how the BPMP supports this.
>>>
>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>> ---
>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>> ++++++++++++++++++++++
>>>  1 file changed, 23 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> index 9a3864f56955..142d363406f6 100644
>>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>  - .../reset/reset.txt
>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>
>>> +The BPMP implements some services which must be represented by separate
>>> nodes.
>>> +For example, it can provide access to certain I2C controllers, and the
>>> I2C
>>> +bindings represent each I2C controller as a device tree node. Such nodes
>>> should
>>> +be nested directly inside the main BPMP node.
>>> +
>>> +Software can determine whether a child node of the BPMP node represents
>>> a device
>>> +by checking for a compatible property. Any node with a compatible
>>> property
>>> +represents a device that can be instantiated. Nodes without a compatible
>>> +property may be used to provide configuration information regarding the
>>> BPMP
>>> +itself, although no such configuration nodes are currently defined by
>>> this
>>> +binding.
>>> +
>>> +The BPMP firmware defines no single global name-/numbering-space for
>>> such
>>> +services. Put another way, the numbering scheme for I2C buses is
>>> distinct from
>>> +the numbering scheme for any other service the BPMP may provide (e.g. a
>>> future
>>> +hypothetical SPI bus service). As such, child device nodes will have no
>>> reg
>>> +property, and the BPMP node will have no #address-cells or #size-cells
>>> property.
>>
>>
>> My understanding is that the I2C bus number is passed as part of the
>> request to the BPMP firmware. Does that not count as addressing? Could
>> we not represent that generically using a device tree hierarchy? I'm
>> thinking something along these lines:
>>
>>         bpmp {
>>                 ...
>>
>>                 services {
>>                         i2c {
>>                                 i2c at 0 {
>>                                         reg = <0>;
>
>
> Technically, that is possible. However, Rob Herring rejected the idea of
> multiple levels of sub-nodes.

I think I questioned the need, not rejected. What about the above, but
remove serivces level:

         bpmp {
                 ...

                 i2c {
                         i2c at 0 {
                                 reg = <0>;

Rob

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/28/2016 01:07 PM, Rob Herring wrote:
> On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>>
>>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>>
>>>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>
>>>> The BPMP implements some services which must be represented by separate
>>>> nodes. For example, it can provide access to certain I2C controllers, and
>>>> the I2C bindings represent each I2C controller as a device tree node.
>>>> Update the binding to describe how the BPMP supports this.
>>>>
>>>> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>> ---
>>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>>> ++++++++++++++++++++++
>>>>  1 file changed, 23 insertions(+)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>> index 9a3864f56955..142d363406f6 100644
>>>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>>  - .../reset/reset.txt
>>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>>
>>>> +The BPMP implements some services which must be represented by separate
>>>> nodes.
>>>> +For example, it can provide access to certain I2C controllers, and the
>>>> I2C
>>>> +bindings represent each I2C controller as a device tree node. Such nodes
>>>> should
>>>> +be nested directly inside the main BPMP node.
>>>> +
>>>> +Software can determine whether a child node of the BPMP node represents
>>>> a device
>>>> +by checking for a compatible property. Any node with a compatible
>>>> property
>>>> +represents a device that can be instantiated. Nodes without a compatible
>>>> +property may be used to provide configuration information regarding the
>>>> BPMP
>>>> +itself, although no such configuration nodes are currently defined by
>>>> this
>>>> +binding.
>>>> +
>>>> +The BPMP firmware defines no single global name-/numbering-space for
>>>> such
>>>> +services. Put another way, the numbering scheme for I2C buses is
>>>> distinct from
>>>> +the numbering scheme for any other service the BPMP may provide (e.g. a
>>>> future
>>>> +hypothetical SPI bus service). As such, child device nodes will have no
>>>> reg
>>>> +property, and the BPMP node will have no #address-cells or #size-cells
>>>> property.
>>>
>>>
>>> My understanding is that the I2C bus number is passed as part of the
>>> request to the BPMP firmware. Does that not count as addressing? Could
>>> we not represent that generically using a device tree hierarchy? I'm
>>> thinking something along these lines:
>>>
>>>         bpmp {
>>>                 ...
>>>
>>>                 services {
>>>                         i2c {
>>>                                 i2c@0 {
>>>                                         reg = <0>;
>>
>>
>> Technically, that is possible. However, Rob Herring rejected the idea of
>> multiple levels of sub-nodes.
>
> I think I questioned the need, not rejected. What about the above, but
> remove serivces level:
>
>          bpmp {
>                  ...
>
>                  i2c {
>                          i2c@0 {
>                                  reg = <0>;

Sigh. Can you please talk to Thierry and work out what the binding would 
be (perhaps on IRC to expedite things?) and I'll just implement whatever 
you two agree upon. I don't really care much what the binding looks like 
any more; I just need something that will pass review. Thanks.

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/28/2016 01:07 PM, Rob Herring wrote:
> On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>>
>>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>>
>>>> From: Stephen Warren <swarren@nvidia.com>
>>>>
>>>> The BPMP implements some services which must be represented by separate
>>>> nodes. For example, it can provide access to certain I2C controllers, and
>>>> the I2C bindings represent each I2C controller as a device tree node.
>>>> Update the binding to describe how the BPMP supports this.
>>>>
>>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>>> ---
>>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>>> ++++++++++++++++++++++
>>>>  1 file changed, 23 insertions(+)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>> index 9a3864f56955..142d363406f6 100644
>>>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>>  - .../reset/reset.txt
>>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>>
>>>> +The BPMP implements some services which must be represented by separate
>>>> nodes.
>>>> +For example, it can provide access to certain I2C controllers, and the
>>>> I2C
>>>> +bindings represent each I2C controller as a device tree node. Such nodes
>>>> should
>>>> +be nested directly inside the main BPMP node.
>>>> +
>>>> +Software can determine whether a child node of the BPMP node represents
>>>> a device
>>>> +by checking for a compatible property. Any node with a compatible
>>>> property
>>>> +represents a device that can be instantiated. Nodes without a compatible
>>>> +property may be used to provide configuration information regarding the
>>>> BPMP
>>>> +itself, although no such configuration nodes are currently defined by
>>>> this
>>>> +binding.
>>>> +
>>>> +The BPMP firmware defines no single global name-/numbering-space for
>>>> such
>>>> +services. Put another way, the numbering scheme for I2C buses is
>>>> distinct from
>>>> +the numbering scheme for any other service the BPMP may provide (e.g. a
>>>> future
>>>> +hypothetical SPI bus service). As such, child device nodes will have no
>>>> reg
>>>> +property, and the BPMP node will have no #address-cells or #size-cells
>>>> property.
>>>
>>>
>>> My understanding is that the I2C bus number is passed as part of the
>>> request to the BPMP firmware. Does that not count as addressing? Could
>>> we not represent that generically using a device tree hierarchy? I'm
>>> thinking something along these lines:
>>>
>>>         bpmp {
>>>                 ...
>>>
>>>                 services {
>>>                         i2c {
>>>                                 i2c at 0 {
>>>                                         reg = <0>;
>>
>>
>> Technically, that is possible. However, Rob Herring rejected the idea of
>> multiple levels of sub-nodes.
>
> I think I questioned the need, not rejected. What about the above, but
> remove serivces level:
>
>          bpmp {
>                  ...
>
>                  i2c {
>                          i2c at 0 {
>                                  reg = <0>;

Sigh. Can you please talk to Thierry and work out what the binding would 
be (perhaps on IRC to expedite things?) and I'll just implement whatever 
you two agree upon. I don't really care much what the binding looks like 
any more; I just need something that will pass review. Thanks.

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Thierry Reding]

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

On Thu, Jul 28, 2016 at 03:24:22PM -0600, Stephen Warren wrote:
> On 07/28/2016 01:07 PM, Rob Herring wrote:
> > On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> > > On 07/26/2016 04:03 AM, Thierry Reding wrote:
> > > > 
> > > > On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> > > > > 
> > > > > From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > > > 
> > > > > The BPMP implements some services which must be represented by separate
> > > > > nodes. For example, it can provide access to certain I2C controllers, and
> > > > > the I2C bindings represent each I2C controller as a device tree node.
> > > > > Update the binding to describe how the BPMP supports this.
> > > > > 
> > > > > Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > > > > ---
> > > > >  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
> > > > > ++++++++++++++++++++++
> > > > >  1 file changed, 23 insertions(+)
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > > b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > > index 9a3864f56955..142d363406f6 100644
> > > > > --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > > +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > > @@ -38,6 +38,24 @@ implemented by this node:
> > > > >  - .../reset/reset.txt
> > > > >  - <dt-bindings/reset/tegra186-reset.h>
> > > > > 
> > > > > +The BPMP implements some services which must be represented by separate
> > > > > nodes.
> > > > > +For example, it can provide access to certain I2C controllers, and the
> > > > > I2C
> > > > > +bindings represent each I2C controller as a device tree node. Such nodes
> > > > > should
> > > > > +be nested directly inside the main BPMP node.
> > > > > +
> > > > > +Software can determine whether a child node of the BPMP node represents
> > > > > a device
> > > > > +by checking for a compatible property. Any node with a compatible
> > > > > property
> > > > > +represents a device that can be instantiated. Nodes without a compatible
> > > > > +property may be used to provide configuration information regarding the
> > > > > BPMP
> > > > > +itself, although no such configuration nodes are currently defined by
> > > > > this
> > > > > +binding.
> > > > > +
> > > > > +The BPMP firmware defines no single global name-/numbering-space for
> > > > > such
> > > > > +services. Put another way, the numbering scheme for I2C buses is
> > > > > distinct from
> > > > > +the numbering scheme for any other service the BPMP may provide (e.g. a
> > > > > future
> > > > > +hypothetical SPI bus service). As such, child device nodes will have no
> > > > > reg
> > > > > +property, and the BPMP node will have no #address-cells or #size-cells
> > > > > property.
> > > > 
> > > > 
> > > > My understanding is that the I2C bus number is passed as part of the
> > > > request to the BPMP firmware. Does that not count as addressing? Could
> > > > we not represent that generically using a device tree hierarchy? I'm
> > > > thinking something along these lines:
> > > > 
> > > >         bpmp {
> > > >                 ...
> > > > 
> > > >                 services {
> > > >                         i2c {
> > > >                                 i2c@0 {
> > > >                                         reg = <0>;
> > > 
> > > 
> > > Technically, that is possible. However, Rob Herring rejected the idea of
> > > multiple levels of sub-nodes.
> > 
> > I think I questioned the need, not rejected. What about the above, but
> > remove serivces level:
> > 
> >          bpmp {
> >                  ...
> > 
> >                  i2c {
> >                          i2c@0 {
> >                                  reg = <0>;
> 
> Sigh. Can you please talk to Thierry and work out what the binding would be
> (perhaps on IRC to expedite things?) and I'll just implement whatever you
> two agree upon. I don't really care much what the binding looks like any
> more; I just need something that will pass review. Thanks.

Like I said, I'm fine going with what you proposed. I'm sure by now the
BPMP has long been frozen and if the proposed binding works fine that's
good. No need to over-engineer.

If we ever need more than one I2C (or expose other busses) I'm sure we
can find a way to switch to something like the above later on. Like I
said, that's very unlikely to happen on Tegra186, so we'll have a new
compatible string (and hence an easy way to differentiate between these
bindings) anyway.

Thierry

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

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Thierry Reding]

On Thu, Jul 28, 2016 at 03:24:22PM -0600, Stephen Warren wrote:
> On 07/28/2016 01:07 PM, Rob Herring wrote:
> > On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > > On 07/26/2016 04:03 AM, Thierry Reding wrote:
> > > > 
> > > > On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> > > > > 
> > > > > From: Stephen Warren <swarren@nvidia.com>
> > > > > 
> > > > > The BPMP implements some services which must be represented by separate
> > > > > nodes. For example, it can provide access to certain I2C controllers, and
> > > > > the I2C bindings represent each I2C controller as a device tree node.
> > > > > Update the binding to describe how the BPMP supports this.
> > > > > 
> > > > > Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > > > > ---
> > > > >  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
> > > > > ++++++++++++++++++++++
> > > > >  1 file changed, 23 insertions(+)
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > > b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > > index 9a3864f56955..142d363406f6 100644
> > > > > --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > > +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> > > > > @@ -38,6 +38,24 @@ implemented by this node:
> > > > >  - .../reset/reset.txt
> > > > >  - <dt-bindings/reset/tegra186-reset.h>
> > > > > 
> > > > > +The BPMP implements some services which must be represented by separate
> > > > > nodes.
> > > > > +For example, it can provide access to certain I2C controllers, and the
> > > > > I2C
> > > > > +bindings represent each I2C controller as a device tree node. Such nodes
> > > > > should
> > > > > +be nested directly inside the main BPMP node.
> > > > > +
> > > > > +Software can determine whether a child node of the BPMP node represents
> > > > > a device
> > > > > +by checking for a compatible property. Any node with a compatible
> > > > > property
> > > > > +represents a device that can be instantiated. Nodes without a compatible
> > > > > +property may be used to provide configuration information regarding the
> > > > > BPMP
> > > > > +itself, although no such configuration nodes are currently defined by
> > > > > this
> > > > > +binding.
> > > > > +
> > > > > +The BPMP firmware defines no single global name-/numbering-space for
> > > > > such
> > > > > +services. Put another way, the numbering scheme for I2C buses is
> > > > > distinct from
> > > > > +the numbering scheme for any other service the BPMP may provide (e.g. a
> > > > > future
> > > > > +hypothetical SPI bus service). As such, child device nodes will have no
> > > > > reg
> > > > > +property, and the BPMP node will have no #address-cells or #size-cells
> > > > > property.
> > > > 
> > > > 
> > > > My understanding is that the I2C bus number is passed as part of the
> > > > request to the BPMP firmware. Does that not count as addressing? Could
> > > > we not represent that generically using a device tree hierarchy? I'm
> > > > thinking something along these lines:
> > > > 
> > > >         bpmp {
> > > >                 ...
> > > > 
> > > >                 services {
> > > >                         i2c {
> > > >                                 i2c at 0 {
> > > >                                         reg = <0>;
> > > 
> > > 
> > > Technically, that is possible. However, Rob Herring rejected the idea of
> > > multiple levels of sub-nodes.
> > 
> > I think I questioned the need, not rejected. What about the above, but
> > remove serivces level:
> > 
> >          bpmp {
> >                  ...
> > 
> >                  i2c {
> >                          i2c at 0 {
> >                                  reg = <0>;
> 
> Sigh. Can you please talk to Thierry and work out what the binding would be
> (perhaps on IRC to expedite things?) and I'll just implement whatever you
> two agree upon. I don't really care much what the binding looks like any
> more; I just need something that will pass review. Thanks.

Like I said, I'm fine going with what you proposed. I'm sure by now the
BPMP has long been frozen and if the proposed binding works fine that's
good. No need to over-engineer.

If we ever need more than one I2C (or expose other busses) I'm sure we
can find a way to switch to something like the above later on. Like I
said, that's very unlikely to happen on Tegra186, so we'll have a new
compatible string (and hence an easy way to differentiate between these
bindings) anyway.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160729/1209e25e/attachment.sig>

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/29/2016 07:48 AM, Thierry Reding wrote:
> On Thu, Jul 28, 2016 at 03:24:22PM -0600, Stephen Warren wrote:
>> On 07/28/2016 01:07 PM, Rob Herring wrote:
>>> On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>>>> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>>>>
>>>>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>>>>
>>>>>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>>
>>>>>> The BPMP implements some services which must be represented by separate
>>>>>> nodes. For example, it can provide access to certain I2C controllers, and
>>>>>> the I2C bindings represent each I2C controller as a device tree node.
>>>>>> Update the binding to describe how the BPMP supports this.
>>>>>>
>>>>>> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>> ---
>>>>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>>>>> ++++++++++++++++++++++
>>>>>>  1 file changed, 23 insertions(+)
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>> index 9a3864f56955..142d363406f6 100644
>>>>>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>>>>  - .../reset/reset.txt
>>>>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>>>>
>>>>>> +The BPMP implements some services which must be represented by separate
>>>>>> nodes.
>>>>>> +For example, it can provide access to certain I2C controllers, and the
>>>>>> I2C
>>>>>> +bindings represent each I2C controller as a device tree node. Such nodes
>>>>>> should
>>>>>> +be nested directly inside the main BPMP node.
>>>>>> +
>>>>>> +Software can determine whether a child node of the BPMP node represents
>>>>>> a device
>>>>>> +by checking for a compatible property. Any node with a compatible
>>>>>> property
>>>>>> +represents a device that can be instantiated. Nodes without a compatible
>>>>>> +property may be used to provide configuration information regarding the
>>>>>> BPMP
>>>>>> +itself, although no such configuration nodes are currently defined by
>>>>>> this
>>>>>> +binding.
>>>>>> +
>>>>>> +The BPMP firmware defines no single global name-/numbering-space for
>>>>>> such
>>>>>> +services. Put another way, the numbering scheme for I2C buses is
>>>>>> distinct from
>>>>>> +the numbering scheme for any other service the BPMP may provide (e.g. a
>>>>>> future
>>>>>> +hypothetical SPI bus service). As such, child device nodes will have no
>>>>>> reg
>>>>>> +property, and the BPMP node will have no #address-cells or #size-cells
>>>>>> property.
>>>>>
>>>>>
>>>>> My understanding is that the I2C bus number is passed as part of the
>>>>> request to the BPMP firmware. Does that not count as addressing? Could
>>>>> we not represent that generically using a device tree hierarchy? I'm
>>>>> thinking something along these lines:
>>>>>
>>>>>         bpmp {
>>>>>                 ...
>>>>>
>>>>>                 services {
>>>>>                         i2c {
>>>>>                                 i2c@0 {
>>>>>                                         reg = <0>;
>>>>
>>>>
>>>> Technically, that is possible. However, Rob Herring rejected the idea of
>>>> multiple levels of sub-nodes.
>>>
>>> I think I questioned the need, not rejected. What about the above, but
>>> remove serivces level:
>>>
>>>          bpmp {
>>>                  ...
>>>
>>>                  i2c {
>>>                          i2c@0 {
>>>                                  reg = <0>;
>>
>> Sigh. Can you please talk to Thierry and work out what the binding would be
>> (perhaps on IRC to expedite things?) and I'll just implement whatever you
>> two agree upon. I don't really care much what the binding looks like any
>> more; I just need something that will pass review. Thanks.
>
> Like I said, I'm fine going with what you proposed.

OK, great. For the record, I'm going to send U-Boot patches today that 
apply this binding patch (the original one I sent, unmodified) to the 
U-Boot tree, and implement it in the U-Boot driver.

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/29/2016 07:48 AM, Thierry Reding wrote:
> On Thu, Jul 28, 2016 at 03:24:22PM -0600, Stephen Warren wrote:
>> On 07/28/2016 01:07 PM, Rob Herring wrote:
>>> On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>>>>
>>>>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>>>>
>>>>>> From: Stephen Warren <swarren@nvidia.com>
>>>>>>
>>>>>> The BPMP implements some services which must be represented by separate
>>>>>> nodes. For example, it can provide access to certain I2C controllers, and
>>>>>> the I2C bindings represent each I2C controller as a device tree node.
>>>>>> Update the binding to describe how the BPMP supports this.
>>>>>>
>>>>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>>>>> ---
>>>>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>>>>> ++++++++++++++++++++++
>>>>>>  1 file changed, 23 insertions(+)
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>> index 9a3864f56955..142d363406f6 100644
>>>>>> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>>>>  - .../reset/reset.txt
>>>>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>>>>
>>>>>> +The BPMP implements some services which must be represented by separate
>>>>>> nodes.
>>>>>> +For example, it can provide access to certain I2C controllers, and the
>>>>>> I2C
>>>>>> +bindings represent each I2C controller as a device tree node. Such nodes
>>>>>> should
>>>>>> +be nested directly inside the main BPMP node.
>>>>>> +
>>>>>> +Software can determine whether a child node of the BPMP node represents
>>>>>> a device
>>>>>> +by checking for a compatible property. Any node with a compatible
>>>>>> property
>>>>>> +represents a device that can be instantiated. Nodes without a compatible
>>>>>> +property may be used to provide configuration information regarding the
>>>>>> BPMP
>>>>>> +itself, although no such configuration nodes are currently defined by
>>>>>> this
>>>>>> +binding.
>>>>>> +
>>>>>> +The BPMP firmware defines no single global name-/numbering-space for
>>>>>> such
>>>>>> +services. Put another way, the numbering scheme for I2C buses is
>>>>>> distinct from
>>>>>> +the numbering scheme for any other service the BPMP may provide (e.g. a
>>>>>> future
>>>>>> +hypothetical SPI bus service). As such, child device nodes will have no
>>>>>> reg
>>>>>> +property, and the BPMP node will have no #address-cells or #size-cells
>>>>>> property.
>>>>>
>>>>>
>>>>> My understanding is that the I2C bus number is passed as part of the
>>>>> request to the BPMP firmware. Does that not count as addressing? Could
>>>>> we not represent that generically using a device tree hierarchy? I'm
>>>>> thinking something along these lines:
>>>>>
>>>>>         bpmp {
>>>>>                 ...
>>>>>
>>>>>                 services {
>>>>>                         i2c {
>>>>>                                 i2c at 0 {
>>>>>                                         reg = <0>;
>>>>
>>>>
>>>> Technically, that is possible. However, Rob Herring rejected the idea of
>>>> multiple levels of sub-nodes.
>>>
>>> I think I questioned the need, not rejected. What about the above, but
>>> remove serivces level:
>>>
>>>          bpmp {
>>>                  ...
>>>
>>>                  i2c {
>>>                          i2c at 0 {
>>>                                  reg = <0>;
>>
>> Sigh. Can you please talk to Thierry and work out what the binding would be
>> (perhaps on IRC to expedite things?) and I'll just implement whatever you
>> two agree upon. I don't really care much what the binding looks like any
>> more; I just need something that will pass review. Thanks.
>
> Like I said, I'm fine going with what you proposed.

OK, great. For the record, I'm going to send U-Boot patches today that 
apply this binding patch (the original one I sent, unmodified) to the 
U-Boot tree, and implement it in the U-Boot driver.

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Rob Herring]

On Fri, Jul 29, 2016 at 11:06 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
> On 07/29/2016 07:48 AM, Thierry Reding wrote:
>>
>> On Thu, Jul 28, 2016 at 03:24:22PM -0600, Stephen Warren wrote:
>>>
>>> On 07/28/2016 01:07 PM, Rob Herring wrote:
>>>>
>>>> On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
>>>> wrote:
>>>>>
>>>>> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>>>>>
>>>>>>>
>>>>>>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>>>
>>>>>>> The BPMP implements some services which must be represented by
>>>>>>> separate
>>>>>>> nodes. For example, it can provide access to certain I2C controllers,
>>>>>>> and
>>>>>>> the I2C bindings represent each I2C controller as a device tree node.
>>>>>>> Update the binding to describe how the BPMP supports this.
>>>>>>>
>>>>>>> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>>> ---
>>>>>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>>>>>> ++++++++++++++++++++++
>>>>>>>  1 file changed, 23 insertions(+)
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>> index 9a3864f56955..142d363406f6 100644
>>>>>>> ---
>>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>> +++
>>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>>>>>  - .../reset/reset.txt
>>>>>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>>>>>
>>>>>>> +The BPMP implements some services which must be represented by
>>>>>>> separate
>>>>>>> nodes.
>>>>>>> +For example, it can provide access to certain I2C controllers, and
>>>>>>> the
>>>>>>> I2C
>>>>>>> +bindings represent each I2C controller as a device tree node. Such
>>>>>>> nodes
>>>>>>> should
>>>>>>> +be nested directly inside the main BPMP node.
>>>>>>> +
>>>>>>> +Software can determine whether a child node of the BPMP node
>>>>>>> represents
>>>>>>> a device
>>>>>>> +by checking for a compatible property. Any node with a compatible
>>>>>>> property
>>>>>>> +represents a device that can be instantiated. Nodes without a
>>>>>>> compatible
>>>>>>> +property may be used to provide configuration information regarding
>>>>>>> the
>>>>>>> BPMP
>>>>>>> +itself, although no such configuration nodes are currently defined
>>>>>>> by
>>>>>>> this
>>>>>>> +binding.
>>>>>>> +
>>>>>>> +The BPMP firmware defines no single global name-/numbering-space for
>>>>>>> such
>>>>>>> +services. Put another way, the numbering scheme for I2C buses is
>>>>>>> distinct from
>>>>>>> +the numbering scheme for any other service the BPMP may provide
>>>>>>> (e.g. a
>>>>>>> future
>>>>>>> +hypothetical SPI bus service). As such, child device nodes will have
>>>>>>> no
>>>>>>> reg
>>>>>>> +property, and the BPMP node will have no #address-cells or
>>>>>>> #size-cells
>>>>>>> property.
>>>>>>
>>>>>>
>>>>>>
>>>>>> My understanding is that the I2C bus number is passed as part of the
>>>>>> request to the BPMP firmware. Does that not count as addressing? Could
>>>>>> we not represent that generically using a device tree hierarchy? I'm
>>>>>> thinking something along these lines:
>>>>>>
>>>>>>         bpmp {
>>>>>>                 ...
>>>>>>
>>>>>>                 services {
>>>>>>                         i2c {
>>>>>>                                 i2c@0 {
>>>>>>                                         reg = <0>;
>>>>>
>>>>>
>>>>>
>>>>> Technically, that is possible. However, Rob Herring rejected the idea
>>>>> of
>>>>> multiple levels of sub-nodes.
>>>>
>>>>
>>>> I think I questioned the need, not rejected. What about the above, but
>>>> remove serivces level:
>>>>
>>>>          bpmp {
>>>>                  ...
>>>>
>>>>                  i2c {
>>>>                          i2c@0 {
>>>>                                  reg = <0>;
>>>
>>>
>>> Sigh. Can you please talk to Thierry and work out what the binding would
>>> be
>>> (perhaps on IRC to expedite things?) and I'll just implement whatever you
>>> two agree upon. I don't really care much what the binding looks like any
>>> more; I just need something that will pass review. Thanks.
>>
>>
>> Like I said, I'm fine going with what you proposed.
>
>
> OK, great. For the record, I'm going to send U-Boot patches today that apply
> this binding patch (the original one I sent, unmodified) to the U-Boot tree,
> and implement it in the U-Boot driver.

That's fine, I did ack that.

I really don't want to ask, but why are you documenting in u-boot? Is
it some how different for u-boot?

Rob

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Rob Herring]

On Fri, Jul 29, 2016 at 11:06 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/29/2016 07:48 AM, Thierry Reding wrote:
>>
>> On Thu, Jul 28, 2016 at 03:24:22PM -0600, Stephen Warren wrote:
>>>
>>> On 07/28/2016 01:07 PM, Rob Herring wrote:
>>>>
>>>> On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren@wwwdotorg.org>
>>>> wrote:
>>>>>
>>>>> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>>>>>
>>>>>>>
>>>>>>> From: Stephen Warren <swarren@nvidia.com>
>>>>>>>
>>>>>>> The BPMP implements some services which must be represented by
>>>>>>> separate
>>>>>>> nodes. For example, it can provide access to certain I2C controllers,
>>>>>>> and
>>>>>>> the I2C bindings represent each I2C controller as a device tree node.
>>>>>>> Update the binding to describe how the BPMP supports this.
>>>>>>>
>>>>>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>>>>>> ---
>>>>>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>>>>>> ++++++++++++++++++++++
>>>>>>>  1 file changed, 23 insertions(+)
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>> index 9a3864f56955..142d363406f6 100644
>>>>>>> ---
>>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>> +++
>>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>>>>>  - .../reset/reset.txt
>>>>>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>>>>>
>>>>>>> +The BPMP implements some services which must be represented by
>>>>>>> separate
>>>>>>> nodes.
>>>>>>> +For example, it can provide access to certain I2C controllers, and
>>>>>>> the
>>>>>>> I2C
>>>>>>> +bindings represent each I2C controller as a device tree node. Such
>>>>>>> nodes
>>>>>>> should
>>>>>>> +be nested directly inside the main BPMP node.
>>>>>>> +
>>>>>>> +Software can determine whether a child node of the BPMP node
>>>>>>> represents
>>>>>>> a device
>>>>>>> +by checking for a compatible property. Any node with a compatible
>>>>>>> property
>>>>>>> +represents a device that can be instantiated. Nodes without a
>>>>>>> compatible
>>>>>>> +property may be used to provide configuration information regarding
>>>>>>> the
>>>>>>> BPMP
>>>>>>> +itself, although no such configuration nodes are currently defined
>>>>>>> by
>>>>>>> this
>>>>>>> +binding.
>>>>>>> +
>>>>>>> +The BPMP firmware defines no single global name-/numbering-space for
>>>>>>> such
>>>>>>> +services. Put another way, the numbering scheme for I2C buses is
>>>>>>> distinct from
>>>>>>> +the numbering scheme for any other service the BPMP may provide
>>>>>>> (e.g. a
>>>>>>> future
>>>>>>> +hypothetical SPI bus service). As such, child device nodes will have
>>>>>>> no
>>>>>>> reg
>>>>>>> +property, and the BPMP node will have no #address-cells or
>>>>>>> #size-cells
>>>>>>> property.
>>>>>>
>>>>>>
>>>>>>
>>>>>> My understanding is that the I2C bus number is passed as part of the
>>>>>> request to the BPMP firmware. Does that not count as addressing? Could
>>>>>> we not represent that generically using a device tree hierarchy? I'm
>>>>>> thinking something along these lines:
>>>>>>
>>>>>>         bpmp {
>>>>>>                 ...
>>>>>>
>>>>>>                 services {
>>>>>>                         i2c {
>>>>>>                                 i2c at 0 {
>>>>>>                                         reg = <0>;
>>>>>
>>>>>
>>>>>
>>>>> Technically, that is possible. However, Rob Herring rejected the idea
>>>>> of
>>>>> multiple levels of sub-nodes.
>>>>
>>>>
>>>> I think I questioned the need, not rejected. What about the above, but
>>>> remove serivces level:
>>>>
>>>>          bpmp {
>>>>                  ...
>>>>
>>>>                  i2c {
>>>>                          i2c at 0 {
>>>>                                  reg = <0>;
>>>
>>>
>>> Sigh. Can you please talk to Thierry and work out what the binding would
>>> be
>>> (perhaps on IRC to expedite things?) and I'll just implement whatever you
>>> two agree upon. I don't really care much what the binding looks like any
>>> more; I just need something that will pass review. Thanks.
>>
>>
>> Like I said, I'm fine going with what you proposed.
>
>
> OK, great. For the record, I'm going to send U-Boot patches today that apply
> this binding patch (the original one I sent, unmodified) to the U-Boot tree,
> and implement it in the U-Boot driver.

That's fine, I did ack that.

I really don't want to ask, but why are you documenting in u-boot? Is
it some how different for u-boot?

Rob

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/29/2016 02:28 PM, Rob Herring wrote:
> On Fri, Jul 29, 2016 at 11:06 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>> On 07/29/2016 07:48 AM, Thierry Reding wrote:
>>>
>>> On Thu, Jul 28, 2016 at 03:24:22PM -0600, Stephen Warren wrote:
>>>>
>>>> On 07/28/2016 01:07 PM, Rob Herring wrote:
>>>>>
>>>>> On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
>>>>> wrote:
>>>>>>
>>>>>> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>>>>
>>>>>>>> The BPMP implements some services which must be represented by
>>>>>>>> separate
>>>>>>>> nodes. For example, it can provide access to certain I2C controllers,
>>>>>>>> and
>>>>>>>> the I2C bindings represent each I2C controller as a device tree node.
>>>>>>>> Update the binding to describe how the BPMP supports this.
>>>>>>>>
>>>>>>>> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>>>> ---
>>>>>>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>>>>>>> ++++++++++++++++++++++
>>>>>>>>  1 file changed, 23 insertions(+)
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>>> index 9a3864f56955..142d363406f6 100644
>>>>>>>> ---
>>>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>>> +++
>>>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>>>>>>  - .../reset/reset.txt
>>>>>>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>>>>>>
>>>>>>>> +The BPMP implements some services which must be represented by
>>>>>>>> separate
>>>>>>>> nodes.
>>>>>>>> +For example, it can provide access to certain I2C controllers, and
>>>>>>>> the
>>>>>>>> I2C
>>>>>>>> +bindings represent each I2C controller as a device tree node. Such
>>>>>>>> nodes
>>>>>>>> should
>>>>>>>> +be nested directly inside the main BPMP node.
>>>>>>>> +
>>>>>>>> +Software can determine whether a child node of the BPMP node
>>>>>>>> represents
>>>>>>>> a device
>>>>>>>> +by checking for a compatible property. Any node with a compatible
>>>>>>>> property
>>>>>>>> +represents a device that can be instantiated. Nodes without a
>>>>>>>> compatible
>>>>>>>> +property may be used to provide configuration information regarding
>>>>>>>> the
>>>>>>>> BPMP
>>>>>>>> +itself, although no such configuration nodes are currently defined
>>>>>>>> by
>>>>>>>> this
>>>>>>>> +binding.
>>>>>>>> +
>>>>>>>> +The BPMP firmware defines no single global name-/numbering-space for
>>>>>>>> such
>>>>>>>> +services. Put another way, the numbering scheme for I2C buses is
>>>>>>>> distinct from
>>>>>>>> +the numbering scheme for any other service the BPMP may provide
>>>>>>>> (e.g. a
>>>>>>>> future
>>>>>>>> +hypothetical SPI bus service). As such, child device nodes will have
>>>>>>>> no
>>>>>>>> reg
>>>>>>>> +property, and the BPMP node will have no #address-cells or
>>>>>>>> #size-cells
>>>>>>>> property.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My understanding is that the I2C bus number is passed as part of the
>>>>>>> request to the BPMP firmware. Does that not count as addressing? Could
>>>>>>> we not represent that generically using a device tree hierarchy? I'm
>>>>>>> thinking something along these lines:
>>>>>>>
>>>>>>>         bpmp {
>>>>>>>                 ...
>>>>>>>
>>>>>>>                 services {
>>>>>>>                         i2c {
>>>>>>>                                 i2c@0 {
>>>>>>>                                         reg = <0>;
>>>>>>
>>>>>>
>>>>>>
>>>>>> Technically, that is possible. However, Rob Herring rejected the idea
>>>>>> of
>>>>>> multiple levels of sub-nodes.
>>>>>
>>>>>
>>>>> I think I questioned the need, not rejected. What about the above, but
>>>>> remove serivces level:
>>>>>
>>>>>          bpmp {
>>>>>                  ...
>>>>>
>>>>>                  i2c {
>>>>>                          i2c@0 {
>>>>>                                  reg = <0>;
>>>>
>>>>
>>>> Sigh. Can you please talk to Thierry and work out what the binding would
>>>> be
>>>> (perhaps on IRC to expedite things?) and I'll just implement whatever you
>>>> two agree upon. I don't really care much what the binding looks like any
>>>> more; I just need something that will pass review. Thanks.
>>>
>>>
>>> Like I said, I'm fine going with what you proposed.
>>
>>
>> OK, great. For the record, I'm going to send U-Boot patches today that apply
>> this binding patch (the original one I sent, unmodified) to the U-Boot tree,
>> and implement it in the U-Boot driver.
>
> That's fine, I did ack that.
>
> I really don't want to ask, but why are you documenting in u-boot? Is
> it some how different for u-boot?

There's a copy of the DT binding documents in U-Boot as well. At least 
for the bindings I deal with, they should be the same, although the 
U-Boot copies might get stale as hopefully-backwards-compatible 
enhancements are made to the kernel versions.

I'm implementing a U-Boot driver for this new feature, so am copying 
these new binding docs into the U-Boot DT binding docs directory too.

I'd be happy personally not to have another copy of the bindings, and 
just tell people to refer to the docs in the kernel, or any other 
canonical source, but that's not my call.

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Stephen Warren]

On 07/29/2016 02:28 PM, Rob Herring wrote:
> On Fri, Jul 29, 2016 at 11:06 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/29/2016 07:48 AM, Thierry Reding wrote:
>>>
>>> On Thu, Jul 28, 2016 at 03:24:22PM -0600, Stephen Warren wrote:
>>>>
>>>> On 07/28/2016 01:07 PM, Rob Herring wrote:
>>>>>
>>>>> On Tue, Jul 26, 2016 at 11:21 AM, Stephen Warren <swarren@wwwdotorg.org>
>>>>> wrote:
>>>>>>
>>>>>> On 07/26/2016 04:03 AM, Thierry Reding wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> From: Stephen Warren <swarren@nvidia.com>
>>>>>>>>
>>>>>>>> The BPMP implements some services which must be represented by
>>>>>>>> separate
>>>>>>>> nodes. For example, it can provide access to certain I2C controllers,
>>>>>>>> and
>>>>>>>> the I2C bindings represent each I2C controller as a device tree node.
>>>>>>>> Update the binding to describe how the BPMP supports this.
>>>>>>>>
>>>>>>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>>>>>>> ---
>>>>>>>>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23
>>>>>>>> ++++++++++++++++++++++
>>>>>>>>  1 file changed, 23 insertions(+)
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>>> index 9a3864f56955..142d363406f6 100644
>>>>>>>> ---
>>>>>>>> a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>>> +++
>>>>>>>> b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
>>>>>>>> @@ -38,6 +38,24 @@ implemented by this node:
>>>>>>>>  - .../reset/reset.txt
>>>>>>>>  - <dt-bindings/reset/tegra186-reset.h>
>>>>>>>>
>>>>>>>> +The BPMP implements some services which must be represented by
>>>>>>>> separate
>>>>>>>> nodes.
>>>>>>>> +For example, it can provide access to certain I2C controllers, and
>>>>>>>> the
>>>>>>>> I2C
>>>>>>>> +bindings represent each I2C controller as a device tree node. Such
>>>>>>>> nodes
>>>>>>>> should
>>>>>>>> +be nested directly inside the main BPMP node.
>>>>>>>> +
>>>>>>>> +Software can determine whether a child node of the BPMP node
>>>>>>>> represents
>>>>>>>> a device
>>>>>>>> +by checking for a compatible property. Any node with a compatible
>>>>>>>> property
>>>>>>>> +represents a device that can be instantiated. Nodes without a
>>>>>>>> compatible
>>>>>>>> +property may be used to provide configuration information regarding
>>>>>>>> the
>>>>>>>> BPMP
>>>>>>>> +itself, although no such configuration nodes are currently defined
>>>>>>>> by
>>>>>>>> this
>>>>>>>> +binding.
>>>>>>>> +
>>>>>>>> +The BPMP firmware defines no single global name-/numbering-space for
>>>>>>>> such
>>>>>>>> +services. Put another way, the numbering scheme for I2C buses is
>>>>>>>> distinct from
>>>>>>>> +the numbering scheme for any other service the BPMP may provide
>>>>>>>> (e.g. a
>>>>>>>> future
>>>>>>>> +hypothetical SPI bus service). As such, child device nodes will have
>>>>>>>> no
>>>>>>>> reg
>>>>>>>> +property, and the BPMP node will have no #address-cells or
>>>>>>>> #size-cells
>>>>>>>> property.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My understanding is that the I2C bus number is passed as part of the
>>>>>>> request to the BPMP firmware. Does that not count as addressing? Could
>>>>>>> we not represent that generically using a device tree hierarchy? I'm
>>>>>>> thinking something along these lines:
>>>>>>>
>>>>>>>         bpmp {
>>>>>>>                 ...
>>>>>>>
>>>>>>>                 services {
>>>>>>>                         i2c {
>>>>>>>                                 i2c at 0 {
>>>>>>>                                         reg = <0>;
>>>>>>
>>>>>>
>>>>>>
>>>>>> Technically, that is possible. However, Rob Herring rejected the idea
>>>>>> of
>>>>>> multiple levels of sub-nodes.
>>>>>
>>>>>
>>>>> I think I questioned the need, not rejected. What about the above, but
>>>>> remove serivces level:
>>>>>
>>>>>          bpmp {
>>>>>                  ...
>>>>>
>>>>>                  i2c {
>>>>>                          i2c at 0 {
>>>>>                                  reg = <0>;
>>>>
>>>>
>>>> Sigh. Can you please talk to Thierry and work out what the binding would
>>>> be
>>>> (perhaps on IRC to expedite things?) and I'll just implement whatever you
>>>> two agree upon. I don't really care much what the binding looks like any
>>>> more; I just need something that will pass review. Thanks.
>>>
>>>
>>> Like I said, I'm fine going with what you proposed.
>>
>>
>> OK, great. For the record, I'm going to send U-Boot patches today that apply
>> this binding patch (the original one I sent, unmodified) to the U-Boot tree,
>> and implement it in the U-Boot driver.
>
> That's fine, I did ack that.
>
> I really don't want to ask, but why are you documenting in u-boot? Is
> it some how different for u-boot?

There's a copy of the DT binding documents in U-Boot as well. At least 
for the bindings I deal with, they should be the same, although the 
U-Boot copies might get stale as hopefully-backwards-compatible 
enhancements are made to the kernel versions.

I'm implementing a U-Boot driver for this new feature, so am copying 
these new binding docs into the U-Boot DT binding docs directory too.

I'd be happy personally not to have another copy of the bindings, and 
just tell people to refer to the docs in the kernel, or any other 
canonical source, but that's not my call.

Re: [PATCH 1/3] dt-bindings: add power domains to Tegra BPMP firmware

[Thierry Reding]

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

On Tue, Jul 19, 2016 at 01:14:40PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> The Tegra186 BPMP is also a provider of power domains. Enhance the device
> tree binding to describe this.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> These patches all build on top of Joseph Lo's baseline BPMP binding patches[1]
> and enhance them to represent a few more features of the firmware.
> 
> [1] https://lkml.org/lkml/2016/7/19/280
> "[PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox"
> 
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 10 ++++--
>  include/dt-bindings/power/tegra186-powergate.h     | 39 ++++++++++++++++++++++
>  2 files changed, 46 insertions(+), 3 deletions(-)
>  create mode 100644 include/dt-bindings/power/tegra186-powergate.h

Applied, thanks.

One small comment below...

> diff --git a/include/dt-bindings/power/tegra186-powergate.h b/include/dt-bindings/power/tegra186-powergate.h
> new file mode 100644
> index 000000000000..388d6e228dc8
> --- /dev/null
> +++ b/include/dt-bindings/power/tegra186-powergate.h
> @@ -0,0 +1,39 @@
> +/*
> + * Copyright (c) 2015-2016, NVIDIA CORPORATION.  All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
> +#define _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
> +
> +#define TEGRA186_POWER_DOMAIN_AUD	0
> +#define TEGRA186_POWER_DOMAIN_DFD	1
> +#define TEGRA186_POWER_DOMAIN_DISP	2
> +#define TEGRA186_POWER_DOMAIN_DISPB	3
> +#define TEGRA186_POWER_DOMAIN_DISPC	4
> +#define TEGRA186_POWER_DOMAIN_ISPA	5
> +#define TEGRA186_POWER_DOMAIN_NVDEC	6
> +#define TEGRA186_POWER_DOMAIN_NVJPG	7
> +#define TEGRA186_POWER_DOMAIN_MPE	8
> +#define TEGRA186_POWER_DOMAIN_PCX	9
> +#define TEGRA186_POWER_DOMAIN_SAX	10
> +#define TEGRA186_POWER_DOMAIN_VE	11
> +#define TEGRA186_POWER_DOMAIN_VIC	12
> +#define TEGRA186_POWER_DOMAIN_XUSBA	13
> +#define TEGRA186_POWER_DOMAIN_XUSBB	14
> +#define TEGRA186_POWER_DOMAIN_XUSBC	15
> +#define TEGRA186_POWER_DOMAIN_GPU	43
> +#define TEGRA186_POWER_DOMAIN_MAX	44

It's slightly odd that these are named TEGRA186_POWER_DOMAIN_* since
power domain is a Linuxism. All documentation that I've seen calls these
powergates.

I guess since this is now ABI there is not much we can do to rectify it.

Thierry

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

[PATCH 1/3] dt-bindings: add power domains to Tegra BPMP firmware

[Thierry Reding]

On Tue, Jul 19, 2016 at 01:14:40PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> The Tegra186 BPMP is also a provider of power domains. Enhance the device
> tree binding to describe this.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> These patches all build on top of Joseph Lo's baseline BPMP binding patches[1]
> and enhance them to represent a few more features of the firmware.
> 
> [1] https://lkml.org/lkml/2016/7/19/280
> "[PATCH V3 01/10] Documentation: dt-bindings: mailbox: tegra: Add binding for HSP mailbox"
> 
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 10 ++++--
>  include/dt-bindings/power/tegra186-powergate.h     | 39 ++++++++++++++++++++++
>  2 files changed, 46 insertions(+), 3 deletions(-)
>  create mode 100644 include/dt-bindings/power/tegra186-powergate.h

Applied, thanks.

One small comment below...

> diff --git a/include/dt-bindings/power/tegra186-powergate.h b/include/dt-bindings/power/tegra186-powergate.h
> new file mode 100644
> index 000000000000..388d6e228dc8
> --- /dev/null
> +++ b/include/dt-bindings/power/tegra186-powergate.h
> @@ -0,0 +1,39 @@
> +/*
> + * Copyright (c) 2015-2016, NVIDIA CORPORATION.  All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
> +#define _DT_BINDINGS_POWER_TEGRA186_POWERGATE_H
> +
> +#define TEGRA186_POWER_DOMAIN_AUD	0
> +#define TEGRA186_POWER_DOMAIN_DFD	1
> +#define TEGRA186_POWER_DOMAIN_DISP	2
> +#define TEGRA186_POWER_DOMAIN_DISPB	3
> +#define TEGRA186_POWER_DOMAIN_DISPC	4
> +#define TEGRA186_POWER_DOMAIN_ISPA	5
> +#define TEGRA186_POWER_DOMAIN_NVDEC	6
> +#define TEGRA186_POWER_DOMAIN_NVJPG	7
> +#define TEGRA186_POWER_DOMAIN_MPE	8
> +#define TEGRA186_POWER_DOMAIN_PCX	9
> +#define TEGRA186_POWER_DOMAIN_SAX	10
> +#define TEGRA186_POWER_DOMAIN_VE	11
> +#define TEGRA186_POWER_DOMAIN_VIC	12
> +#define TEGRA186_POWER_DOMAIN_XUSBA	13
> +#define TEGRA186_POWER_DOMAIN_XUSBB	14
> +#define TEGRA186_POWER_DOMAIN_XUSBC	15
> +#define TEGRA186_POWER_DOMAIN_GPU	43
> +#define TEGRA186_POWER_DOMAIN_MAX	44

It's slightly odd that these are named TEGRA186_POWER_DOMAIN_* since
power domain is a Linuxism. All documentation that I've seen calls these
powergates.

I guess since this is now ABI there is not much we can do to rectify it.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161115/23dffb84/attachment.sig>

Re: [PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Thierry Reding]

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

On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> The BPMP implements some services which must be represented by separate
> nodes. For example, it can provide access to certain I2C controllers, and
> the I2C bindings represent each I2C controller as a device tree node.
> Update the binding to describe how the BPMP supports this.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)

Applied, with bpmp-i2c changed to i2c as per Rob's comment.

Thanks,
Thierry

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

[PATCH 2/3] dt-bindings: allow child nodes inside the Tegra BPMP

[Thierry Reding]

On Tue, Jul 19, 2016 at 01:14:41PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> The BPMP implements some services which must be represented by separate
> nodes. For example, it can provide access to certain I2C controllers, and
> the I2C bindings represent each I2C controller as a device tree node.
> Update the binding to describe how the BPMP supports this.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
>  .../bindings/firmware/nvidia,tegra186-bpmp.txt     | 23 ++++++++++++++++++++++
>  1 file changed, 23 insertions(+)

Applied, with bpmp-i2c changed to i2c as per Rob's comment.

Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161115/3518be8e/attachment.sig>

Re: [PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Thierry Reding]

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

On Tue, Jul 19, 2016 at 01:14:42PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
> HW devices, such as the I2C controller for the power management I2C bus.
> Software running on other CPUs must perform IPC to the BPMP in order to
> execute transactions on that I2C bus. This binding describes an I2C bus
> that is accessed in such a fashion.
> 
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
>  .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt

I ended up cherry-picking this commit from U-Boot, which already had
both of the comments addressed that were discussed here. I also took the
liberty of adding Jon's Acked-by from this thread since it's effectively
the same commit.

Thanks,
Thierry

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

[PATCH 3/3] dt-bindings: add Tegra186 BPMP I2C binding

[Thierry Reding]

On Tue, Jul 19, 2016 at 01:14:42PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> In Tegra186, the BPMP (Boot and Power Management Processor) owns certain
> HW devices, such as the I2C controller for the power management I2C bus.
> Software running on other CPUs must perform IPC to the BPMP in order to
> execute transactions on that I2C bus. This binding describes an I2C bus
> that is accessed in such a fashion.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
>  .../bindings/i2c/nvidia,tegra186-bpmp-i2c.txt      | 42 ++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt

I ended up cherry-picking this commit from U-Boot, which already had
both of the comments addressed that were discussed here. I also took the
liberty of adding Jon's Acked-by from this thread since it's effectively
the same commit.

Thanks,
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161115/27395f3b/attachment.sig>