* [PATCH 01/38] dt-bindings: interrupt-controller: arm,gic: Add compatible for Tegra186 AGIC
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 02/38] dt-bindings: memory: nvidia: Mark memory controller as interconnect provider Thierry Reding
` (36 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The AGIC variant of GIC found in the audio subsystem of NVIDIA Tegra186
SoCs is mostly compatible with the version found on Tegra210. Provide a
Tegra210 compatible as a fallback compatible, but also require a
Tegra186 specific compatible for forwards compatibility in case there's
ever a need to implement instantiation-specific quirks.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/interrupt-controller/arm,gic.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
index 96f8803ff4e6..becc4364e419 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
@@ -53,6 +53,13 @@ properties:
- const: brcm,brahma-b15-gic
- const: arm,cortex-a15-gic
+ - items:
+ - enum:
+ - nvidia,tegra186-agic
+ - nvidia,tegra194-agic
+ - enum:
+ - nvidia,tegra210-agic
+
interrupt-controller: true
"#address-cells":
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 02/38] dt-bindings: memory: nvidia: Mark memory controller as interconnect provider
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
2020-06-12 14:18 ` [PATCH 01/38] dt-bindings: interrupt-controller: arm,gic: Add compatible for Tegra186 AGIC Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 03/38] dt-bindings: memory: Increase number of reg entries on Tegra194 Thierry Reding
` (35 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../memory-controllers/nvidia,tegra186-mc.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
index 611bda38d187..581572fe3077 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
@@ -38,6 +38,16 @@ properties:
interrupts:
maxItems: 1
+ "#interconnect-cells":
+ const: 1
+ description:
+ Each interconnect node for the memory controller takes a phandle to the
+ memory controller and a single cell as the specifier, identifying the
+ memory client by its ID.
+
+ For a list of valid IDs, see dt-bindings/memory/tegra186-mc.h and
+ dt-bindings/memory/tegra194-mc.h.
+
"#address-cells":
const: 2
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 03/38] dt-bindings: memory: Increase number of reg entries on Tegra194
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
2020-06-12 14:18 ` [PATCH 01/38] dt-bindings: interrupt-controller: arm,gic: Add compatible for Tegra186 AGIC Thierry Reding
2020-06-12 14:18 ` [PATCH 02/38] dt-bindings: memory: nvidia: Mark memory controller as interconnect provider Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 04/38] dt-bindings: firmware: Convert Tegra186 BPMP bindings to json-schema Thierry Reding
` (34 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The memory controller and external memory controller control multiple
channels that require additional register ranges. Allow the number of
ranges to be up to 3 or 2 for the memory controller and the external
memory controller, respectively.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../nvidia,tegra186-mc.yaml | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
index 581572fe3077..774b04d0da0d 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
@@ -102,6 +102,31 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra194-mc
+ then:
+ properties:
+ reg:
+ maxItems: 3
+
+ - if:
+ patternProperties:
+ "^external-memory-controller@[0-9a-f]+$":
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra194-emc
+ then:
+ patternProperties:
+ "^external-memory-controller@[0-9a-f]+$":
+ properties:
+ reg:
+ maxItems: 2
+
examples:
- |
#include <dt-bindings/clock/tegra186-clock.h>
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 04/38] dt-bindings: firmware: Convert Tegra186 BPMP bindings to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (2 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 03/38] dt-bindings: memory: Increase number of reg entries on Tegra194 Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-17 22:49 ` Rob Herring
2020-06-12 14:18 ` [PATCH 05/38] dt-bindings: firmware: tegra186-bpmp: Document interconnect paths Thierry Reding
` (33 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Tegra186 BPMP bindings from the free-form text format to a
json-schema and fix things up so that existing device trees properly
validate.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../firmware/nvidia,tegra186-bpmp.txt | 107 -----------
.../firmware/nvidia,tegra186-bpmp.yaml | 180 ++++++++++++++++++
2 files changed, 180 insertions(+), 107 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
create mode 100644 Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
deleted file mode 100644
index e44a13bc06ed..000000000000
--- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
+++ /dev/null
@@ -1,107 +0,0 @@
-NVIDIA Tegra Boot and Power Management Processor (BPMP)
-
-The BPMP is a specific processor in Tegra chip, which is designed for
-booting process handling and offloading the power management, clock
-management, and reset control tasks from the CPU. The binding document
-defines the resources that would be used by the BPMP firmware driver,
-which can create the interprocessor communication (IPC) between the CPU
-and BPMP.
-
-Required properties:
-- compatible
- Array of strings
- One of:
- - "nvidia,tegra186-bpmp"
-- mboxes : The phandle of mailbox controller and the mailbox specifier.
-- 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
-the mailbox subsystem, and the specifiers implemented by the relevant
-provider(s):
-
-- .../mailbox/mailbox.txt
-- .../mailbox/nvidia,tegra186-hsp.txt
-
-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.yaml
-- <dt-bindings/power/tegra186-powergate.h>
-- .../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
------------------------------------
-
-The shared memory area for the IPC TX and RX between CPU and BPMP are
-predefined and work on top of sysram, which is an SRAM inside the chip.
-
-See ".../sram/sram.txt" for the bindings.
-
-Example:
-
-hsp_top0: hsp@3c00000 {
- ...
- #mbox-cells = <2>;
-};
-
-sysram@30000000 {
- compatible = "nvidia,tegra186-sysram", "mmio-sram";
- reg = <0x0 0x30000000 0x0 0x50000>;
- #address-cells = <2>;
- #size-cells = <2>;
- ranges = <0 0x0 0x0 0x30000000 0x0 0x50000>;
-
- cpu_bpmp_tx: shmem@4e000 {
- compatible = "nvidia,tegra186-bpmp-shmem";
- reg = <0x0 0x4e000 0x0 0x1000>;
- label = "cpu-bpmp-tx";
- pool;
- };
-
- cpu_bpmp_rx: shmem@4f000 {
- compatible = "nvidia,tegra186-bpmp-shmem";
- reg = <0x0 0x4f000 0x0 0x1000>;
- label = "cpu-bpmp-rx";
- pool;
- };
-};
-
-bpmp {
- compatible = "nvidia,tegra186-bpmp";
- mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
- shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
- #clock-cells = <1>;
- #power-domain-cells = <1>;
- #reset-cells = <1>;
-
- i2c {
- compatible = "...";
- ...
- };
-};
diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
new file mode 100644
index 000000000000..0e4d51ba7aa1
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/nvidia,tegra186-bpmp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra186 (and later) Boot and Power Management Processor (BPMP)
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The BPMP is a specific processor in Tegra chip, which is designed for
+ booting process handling and offloading the power management, clock
+ management, and reset control tasks from the CPU. The binding document
+ defines the resources that would be used by the BPMP firmware driver,
+ which can create the interprocessor communication (IPC) between the
+ CPU and BPMP.
+
+ 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.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nvidia,tegra186-bpmp
+
+ iommus:
+ description: |
+ The phandle of the IOMMU and the IOMMU specifier. See ../iommu/iommu.txt
+ for details.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ mboxes:
+ description: |
+ The phandle of the mailbox controller and the mailbox specifier. See
+ ../mailbox/mailbox.txt and ../mailbox/nvidia,tegra186-hsp.txt for
+ details.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ shmem:
+ description: |
+ List of phandles for the TX and RX shared memory areas used for
+ interprocess communication between the CPU and the BPMP.
+
+ The shared memory area for the IPC TX and RX between CPU and BPMP are
+ predefined and work on top of sysram, which is an SRAM inside the chip.
+
+ See ../sram/sram.yaml for the bindings.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ "#clock-cells":
+ const: 1
+
+ "#power-domain-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ i2c:
+ type: object
+ description: |
+ The BPMP can provide serialized access to I2C controllers that have
+ been assigned to it.
+
+ properties:
+ compatible:
+ items:
+ - enum:
+ - nvidia,tegra186-bpmp-i2c
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ nvidia,bpmp-bus-id:
+ description: The bus ID of the I2C controller.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - nvidia,bpmp-bus-id
+
+ patternProperties:
+ "^.*@[0-9a-f]+$":
+ type: object
+ description: I2C slave
+ properties:
+ reg:
+ maxItems: 1
+ description: I2C address of the slave
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+ thermal:
+ type: object
+ description:
+ The BPMP provides functionality that exposes system temperature sensors
+ and which can be used to trigger a system shutdown if the temperature
+ for a given zone exceeds the specified thresholds.
+
+ properties:
+ compatible:
+ items:
+ - enum:
+ - nvidia,tegra186-bpmp-thermal
+
+ "#thermal-sensor-cells":
+ description: The ID of the thermal zone.
+ const: 1
+
+ required:
+ - compatible
+ - "#thermal-sensor-cells"
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - mboxes
+ - shmem
+ - "#clock-cells"
+ - "#power-domain-cells"
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/mailbox/tegra186-hsp.h>
+ #include <dt-bindings/memory/tegra186-mc.h>
+
+ bpmp {
+ compatible = "nvidia,tegra186-bpmp";
+ iommus = <&smmu TEGRA186_SID_BPMP>;
+ mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
+ shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
+ #clock-cells = <1>;
+ #power-domain-cells = <1>;
+ #reset-cells = <1>;
+
+ i2c {
+ compatible = "nvidia,tegra186-bpmp-i2c";
+ nvidia,bpmp-bus-id = <5>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ thermal {
+ compatible = "nvidia,tegra186-bpmp-thermal";
+ #thermal-sensor-cells = <1>;
+ };
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 04/38] dt-bindings: firmware: Convert Tegra186 BPMP bindings to json-schema
2020-06-12 14:18 ` [PATCH 04/38] dt-bindings: firmware: Convert Tegra186 BPMP bindings to json-schema Thierry Reding
@ 2020-06-17 22:49 ` Rob Herring
0 siblings, 0 replies; 76+ messages in thread
From: Rob Herring @ 2020-06-17 22:49 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:18:29PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the Tegra186 BPMP bindings from the free-form text format to a
> json-schema and fix things up so that existing device trees properly
> validate.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../firmware/nvidia,tegra186-bpmp.txt | 107 -----------
> .../firmware/nvidia,tegra186-bpmp.yaml | 180 ++++++++++++++++++
> 2 files changed, 180 insertions(+), 107 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt
> create mode 100644 Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
[...]
> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
> new file mode 100644
> index 000000000000..0e4d51ba7aa1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
> @@ -0,0 +1,180 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/nvidia,tegra186-bpmp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra186 (and later) Boot and Power Management Processor (BPMP)
> +
> +maintainers:
> + - Thierry Reding <thierry.reding@gmail.com>
> + - Jon Hunter <jonathanh@nvidia.com>
> +
> +description: |
> + The BPMP is a specific processor in Tegra chip, which is designed for
> + booting process handling and offloading the power management, clock
> + management, and reset control tasks from the CPU. The binding document
> + defines the resources that would be used by the BPMP firmware driver,
> + which can create the interprocessor communication (IPC) between the
> + CPU and BPMP.
> +
> + 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.
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - nvidia,tegra186-bpmp
> +
> + iommus:
> + description: |
> + The phandle of the IOMMU and the IOMMU specifier. See ../iommu/iommu.txt
> + for details.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
Standard property, don't need a type. Just 'maxItems: 1' if 1 entry or
an 'items' list if more than 1.
> +
> + mboxes:
> + description: |
> + The phandle of the mailbox controller and the mailbox specifier. See
> + ../mailbox/mailbox.txt and ../mailbox/nvidia,tegra186-hsp.txt for
> + details.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
Same here.
> +
> + shmem:
> + description: |
> + List of phandles for the TX and RX shared memory areas used for
> + interprocess communication between the CPU and the BPMP.
> +
> + The shared memory area for the IPC TX and RX between CPU and BPMP are
> + predefined and work on top of sysram, which is an SRAM inside the chip.
> +
> + See ../sram/sram.yaml for the bindings.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + "#clock-cells":
> + const: 1
> +
> + "#power-domain-cells":
> + const: 1
> +
> + "#reset-cells":
> + const: 1
> +
> + i2c:
> + type: object
> + description: |
> + The BPMP can provide serialized access to I2C controllers that have
> + been assigned to it.
Should have a $ref to i2c-controller.yaml
> +
> + properties:
> + compatible:
> + items:
> + - enum:
> + - nvidia,tegra186-bpmp-i2c
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + nvidia,bpmp-bus-id:
> + description: The bus ID of the I2C controller.
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> +
> + required:
> + - compatible
> + - "#address-cells"
> + - "#size-cells"
> + - nvidia,bpmp-bus-id
> +
> + patternProperties:
> + "^.*@[0-9a-f]+$":
> + type: object
> + description: I2C slave
> + properties:
> + reg:
> + maxItems: 1
> + description: I2C address of the slave
> +
> + required:
> + - reg
And child node schema can be dropped.
> +
> + additionalProperties: false
> +
> + thermal:
> + type: object
> + description:
> + The BPMP provides functionality that exposes system temperature sensors
> + and which can be used to trigger a system shutdown if the temperature
> + for a given zone exceeds the specified thresholds.
> +
> + properties:
> + compatible:
> + items:
> + - enum:
> + - nvidia,tegra186-bpmp-thermal
> +
> + "#thermal-sensor-cells":
> + description: The ID of the thermal zone.
> + const: 1
> +
> + required:
> + - compatible
> + - "#thermal-sensor-cells"
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - mboxes
> + - shmem
> + - "#clock-cells"
> + - "#power-domain-cells"
> + - "#reset-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/mailbox/tegra186-hsp.h>
> + #include <dt-bindings/memory/tegra186-mc.h>
> +
> + bpmp {
> + compatible = "nvidia,tegra186-bpmp";
> + iommus = <&smmu TEGRA186_SID_BPMP>;
> + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
> + shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
> + #clock-cells = <1>;
> + #power-domain-cells = <1>;
> + #reset-cells = <1>;
> +
> + i2c {
> + compatible = "nvidia,tegra186-bpmp-i2c";
> + nvidia,bpmp-bus-id = <5>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
Don't show status in examples.
> + };
> +
> + thermal {
> + compatible = "nvidia,tegra186-bpmp-thermal";
> + #thermal-sensor-cells = <1>;
> + };
> + };
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 05/38] dt-bindings: firmware: tegra186-bpmp: Document interconnect paths
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (3 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 04/38] dt-bindings: firmware: Convert Tegra186 BPMP bindings to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-17 22:50 ` Rob Herring
2020-06-12 14:18 ` [PATCH 06/38] dt-bindings: display: tegra: Document display-hub Thierry Reding
` (32 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Document the interconnects property that is used to describe the paths
from and to system memory from and to the BPMP.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../firmware/nvidia,tegra186-bpmp.yaml | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
index 0e4d51ba7aa1..fd642eeb8dde 100644
--- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
+++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
@@ -43,6 +43,21 @@ properties:
- enum:
- nvidia,tegra186-bpmp
+ interconnects:
+ description: A list of phandle and specifier pairs that describe the
+ interconnect paths to and from the BPMP.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ interconnect-names:
+ description: One string for each pair of phandle and specifier in the
+ "interconnects" property.
+ $ref: "/schemas/types.yaml#/definitions/string-array"
+ items:
+ - const: read
+ - const: write
+ - const: dma-mem # dma-read
+ - const: dma-write
+
iommus:
description: |
The phandle of the IOMMU and the IOMMU specifier. See ../iommu/iommu.txt
@@ -158,6 +173,12 @@ examples:
bpmp {
compatible = "nvidia,tegra186-bpmp";
+ interconnects = <&mc TEGRA186_MEMORY_CLIENT_BPMPR &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_BPMPW &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAR &emc>,
+ <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>;
+ interconnect-names = "read", "write", "dma-mem", "dma-write";
+
iommus = <&smmu TEGRA186_SID_BPMP>;
mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 05/38] dt-bindings: firmware: tegra186-bpmp: Document interconnect paths
2020-06-12 14:18 ` [PATCH 05/38] dt-bindings: firmware: tegra186-bpmp: Document interconnect paths Thierry Reding
@ 2020-06-17 22:50 ` Rob Herring
0 siblings, 0 replies; 76+ messages in thread
From: Rob Herring @ 2020-06-17 22:50 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:18:30PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Document the interconnects property that is used to describe the paths
> from and to system memory from and to the BPMP.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../firmware/nvidia,tegra186-bpmp.yaml | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
> index 0e4d51ba7aa1..fd642eeb8dde 100644
> --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
> +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml
> @@ -43,6 +43,21 @@ properties:
> - enum:
> - nvidia,tegra186-bpmp
>
> + interconnects:
> + description: A list of phandle and specifier pairs that describe the
> + interconnect paths to and from the BPMP.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
Again, don't re-define standard properties.
> +
> + interconnect-names:
> + description: One string for each pair of phandle and specifier in the
> + "interconnects" property.
> + $ref: "/schemas/types.yaml#/definitions/string-array"
> + items:
> + - const: read
> + - const: write
> + - const: dma-mem # dma-read
> + - const: dma-write
> +
> iommus:
> description: |
> The phandle of the IOMMU and the IOMMU specifier. See ../iommu/iommu.txt
> @@ -158,6 +173,12 @@ examples:
>
> bpmp {
> compatible = "nvidia,tegra186-bpmp";
> + interconnects = <&mc TEGRA186_MEMORY_CLIENT_BPMPR &emc>,
> + <&mc TEGRA186_MEMORY_CLIENT_BPMPW &emc>,
> + <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAR &emc>,
> + <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>;
> + interconnect-names = "read", "write", "dma-mem", "dma-write";
> +
> iommus = <&smmu TEGRA186_SID_BPMP>;
> mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>;
> shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>;
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 06/38] dt-bindings: display: tegra: Document display-hub
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (4 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 05/38] dt-bindings: firmware: tegra186-bpmp: Document interconnect paths Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-17 22:55 ` Rob Herring
2020-06-12 14:18 ` [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema Thierry Reding
` (31 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Tegra186 and later have an additional component in the display pipeline
called the display hub. Document the bindings which were missing.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../display/tegra/nvidia,tegra20-host1x.txt | 50 +++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index 47319214b5f6..2cf3cc4893da 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -297,6 +297,56 @@ of the following host1x client modules:
- reset-names: Must include the following entries:
- vic
+- display-hub: display controller hub
+ Required properties:
+ - compatible: "nvidia,tegra<chip>-display"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - disp
+ - dsc
+ - hub
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - misc
+ - wgrp0
+ - wgrp1
+ - wgrp2
+ - wgrp3
+ - wgrp4
+ - wgrp5
+ - power-domains: A list of phandle and specifiers identifying the power
+ domains that the display hub is part of.
+ - ranges: Range of registers used for the display controllers.
+
+ Each subnode of the display hub represents one of the display controllers
+ available:
+
+ - display: display controller
+ - compatible: "nvidia,tegra<chip>-dc"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: The interrupt outputs from the controller.
+ - clocks: Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+ - dc
+ - resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+ - dc
+ - power-domains: A list of phandle and specifiers that identify the power
+ domains that this display controller is part of.
+ - iommus: A phandle and specifier identifying the SMMU master interface of
+ this display controller.
+ - nvidia,outputs: A list of phandles of outputs that this display
+ controller can drive.
+ - nvidia,head: The number of the display controller head. This is used to
+ setup the various types of output to receive video data from the given
+ head.
+
Example:
/ {
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 06/38] dt-bindings: display: tegra: Document display-hub
2020-06-12 14:18 ` [PATCH 06/38] dt-bindings: display: tegra: Document display-hub Thierry Reding
@ 2020-06-17 22:55 ` Rob Herring
2020-06-18 10:27 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Rob Herring @ 2020-06-17 22:55 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:18:31PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Tegra186 and later have an additional component in the display pipeline
> called the display hub. Document the bindings which were missing.
I'd rather this be after the conversion or I'm reviewing it twice.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../display/tegra/nvidia,tegra20-host1x.txt | 50 +++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> index 47319214b5f6..2cf3cc4893da 100644
> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> @@ -297,6 +297,56 @@ of the following host1x client modules:
> - reset-names: Must include the following entries:
> - vic
>
> +- display-hub: display controller hub
> + Required properties:
> + - compatible: "nvidia,tegra<chip>-display"
> + - reg: Physical base address and length of the controller's registers.
> + - interrupts: The interrupt outputs from the controller.
> + - clocks: Must contain an entry for each entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> + - clock-names: Must include the following entries:
> + - disp
> + - dsc
> + - hub
> + - resets: Must contain an entry for each entry in reset-names.
> + See ../reset/reset.txt for details.
> + - reset-names: Must include the following entries:
> + - misc
> + - wgrp0
> + - wgrp1
> + - wgrp2
> + - wgrp3
> + - wgrp4
> + - wgrp5
> + - power-domains: A list of phandle and specifiers identifying the power
> + domains that the display hub is part of.
> + - ranges: Range of registers used for the display controllers.
> +
> + Each subnode of the display hub represents one of the display controllers
> + available:
> +
> + - display: display controller
> + - compatible: "nvidia,tegra<chip>-dc"
> + - reg: Physical base address and length of the controller's registers.
> + - interrupts: The interrupt outputs from the controller.
> + - clocks: Must contain an entry for each entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> + - clock-names: Must include the following entries:
> + - dc
> + - resets: Must contain an entry for each entry in reset-names.
> + See ../reset/reset.txt for details.
> + - reset-names: Must include the following entries:
> + - dc
> + - power-domains: A list of phandle and specifiers that identify the power
> + domains that this display controller is part of.
> + - iommus: A phandle and specifier identifying the SMMU master interface of
> + this display controller.
> + - nvidia,outputs: A list of phandles of outputs that this display
> + controller can drive.
Seems like an OF graph should describe this?
> + - nvidia,head: The number of the display controller head. This is used to
> + setup the various types of output to receive video data from the given
> + head.
Not really clear what this is...
> +
> Example:
>
> / {
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread* Re: [PATCH 06/38] dt-bindings: display: tegra: Document display-hub
2020-06-17 22:55 ` Rob Herring
@ 2020-06-18 10:27 ` Thierry Reding
2020-06-18 18:17 ` Rob Herring
0 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-18 10:27 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 13038 bytes --]
On Wed, Jun 17, 2020 at 04:55:06PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:18:31PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Tegra186 and later have an additional component in the display pipeline
> > called the display hub. Document the bindings which were missing.
>
> I'd rather this be after the conversion or I'm reviewing it twice.
Okay, I'll reorder the patches accordingly.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > .../display/tegra/nvidia,tegra20-host1x.txt | 50 +++++++++++++++++++
> > 1 file changed, 50 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > index 47319214b5f6..2cf3cc4893da 100644
> > --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > @@ -297,6 +297,56 @@ of the following host1x client modules:
> > - reset-names: Must include the following entries:
> > - vic
> >
> > +- display-hub: display controller hub
> > + Required properties:
> > + - compatible: "nvidia,tegra<chip>-display"
> > + - reg: Physical base address and length of the controller's registers.
> > + - interrupts: The interrupt outputs from the controller.
> > + - clocks: Must contain an entry for each entry in clock-names.
> > + See ../clocks/clock-bindings.txt for details.
> > + - clock-names: Must include the following entries:
> > + - disp
> > + - dsc
> > + - hub
> > + - resets: Must contain an entry for each entry in reset-names.
> > + See ../reset/reset.txt for details.
> > + - reset-names: Must include the following entries:
> > + - misc
> > + - wgrp0
> > + - wgrp1
> > + - wgrp2
> > + - wgrp3
> > + - wgrp4
> > + - wgrp5
> > + - power-domains: A list of phandle and specifiers identifying the power
> > + domains that the display hub is part of.
> > + - ranges: Range of registers used for the display controllers.
> > +
> > + Each subnode of the display hub represents one of the display controllers
> > + available:
> > +
> > + - display: display controller
> > + - compatible: "nvidia,tegra<chip>-dc"
> > + - reg: Physical base address and length of the controller's registers.
> > + - interrupts: The interrupt outputs from the controller.
> > + - clocks: Must contain an entry for each entry in clock-names.
> > + See ../clocks/clock-bindings.txt for details.
> > + - clock-names: Must include the following entries:
> > + - dc
> > + - resets: Must contain an entry for each entry in reset-names.
> > + See ../reset/reset.txt for details.
> > + - reset-names: Must include the following entries:
> > + - dc
> > + - power-domains: A list of phandle and specifiers that identify the power
> > + domains that this display controller is part of.
> > + - iommus: A phandle and specifier identifying the SMMU master interface of
> > + this display controller.
> > + - nvidia,outputs: A list of phandles of outputs that this display
> > + controller can drive.
>
> Seems like an OF graph should describe this?
The above documents the current state of affairs. I don't recall exactly
why we never merged the bindings, but we've been using this
nvidia,outputs property for almost three years now. Changing this would
break ABI, although I guess you could say that since this was never
documented it can't be ABI. Still, changing this is going to cause old
device trees to fail with new kernels. Unless of course if we add some
backwards-compatibility mechanism in the driver. But in that case, what
exactly do we gain by switching to an OF graph?
Historically, I think nvidia,outputs was introduced before OF graphs
were "a thing", at least in DRM. According to the git log, the helpers
for graphs were introduced a couple of years before nvidia,outputs was
used, but I guess they must not have been widespread enough for me to
have been aware of them.
Anyway, irrespective of the compatibility issues, I tried to use an OF
graph to describe this and here's what I came up with:
--- >8 ---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 170 ++++++++++++++++++++++++++++++-
drivers/gpu/drm/tegra/dc.c | 15 +--
drivers/gpu/drm/tegra/dc.h | 1 -
drivers/gpu/drm/tegra/output.c | 12 +--
4 files changed, 172 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 58100fb9cd8b..a3dcf2437976 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -994,8 +994,38 @@ display@15200000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
- nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
nvidia,head = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dc0_out: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dc0_out_dsia: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dsia_in_dc0>;
+ };
+
+ dc0_out_dsib: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dsib_in_dc0>;
+ };
+
+ dc0_out_sor0: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <&sor0_in_dc0>;
+ };
+
+ dc0_out_sor1: endpoint@3 {
+ reg = <3>;
+ remote-endpoint = <&sor1_in_dc0>;
+ };
+ };
+ };
};
display@15210000 {
@@ -1010,8 +1040,38 @@ display@15210000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPB>;
iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
- nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
nvidia,head = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dc1_out: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dc1_out_dsia: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dsia_in_dc1>;
+ };
+
+ dc1_out_dsib: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dsib_in_dc1>;
+ };
+
+ dc1_out_sor0: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <&sor0_in_dc1>;
+ };
+
+ dc1_out_sor1: endpoint@3 {
+ reg = <3>;
+ remote-endpoint = <&sor1_in_dc1>;
+ };
+ };
+ };
};
display@15220000 {
@@ -1026,8 +1086,28 @@ display@15220000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPC>;
iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
- nvidia,outputs = <&sor0 &sor1>;
nvidia,head = <2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dc2_out: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dc2_out_sor0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&sor0_in_dc2>;
+ };
+
+ dc2_out_sor1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&sor1_in_dc2>;
+ };
+ };
+ };
};
};
@@ -1044,6 +1124,25 @@ dsia: dsi@15300000 {
status = "disabled";
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsia_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dsia_in_dc0: endpoint@0 {
+ remote-endpoint = <&dc0_out_dsia>;
+ };
+
+ dsia_in_dc1: endpoint@1 {
+ remote-endpoint = <&dc1_out_dsia>;
+ };
+ };
+ };
};
vic@15340000 {
@@ -1072,6 +1171,25 @@ dsib: dsi@15400000 {
status = "disabled";
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsib_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ dsib_in_dc0: endpoint@0 {
+ remote-endpoint = <&dc0_out_dsib>;
+ };
+
+ dsib_in_dc1: endpoint@1 {
+ remote-endpoint = <&dc1_out_dsib>;
+ };
+ };
+ };
};
sor0: sor@15540000 {
@@ -1096,6 +1214,29 @@ sor0: sor@15540000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
nvidia,interface = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sor0_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ sor0_in_dc0: endpoint@0 {
+ remote-endpoint = <&dc0_out_sor0>;
+ };
+
+ sor0_in_dc1: endpoint@1 {
+ remote-endpoint = <&dc1_out_sor0>;
+ };
+
+ sor0_in_dc2: endpoint@2 {
+ remote-endpoint = <&dc2_out_sor0>;
+ };
+ };
+ };
};
sor1: sor@15580000 {
@@ -1120,6 +1261,29 @@ sor1: sor@15580000 {
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
nvidia,interface = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sor1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ sor1_in_dc0: endpoint@0 {
+ remote-endpoint = <&dc0_out_sor1>;
+ };
+
+ sor1_in_dc1: endpoint@1 {
+ remote-endpoint = <&dc1_out_sor1>;
+ };
+
+ sor1_in_dc2: endpoint@2 {
+ remote-endpoint = <&dc2_out_sor1>;
+ };
+ };
+ };
};
dpaux: dpaux@155c0000 {
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 04d6848d19fc..4adb64c083c8 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -10,6 +10,7 @@
#include <linux/iommu.h>
#include <linux/module.h>
#include <linux/of_device.h>
+#include <linux/of_graph.h>
#include <linux/pm_runtime.h>
#include <linux/reset.h>
@@ -86,19 +87,6 @@ static inline void tegra_plane_writel(struct tegra_plane *plane, u32 value,
tegra_dc_writel(plane->dc, value, tegra_plane_offset(plane, offset));
}
-bool tegra_dc_has_output(struct tegra_dc *dc, struct device *dev)
-{
- struct device_node *np = dc->dev->of_node;
- struct of_phandle_iterator it;
- int err;
-
- of_for_each_phandle(&it, err, np, "nvidia,outputs", NULL, 0)
- if (it.node == dev->of_node)
- return true;
-
- return false;
-}
-
/*
* Double-buffered registers have two copies: ASSEMBLY and ACTIVE. When the
* *_ACT_REQ bits are set the ASSEMBLY copy is latched into the ACTIVE copy.
@@ -2061,6 +2049,7 @@ static int tegra_dc_init(struct host1x_client *client)
if (err < 0)
goto cleanup;
+ dc->base.port = of_graph_get_port_by_id(dc->dev->of_node, 0);
drm_crtc_helper_add(&dc->base, &tegra_crtc_helper_funcs);
/*
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 3d8ddccd758f..9e4ae77e6270 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -144,7 +144,6 @@ struct tegra_dc_window {
};
/* from dc.c */
-bool tegra_dc_has_output(struct tegra_dc *dc, struct device *dev);
void tegra_dc_commit(struct tegra_dc *dc);
int tegra_dc_state_setup_clock(struct tegra_dc *dc,
struct drm_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index e36e5e7c2f69..b09935cdf397 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -5,6 +5,7 @@
*/
#include <drm/drm_atomic_helper.h>
+#include <drm/drm_of.h>
#include <drm/drm_panel.h>
#include <drm/drm_simple_kms_helper.h>
@@ -229,16 +230,9 @@ void tegra_output_find_possible_crtcs(struct tegra_output *output,
struct drm_device *drm)
{
struct device *dev = output->dev;
- struct drm_crtc *crtc;
- unsigned int mask = 0;
-
- drm_for_each_crtc(crtc, drm) {
- struct tegra_dc *dc = to_tegra_dc(crtc);
-
- if (tegra_dc_has_output(dc, dev))
- mask |= drm_crtc_mask(crtc);
- }
+ u32 mask;
+ mask = drm_of_find_possible_crtcs(drm, dev->of_node);
if (mask == 0) {
dev_warn(dev, "missing output definition for heads in DT\n");
mask = 0x3;
--- >8 ---
I do see the benefit of using standard bindings where available, but in
this case I think that's hardly an improvement over the current binding,
even though it's undocumented.
> > + - nvidia,head: The number of the display controller head. This is used to
> > + setup the various types of output to receive video data from the given
> > + head.
>
> Not really clear what this is...
This is the same as for the display controller in older Tegra devices.
The value is the index of the display controller head, or the instance
number of the IP, if that's any clearer. We need this in some places
for register programming. We can't always safely derive it in some
other way.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 06/38] dt-bindings: display: tegra: Document display-hub
2020-06-18 10:27 ` Thierry Reding
@ 2020-06-18 18:17 ` Rob Herring
2020-06-19 6:45 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Rob Herring @ 2020-06-18 18:17 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Thu, Jun 18, 2020 at 4:27 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, Jun 17, 2020 at 04:55:06PM -0600, Rob Herring wrote:
> > On Fri, Jun 12, 2020 at 04:18:31PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > >
> > > Tegra186 and later have an additional component in the display pipeline
> > > called the display hub. Document the bindings which were missing.
> >
> > I'd rather this be after the conversion or I'm reviewing it twice.
>
> Okay, I'll reorder the patches accordingly.
>
> > >
> > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > ---
> > > .../display/tegra/nvidia,tegra20-host1x.txt | 50 +++++++++++++++++++
> > > 1 file changed, 50 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > > index 47319214b5f6..2cf3cc4893da 100644
> > > --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > > @@ -297,6 +297,56 @@ of the following host1x client modules:
> > > - reset-names: Must include the following entries:
> > > - vic
> > >
> > > +- display-hub: display controller hub
> > > + Required properties:
> > > + - compatible: "nvidia,tegra<chip>-display"
> > > + - reg: Physical base address and length of the controller's registers.
> > > + - interrupts: The interrupt outputs from the controller.
> > > + - clocks: Must contain an entry for each entry in clock-names.
> > > + See ../clocks/clock-bindings.txt for details.
> > > + - clock-names: Must include the following entries:
> > > + - disp
> > > + - dsc
> > > + - hub
> > > + - resets: Must contain an entry for each entry in reset-names.
> > > + See ../reset/reset.txt for details.
> > > + - reset-names: Must include the following entries:
> > > + - misc
> > > + - wgrp0
> > > + - wgrp1
> > > + - wgrp2
> > > + - wgrp3
> > > + - wgrp4
> > > + - wgrp5
> > > + - power-domains: A list of phandle and specifiers identifying the power
> > > + domains that the display hub is part of.
> > > + - ranges: Range of registers used for the display controllers.
> > > +
> > > + Each subnode of the display hub represents one of the display controllers
> > > + available:
> > > +
> > > + - display: display controller
> > > + - compatible: "nvidia,tegra<chip>-dc"
> > > + - reg: Physical base address and length of the controller's registers.
> > > + - interrupts: The interrupt outputs from the controller.
> > > + - clocks: Must contain an entry for each entry in clock-names.
> > > + See ../clocks/clock-bindings.txt for details.
> > > + - clock-names: Must include the following entries:
> > > + - dc
> > > + - resets: Must contain an entry for each entry in reset-names.
> > > + See ../reset/reset.txt for details.
> > > + - reset-names: Must include the following entries:
> > > + - dc
> > > + - power-domains: A list of phandle and specifiers that identify the power
> > > + domains that this display controller is part of.
> > > + - iommus: A phandle and specifier identifying the SMMU master interface of
> > > + this display controller.
> > > + - nvidia,outputs: A list of phandles of outputs that this display
> > > + controller can drive.
> >
> > Seems like an OF graph should describe this?
>
> The above documents the current state of affairs. I don't recall exactly
> why we never merged the bindings, but we've been using this
> nvidia,outputs property for almost three years now. Changing this would
> break ABI, although I guess you could say that since this was never
> documented it can't be ABI. Still, changing this is going to cause old
> device trees to fail with new kernels. Unless of course if we add some
> backwards-compatibility mechanism in the driver. But in that case, what
> exactly do we gain by switching to an OF graph?
Probably nothing at this point. More I was just curious how we ended
up with something different.
> Historically, I think nvidia,outputs was introduced before OF graphs
> were "a thing", at least in DRM. According to the git log, the helpers
> for graphs were introduced a couple of years before nvidia,outputs was
> used, but I guess they must not have been widespread enough for me to
> have been aware of them.
There was a period display subsystem bindings were pretty much un-reviewed...
> Anyway, irrespective of the compatibility issues, I tried to use an OF
> graph to describe this and here's what I came up with:
>
> --- >8 ---
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 170 ++++++++++++++++++++++++++++++-
> drivers/gpu/drm/tegra/dc.c | 15 +--
> drivers/gpu/drm/tegra/dc.h | 1 -
> drivers/gpu/drm/tegra/output.c | 12 +--
> 4 files changed, 172 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> index 58100fb9cd8b..a3dcf2437976 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> @@ -994,8 +994,38 @@ display@15200000 {
> power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
>
> - nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> nvidia,head = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dc0_out: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + dc0_out_dsia: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&dsia_in_dc0>;
> + };
> +
> + dc0_out_dsib: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&dsib_in_dc0>;
> + };
> +
> + dc0_out_sor0: endpoint@2 {
> + reg = <2>;
> + remote-endpoint = <&sor0_in_dc0>;
> + };
> +
> + dc0_out_sor1: endpoint@3 {
> + reg = <3>;
> + remote-endpoint = <&sor1_in_dc0>;
> + };
> + };
> + };
> };
>
> display@15210000 {
> @@ -1010,8 +1040,38 @@ display@15210000 {
> power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPB>;
> iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
>
> - nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> nvidia,head = <1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dc1_out: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + dc1_out_dsia: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&dsia_in_dc1>;
> + };
> +
> + dc1_out_dsib: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&dsib_in_dc1>;
> + };
> +
> + dc1_out_sor0: endpoint@2 {
> + reg = <2>;
> + remote-endpoint = <&sor0_in_dc1>;
> + };
> +
> + dc1_out_sor1: endpoint@3 {
> + reg = <3>;
> + remote-endpoint = <&sor1_in_dc1>;
> + };
> + };
> + };
> };
>
> display@15220000 {
> @@ -1026,8 +1086,28 @@ display@15220000 {
> power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPC>;
> iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
>
> - nvidia,outputs = <&sor0 &sor1>;
> nvidia,head = <2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dc2_out: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + dc2_out_sor0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&sor0_in_dc2>;
> + };
> +
> + dc2_out_sor1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&sor1_in_dc2>;
> + };
> + };
> + };
> };
> };
>
> @@ -1044,6 +1124,25 @@ dsia: dsi@15300000 {
> status = "disabled";
>
> power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dsia_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + dsia_in_dc0: endpoint@0 {
> + remote-endpoint = <&dc0_out_dsia>;
> + };
> +
> + dsia_in_dc1: endpoint@1 {
> + remote-endpoint = <&dc1_out_dsia>;
> + };
> + };
> + };
> };
>
> vic@15340000 {
> @@ -1072,6 +1171,25 @@ dsib: dsi@15400000 {
> status = "disabled";
>
> power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dsib_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + dsib_in_dc0: endpoint@0 {
> + remote-endpoint = <&dc0_out_dsib>;
> + };
> +
> + dsib_in_dc1: endpoint@1 {
> + remote-endpoint = <&dc1_out_dsib>;
> + };
> + };
> + };
> };
>
> sor0: sor@15540000 {
> @@ -1096,6 +1214,29 @@ sor0: sor@15540000 {
>
> power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> nvidia,interface = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sor0_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + sor0_in_dc0: endpoint@0 {
> + remote-endpoint = <&dc0_out_sor0>;
> + };
> +
> + sor0_in_dc1: endpoint@1 {
> + remote-endpoint = <&dc1_out_sor0>;
> + };
> +
> + sor0_in_dc2: endpoint@2 {
> + remote-endpoint = <&dc2_out_sor0>;
> + };
> + };
> + };
> };
>
> sor1: sor@15580000 {
> @@ -1120,6 +1261,29 @@ sor1: sor@15580000 {
>
> power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> nvidia,interface = <1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sor1_in: port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + sor1_in_dc0: endpoint@0 {
> + remote-endpoint = <&dc0_out_sor1>;
> + };
> +
> + sor1_in_dc1: endpoint@1 {
> + remote-endpoint = <&dc1_out_sor1>;
> + };
> +
> + sor1_in_dc2: endpoint@2 {
> + remote-endpoint = <&dc2_out_sor1>;
> + };
> + };
> + };
> };
>
> dpaux: dpaux@155c0000 {
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 04d6848d19fc..4adb64c083c8 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -10,6 +10,7 @@
> #include <linux/iommu.h>
> #include <linux/module.h>
> #include <linux/of_device.h>
> +#include <linux/of_graph.h>
> #include <linux/pm_runtime.h>
> #include <linux/reset.h>
>
> @@ -86,19 +87,6 @@ static inline void tegra_plane_writel(struct tegra_plane *plane, u32 value,
> tegra_dc_writel(plane->dc, value, tegra_plane_offset(plane, offset));
> }
>
> -bool tegra_dc_has_output(struct tegra_dc *dc, struct device *dev)
> -{
> - struct device_node *np = dc->dev->of_node;
> - struct of_phandle_iterator it;
> - int err;
> -
> - of_for_each_phandle(&it, err, np, "nvidia,outputs", NULL, 0)
> - if (it.node == dev->of_node)
> - return true;
> -
> - return false;
> -}
> -
> /*
> * Double-buffered registers have two copies: ASSEMBLY and ACTIVE. When the
> * *_ACT_REQ bits are set the ASSEMBLY copy is latched into the ACTIVE copy.
> @@ -2061,6 +2049,7 @@ static int tegra_dc_init(struct host1x_client *client)
> if (err < 0)
> goto cleanup;
>
> + dc->base.port = of_graph_get_port_by_id(dc->dev->of_node, 0);
> drm_crtc_helper_add(&dc->base, &tegra_crtc_helper_funcs);
>
> /*
> diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
> index 3d8ddccd758f..9e4ae77e6270 100644
> --- a/drivers/gpu/drm/tegra/dc.h
> +++ b/drivers/gpu/drm/tegra/dc.h
> @@ -144,7 +144,6 @@ struct tegra_dc_window {
> };
>
> /* from dc.c */
> -bool tegra_dc_has_output(struct tegra_dc *dc, struct device *dev);
> void tegra_dc_commit(struct tegra_dc *dc);
> int tegra_dc_state_setup_clock(struct tegra_dc *dc,
> struct drm_crtc_state *crtc_state,
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index e36e5e7c2f69..b09935cdf397 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -5,6 +5,7 @@
> */
>
> #include <drm/drm_atomic_helper.h>
> +#include <drm/drm_of.h>
> #include <drm/drm_panel.h>
> #include <drm/drm_simple_kms_helper.h>
>
> @@ -229,16 +230,9 @@ void tegra_output_find_possible_crtcs(struct tegra_output *output,
> struct drm_device *drm)
> {
> struct device *dev = output->dev;
> - struct drm_crtc *crtc;
> - unsigned int mask = 0;
> -
> - drm_for_each_crtc(crtc, drm) {
> - struct tegra_dc *dc = to_tegra_dc(crtc);
> -
> - if (tegra_dc_has_output(dc, dev))
> - mask |= drm_crtc_mask(crtc);
> - }
> + u32 mask;
>
> + mask = drm_of_find_possible_crtcs(drm, dev->of_node);
> if (mask == 0) {
> dev_warn(dev, "missing output definition for heads in DT\n");
> mask = 0x3;
> --- >8 ---
>
> I do see the benefit of using standard bindings where available, but in
> this case I think that's hardly an improvement over the current binding,
> even though it's undocumented.
>
> > > + - nvidia,head: The number of the display controller head. This is used to
> > > + setup the various types of output to receive video data from the given
> > > + head.
> >
> > Not really clear what this is...
>
> This is the same as for the display controller in older Tegra devices.
> The value is the index of the display controller head, or the instance
> number of the IP, if that's any clearer. We need this in some places
> for register programming. We can't always safely derive it in some
> other way.
Index, humm. I'll pretend I didn't ask...
Rob
^ permalink raw reply [flat|nested] 76+ messages in thread* Re: [PATCH 06/38] dt-bindings: display: tegra: Document display-hub
2020-06-18 18:17 ` Rob Herring
@ 2020-06-19 6:45 ` Thierry Reding
0 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-19 6:45 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 21238 bytes --]
On Thu, Jun 18, 2020 at 12:17:36PM -0600, Rob Herring wrote:
> On Thu, Jun 18, 2020 at 4:27 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Wed, Jun 17, 2020 at 04:55:06PM -0600, Rob Herring wrote:
> > > On Fri, Jun 12, 2020 at 04:18:31PM +0200, Thierry Reding wrote:
> > > > From: Thierry Reding <treding@nvidia.com>
> > > >
> > > > Tegra186 and later have an additional component in the display pipeline
> > > > called the display hub. Document the bindings which were missing.
> > >
> > > I'd rather this be after the conversion or I'm reviewing it twice.
> >
> > Okay, I'll reorder the patches accordingly.
> >
> > > >
> > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > ---
> > > > .../display/tegra/nvidia,tegra20-host1x.txt | 50 +++++++++++++++++++
> > > > 1 file changed, 50 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > > > index 47319214b5f6..2cf3cc4893da 100644
> > > > --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > > > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > > > @@ -297,6 +297,56 @@ of the following host1x client modules:
> > > > - reset-names: Must include the following entries:
> > > > - vic
> > > >
> > > > +- display-hub: display controller hub
> > > > + Required properties:
> > > > + - compatible: "nvidia,tegra<chip>-display"
> > > > + - reg: Physical base address and length of the controller's registers.
> > > > + - interrupts: The interrupt outputs from the controller.
> > > > + - clocks: Must contain an entry for each entry in clock-names.
> > > > + See ../clocks/clock-bindings.txt for details.
> > > > + - clock-names: Must include the following entries:
> > > > + - disp
> > > > + - dsc
> > > > + - hub
> > > > + - resets: Must contain an entry for each entry in reset-names.
> > > > + See ../reset/reset.txt for details.
> > > > + - reset-names: Must include the following entries:
> > > > + - misc
> > > > + - wgrp0
> > > > + - wgrp1
> > > > + - wgrp2
> > > > + - wgrp3
> > > > + - wgrp4
> > > > + - wgrp5
> > > > + - power-domains: A list of phandle and specifiers identifying the power
> > > > + domains that the display hub is part of.
> > > > + - ranges: Range of registers used for the display controllers.
> > > > +
> > > > + Each subnode of the display hub represents one of the display controllers
> > > > + available:
> > > > +
> > > > + - display: display controller
> > > > + - compatible: "nvidia,tegra<chip>-dc"
> > > > + - reg: Physical base address and length of the controller's registers.
> > > > + - interrupts: The interrupt outputs from the controller.
> > > > + - clocks: Must contain an entry for each entry in clock-names.
> > > > + See ../clocks/clock-bindings.txt for details.
> > > > + - clock-names: Must include the following entries:
> > > > + - dc
> > > > + - resets: Must contain an entry for each entry in reset-names.
> > > > + See ../reset/reset.txt for details.
> > > > + - reset-names: Must include the following entries:
> > > > + - dc
> > > > + - power-domains: A list of phandle and specifiers that identify the power
> > > > + domains that this display controller is part of.
> > > > + - iommus: A phandle and specifier identifying the SMMU master interface of
> > > > + this display controller.
> > > > + - nvidia,outputs: A list of phandles of outputs that this display
> > > > + controller can drive.
> > >
> > > Seems like an OF graph should describe this?
> >
> > The above documents the current state of affairs. I don't recall exactly
> > why we never merged the bindings, but we've been using this
> > nvidia,outputs property for almost three years now. Changing this would
> > break ABI, although I guess you could say that since this was never
> > documented it can't be ABI. Still, changing this is going to cause old
> > device trees to fail with new kernels. Unless of course if we add some
> > backwards-compatibility mechanism in the driver. But in that case, what
> > exactly do we gain by switching to an OF graph?
>
> Probably nothing at this point. More I was just curious how we ended
> up with something different.
So does that mean yes or no? Do you want me to proceed with what's
currently used or should I switch to the OF graph version?
> > Historically, I think nvidia,outputs was introduced before OF graphs
> > were "a thing", at least in DRM. According to the git log, the helpers
> > for graphs were introduced a couple of years before nvidia,outputs was
> > used, but I guess they must not have been widespread enough for me to
> > have been aware of them.
>
> There was a period display subsystem bindings were pretty much un-reviewed...
>
> > Anyway, irrespective of the compatibility issues, I tried to use an OF
> > graph to describe this and here's what I came up with:
> >
> > --- >8 ---
> > arch/arm64/boot/dts/nvidia/tegra186.dtsi | 170 ++++++++++++++++++++++++++++++-
> > drivers/gpu/drm/tegra/dc.c | 15 +--
> > drivers/gpu/drm/tegra/dc.h | 1 -
> > drivers/gpu/drm/tegra/output.c | 12 +--
> > 4 files changed, 172 insertions(+), 26 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> > index 58100fb9cd8b..a3dcf2437976 100644
> > --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> > +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> > @@ -994,8 +994,38 @@ display@15200000 {
> > power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> > iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
> >
> > - nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > nvidia,head = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + dc0_out: port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + dc0_out_dsia: endpoint@0 {
> > + reg = <0>;
> > + remote-endpoint = <&dsia_in_dc0>;
> > + };
> > +
> > + dc0_out_dsib: endpoint@1 {
> > + reg = <1>;
> > + remote-endpoint = <&dsib_in_dc0>;
> > + };
> > +
> > + dc0_out_sor0: endpoint@2 {
> > + reg = <2>;
> > + remote-endpoint = <&sor0_in_dc0>;
> > + };
> > +
> > + dc0_out_sor1: endpoint@3 {
> > + reg = <3>;
> > + remote-endpoint = <&sor1_in_dc0>;
> > + };
> > + };
> > + };
> > };
> >
> > display@15210000 {
> > @@ -1010,8 +1040,38 @@ display@15210000 {
> > power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPB>;
> > iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
> >
> > - nvidia,outputs = <&dsia &dsib &sor0 &sor1>;
> > nvidia,head = <1>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + dc1_out: port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + dc1_out_dsia: endpoint@0 {
> > + reg = <0>;
> > + remote-endpoint = <&dsia_in_dc1>;
> > + };
> > +
> > + dc1_out_dsib: endpoint@1 {
> > + reg = <1>;
> > + remote-endpoint = <&dsib_in_dc1>;
> > + };
> > +
> > + dc1_out_sor0: endpoint@2 {
> > + reg = <2>;
> > + remote-endpoint = <&sor0_in_dc1>;
> > + };
> > +
> > + dc1_out_sor1: endpoint@3 {
> > + reg = <3>;
> > + remote-endpoint = <&sor1_in_dc1>;
> > + };
> > + };
> > + };
> > };
> >
> > display@15220000 {
> > @@ -1026,8 +1086,28 @@ display@15220000 {
> > power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISPC>;
> > iommus = <&smmu TEGRA186_SID_NVDISPLAY>;
> >
> > - nvidia,outputs = <&sor0 &sor1>;
> > nvidia,head = <2>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + dc2_out: port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + dc2_out_sor0: endpoint@0 {
> > + reg = <0>;
> > + remote-endpoint = <&sor0_in_dc2>;
> > + };
> > +
> > + dc2_out_sor1: endpoint@1 {
> > + reg = <1>;
> > + remote-endpoint = <&sor1_in_dc2>;
> > + };
> > + };
> > + };
> > };
> > };
> >
> > @@ -1044,6 +1124,25 @@ dsia: dsi@15300000 {
> > status = "disabled";
> >
> > power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + dsia_in: port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + dsia_in_dc0: endpoint@0 {
> > + remote-endpoint = <&dc0_out_dsia>;
> > + };
> > +
> > + dsia_in_dc1: endpoint@1 {
> > + remote-endpoint = <&dc1_out_dsia>;
> > + };
> > + };
> > + };
> > };
> >
> > vic@15340000 {
> > @@ -1072,6 +1171,25 @@ dsib: dsi@15400000 {
> > status = "disabled";
> >
> > power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + dsib_in: port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + dsib_in_dc0: endpoint@0 {
> > + remote-endpoint = <&dc0_out_dsib>;
> > + };
> > +
> > + dsib_in_dc1: endpoint@1 {
> > + remote-endpoint = <&dc1_out_dsib>;
> > + };
> > + };
> > + };
> > };
> >
> > sor0: sor@15540000 {
> > @@ -1096,6 +1214,29 @@ sor0: sor@15540000 {
> >
> > power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> > nvidia,interface = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sor0_in: port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + sor0_in_dc0: endpoint@0 {
> > + remote-endpoint = <&dc0_out_sor0>;
> > + };
> > +
> > + sor0_in_dc1: endpoint@1 {
> > + remote-endpoint = <&dc1_out_sor0>;
> > + };
> > +
> > + sor0_in_dc2: endpoint@2 {
> > + remote-endpoint = <&dc2_out_sor0>;
> > + };
> > + };
> > + };
> > };
> >
> > sor1: sor@15580000 {
> > @@ -1120,6 +1261,29 @@ sor1: sor@15580000 {
> >
> > power-domains = <&bpmp TEGRA186_POWER_DOMAIN_DISP>;
> > nvidia,interface = <1>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sor1_in: port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + sor1_in_dc0: endpoint@0 {
> > + remote-endpoint = <&dc0_out_sor1>;
> > + };
> > +
> > + sor1_in_dc1: endpoint@1 {
> > + remote-endpoint = <&dc1_out_sor1>;
> > + };
> > +
> > + sor1_in_dc2: endpoint@2 {
> > + remote-endpoint = <&dc2_out_sor1>;
> > + };
> > + };
> > + };
> > };
> >
> > dpaux: dpaux@155c0000 {
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index 04d6848d19fc..4adb64c083c8 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -10,6 +10,7 @@
> > #include <linux/iommu.h>
> > #include <linux/module.h>
> > #include <linux/of_device.h>
> > +#include <linux/of_graph.h>
> > #include <linux/pm_runtime.h>
> > #include <linux/reset.h>
> >
> > @@ -86,19 +87,6 @@ static inline void tegra_plane_writel(struct tegra_plane *plane, u32 value,
> > tegra_dc_writel(plane->dc, value, tegra_plane_offset(plane, offset));
> > }
> >
> > -bool tegra_dc_has_output(struct tegra_dc *dc, struct device *dev)
> > -{
> > - struct device_node *np = dc->dev->of_node;
> > - struct of_phandle_iterator it;
> > - int err;
> > -
> > - of_for_each_phandle(&it, err, np, "nvidia,outputs", NULL, 0)
> > - if (it.node == dev->of_node)
> > - return true;
> > -
> > - return false;
> > -}
> > -
> > /*
> > * Double-buffered registers have two copies: ASSEMBLY and ACTIVE. When the
> > * *_ACT_REQ bits are set the ASSEMBLY copy is latched into the ACTIVE copy.
> > @@ -2061,6 +2049,7 @@ static int tegra_dc_init(struct host1x_client *client)
> > if (err < 0)
> > goto cleanup;
> >
> > + dc->base.port = of_graph_get_port_by_id(dc->dev->of_node, 0);
> > drm_crtc_helper_add(&dc->base, &tegra_crtc_helper_funcs);
> >
> > /*
> > diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
> > index 3d8ddccd758f..9e4ae77e6270 100644
> > --- a/drivers/gpu/drm/tegra/dc.h
> > +++ b/drivers/gpu/drm/tegra/dc.h
> > @@ -144,7 +144,6 @@ struct tegra_dc_window {
> > };
> >
> > /* from dc.c */
> > -bool tegra_dc_has_output(struct tegra_dc *dc, struct device *dev);
> > void tegra_dc_commit(struct tegra_dc *dc);
> > int tegra_dc_state_setup_clock(struct tegra_dc *dc,
> > struct drm_crtc_state *crtc_state,
> > diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> > index e36e5e7c2f69..b09935cdf397 100644
> > --- a/drivers/gpu/drm/tegra/output.c
> > +++ b/drivers/gpu/drm/tegra/output.c
> > @@ -5,6 +5,7 @@
> > */
> >
> > #include <drm/drm_atomic_helper.h>
> > +#include <drm/drm_of.h>
> > #include <drm/drm_panel.h>
> > #include <drm/drm_simple_kms_helper.h>
> >
> > @@ -229,16 +230,9 @@ void tegra_output_find_possible_crtcs(struct tegra_output *output,
> > struct drm_device *drm)
> > {
> > struct device *dev = output->dev;
> > - struct drm_crtc *crtc;
> > - unsigned int mask = 0;
> > -
> > - drm_for_each_crtc(crtc, drm) {
> > - struct tegra_dc *dc = to_tegra_dc(crtc);
> > -
> > - if (tegra_dc_has_output(dc, dev))
> > - mask |= drm_crtc_mask(crtc);
> > - }
> > + u32 mask;
> >
> > + mask = drm_of_find_possible_crtcs(drm, dev->of_node);
> > if (mask == 0) {
> > dev_warn(dev, "missing output definition for heads in DT\n");
> > mask = 0x3;
> > --- >8 ---
> >
> > I do see the benefit of using standard bindings where available, but in
> > this case I think that's hardly an improvement over the current binding,
> > even though it's undocumented.
> >
> > > > + - nvidia,head: The number of the display controller head. This is used to
> > > > + setup the various types of output to receive video data from the given
> > > > + head.
> > >
> > > Not really clear what this is...
> >
> > This is the same as for the display controller in older Tegra devices.
> > The value is the index of the display controller head, or the instance
> > number of the IP, if that's any clearer. We need this in some places
> > for register programming. We can't always safely derive it in some
> > other way.
>
> Index, humm. I'll pretend I didn't ask...
Do you have a better suggestion? If we break ABI for the OF graph thing
maybe we should role this ABI break in at the same time. This should be
safe to do on Tegra because I'm not aware of any devices that will boot
with a DTB from a read-only location.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (5 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 06/38] dt-bindings: display: tegra: Document display-hub Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 15:54 ` Dmitry Osipenko
2020-06-17 23:13 ` Rob Herring
2020-06-12 14:18 ` [PATCH 08/38] dt-bindings: display: tegra: Document interconnect paths Thierry Reding
` (30 subsequent siblings)
37 siblings, 2 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Tegra host1x controller bindings from the free-form text
format to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../display/tegra/nvidia,tegra20-host1x.txt | 516 ------
.../display/tegra/nvidia,tegra20-host1x.yaml | 1418 +++++++++++++++++
2 files changed, 1418 insertions(+), 516 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
deleted file mode 100644
index 2cf3cc4893da..000000000000
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ /dev/null
@@ -1,516 +0,0 @@
-NVIDIA Tegra host1x
-
-Required properties:
-- compatible: "nvidia,tegra<chip>-host1x"
-- reg: Physical base address and length of the controller's registers.
- For pre-Tegra186, one entry describing the whole register area.
- For Tegra186, one entry for each entry in reg-names:
- "vm" - VM region assigned to Linux
- "hypervisor" - Hypervisor region (only if Linux acts as hypervisor)
-- interrupts: The interrupt outputs from the controller.
-- #address-cells: The number of cells used to represent physical base addresses
- in the host1x address space. Should be 1.
-- #size-cells: The number of cells used to represent the size of an address
- range in the host1x address space. Should be 1.
-- ranges: The mapping of the host1x address space to the CPU address space.
-- clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - host1x
-
-The host1x top-level node defines a number of children, each representing one
-of the following host1x client modules:
-
-- mpe: video encoder
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-mpe"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - mpe
-
-- vi: video input
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-vi"
- - reg: Physical base address and length of the controller registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
- - Tegra20/Tegra30/Tegra114/Tegra124:
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - vi
- - Tegra210:
- - power-domains: Must include venc powergate node as vi is in VE partition.
- - Tegra210 has CSI part of VI sharing same host interface and register space.
- So, VI device node should have CSI child node.
-
- - csi: mipi csi interface to vi
-
- Required properties:
- - compatible: "nvidia,tegra210-csi"
- - reg: Physical base address offset to parent and length of the controller
- registers.
- - clocks: Must contain entries csi, cilab, cilcd, cile, csi_tpg clocks.
- See ../clocks/clock-bindings.txt for details.
- - power-domains: Must include sor powergate node as csicil is in
- SOR partition.
-
-- epp: encoder pre-processor
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-epp"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - epp
-
-- isp: image signal processor
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-isp"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - isp
-
-- gr2d: 2D graphics engine
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-gr2d"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - 2d
-
-- gr3d: 3D graphics engine
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-gr3d"
- - reg: Physical base address and length of the controller's registers.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must include the following entries:
- (This property may be omitted if the only clock in the list is "3d")
- - 3d
- This MUST be the first entry.
- - 3d2 (Only required on SoCs with two 3D clocks)
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - 3d
- - 3d2 (Only required on SoCs with two 3D clocks)
-
-- dc: display controller
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-dc"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must include the following entries:
- - dc
- This MUST be the first entry.
- - parent
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - dc
- - nvidia,head: The number of the display controller head. This is used to
- setup the various types of output to receive video data from the given
- head.
-
- Each display controller node has a child node, named "rgb", that represents
- the RGB output associated with the controller. It can take the following
- optional properties:
- - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- - nvidia,edid: supplies a binary EDID blob
- - nvidia,panel: phandle of a display panel
-
-- hdmi: High Definition Multimedia Interface
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-hdmi"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - hdmi-supply: supply for the +5V HDMI connector pin
- - vdd-supply: regulator for supply voltage
- - pll-supply: regulator for PLL
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must include the following entries:
- - hdmi
- This MUST be the first entry.
- - parent
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - hdmi
-
- Optional properties:
- - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- - nvidia,edid: supplies a binary EDID blob
- - nvidia,panel: phandle of a display panel
-
-- tvo: TV encoder output
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-tvo"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-
-- dsi: display serial interface
-
- Required properties:
- - compatible: "nvidia,tegra<chip>-dsi"
- - reg: Physical base address and length of the controller's registers.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must include the following entries:
- - dsi
- This MUST be the first entry.
- - lp
- - parent
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - dsi
- - avdd-dsi-supply: phandle of a supply that powers the DSI controller
- - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying
- which pads are used by this DSI output and need to be calibrated. See also
- ../display/tegra/nvidia,tegra114-mipi.txt.
-
- Optional properties:
- - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- - nvidia,edid: supplies a binary EDID blob
- - nvidia,panel: phandle of a display panel
- - nvidia,ganged-mode: contains a phandle to a second DSI controller to gang
- up with in order to support up to 8 data lanes
-
-- sor: serial output resource
-
- Required properties:
- - compatible: Should be:
- - "nvidia,tegra124-sor": for Tegra124 and Tegra132
- - "nvidia,tegra132-sor": for Tegra132
- - "nvidia,tegra210-sor": for Tegra210
- - "nvidia,tegra210-sor1": for Tegra210
- - "nvidia,tegra186-sor": for Tegra186
- - "nvidia,tegra186-sor1": for Tegra186
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must include the following entries:
- - sor: clock input for the SOR hardware
- - out: SOR output clock
- - parent: input for the pixel clock
- - dp: reference clock for the SOR clock
- - safe: safe reference for the SOR clock during power up
-
- For Tegra186 and later:
- - pad: SOR pad output clock (on Tegra186 and later)
-
- Obsolete:
- - source: source clock for the SOR clock (obsolete, use "out" instead)
-
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - sor
-
- Required properties on Tegra186 and later:
- - nvidia,interface: index of the SOR interface
-
- Optional properties:
- - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- - nvidia,edid: supplies a binary EDID blob
- - nvidia,panel: phandle of a display panel
- - nvidia,xbar-cfg: 5 cells containing the crossbar configuration. Each lane
- of the SOR, identified by the cell's index, is mapped via the crossbar to
- the pad specified by the cell's value.
-
- Optional properties when driving an eDP output:
- - nvidia,dpaux: phandle to a DispayPort AUX interface
-
-- dpaux: DisplayPort AUX interface
- - compatible : Should contain one of the following:
- - "nvidia,tegra124-dpaux": for Tegra124 and Tegra132
- - "nvidia,tegra210-dpaux": for Tegra210
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must include the following entries:
- - dpaux: clock input for the DPAUX hardware
- - parent: reference clock
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - dpaux
- - vdd-supply: phandle of a supply that powers the DisplayPort link
- - i2c-bus: Subnode where I2C slave devices are listed. This subnode
- must be always present. If there are no I2C slave devices, an empty
- node should be added. See ../../i2c/i2c.txt for more information.
-
- See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
- regarding the DPAUX pad controller bindings.
-
-- vic: Video Image Compositor
- - compatible : "nvidia,tegra<chip>-vic"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must include the following entries:
- - vic: clock input for the VIC hardware
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - vic
-
-- display-hub: display controller hub
- Required properties:
- - compatible: "nvidia,tegra<chip>-display"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must include the following entries:
- - disp
- - dsc
- - hub
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - misc
- - wgrp0
- - wgrp1
- - wgrp2
- - wgrp3
- - wgrp4
- - wgrp5
- - power-domains: A list of phandle and specifiers identifying the power
- domains that the display hub is part of.
- - ranges: Range of registers used for the display controllers.
-
- Each subnode of the display hub represents one of the display controllers
- available:
-
- - display: display controller
- - compatible: "nvidia,tegra<chip>-dc"
- - reg: Physical base address and length of the controller's registers.
- - interrupts: The interrupt outputs from the controller.
- - clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
- - clock-names: Must include the following entries:
- - dc
- - resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
- - reset-names: Must include the following entries:
- - dc
- - power-domains: A list of phandle and specifiers that identify the power
- domains that this display controller is part of.
- - iommus: A phandle and specifier identifying the SMMU master interface of
- this display controller.
- - nvidia,outputs: A list of phandles of outputs that this display
- controller can drive.
- - nvidia,head: The number of the display controller head. This is used to
- setup the various types of output to receive video data from the given
- head.
-
-Example:
-
-/ {
- ...
-
- host1x {
- compatible = "nvidia,tegra20-host1x", "simple-bus";
- reg = <0x50000000 0x00024000>;
- interrupts = <0 65 0x04 /* mpcore syncpt */
- 0 67 0x04>; /* mpcore general */
- clocks = <&tegra_car TEGRA20_CLK_HOST1X>;
- resets = <&tegra_car 28>;
- reset-names = "host1x";
-
- #address-cells = <1>;
- #size-cells = <1>;
-
- ranges = <0x54000000 0x54000000 0x04000000>;
-
- mpe {
- compatible = "nvidia,tegra20-mpe";
- reg = <0x54040000 0x00040000>;
- interrupts = <0 68 0x04>;
- clocks = <&tegra_car TEGRA20_CLK_MPE>;
- resets = <&tegra_car 60>;
- reset-names = "mpe";
- };
-
- vi@54080000 {
- compatible = "nvidia,tegra210-vi";
- reg = <0x0 0x54080000 0x0 0x700>;
- interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
- assigned-clocks = <&tegra_car TEGRA210_CLK_VI>;
- assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>;
-
- clocks = <&tegra_car TEGRA210_CLK_VI>;
- power-domains = <&pd_venc>;
-
- #address-cells = <1>;
- #size-cells = <1>;
-
- ranges = <0x0 0x0 0x54080000 0x2000>;
-
- csi@838 {
- compatible = "nvidia,tegra210-csi";
- reg = <0x838 0x1300>;
- assigned-clocks = <&tegra_car TEGRA210_CLK_CILAB>,
- <&tegra_car TEGRA210_CLK_CILCD>,
- <&tegra_car TEGRA210_CLK_CILE>,
- <&tegra_car TEGRA210_CLK_CSI_TPG>;
- assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_P>,
- <&tegra_car TEGRA210_CLK_PLL_P>,
- <&tegra_car TEGRA210_CLK_PLL_P>;
- assigned-clock-rates = <102000000>,
- <102000000>,
- <102000000>,
- <972000000>;
-
- clocks = <&tegra_car TEGRA210_CLK_CSI>,
- <&tegra_car TEGRA210_CLK_CILAB>,
- <&tegra_car TEGRA210_CLK_CILCD>,
- <&tegra_car TEGRA210_CLK_CILE>,
- <&tegra_car TEGRA210_CLK_CSI_TPG>;
- clock-names = "csi", "cilab", "cilcd", "cile", "csi_tpg";
- power-domains = <&pd_sor>;
- };
- };
-
- epp {
- compatible = "nvidia,tegra20-epp";
- reg = <0x540c0000 0x00040000>;
- interrupts = <0 70 0x04>;
- clocks = <&tegra_car TEGRA20_CLK_EPP>;
- resets = <&tegra_car 19>;
- reset-names = "epp";
- };
-
- isp {
- compatible = "nvidia,tegra20-isp";
- reg = <0x54100000 0x00040000>;
- interrupts = <0 71 0x04>;
- clocks = <&tegra_car TEGRA20_CLK_ISP>;
- resets = <&tegra_car 23>;
- reset-names = "isp";
- };
-
- gr2d {
- compatible = "nvidia,tegra20-gr2d";
- reg = <0x54140000 0x00040000>;
- interrupts = <0 72 0x04>;
- clocks = <&tegra_car TEGRA20_CLK_GR2D>;
- resets = <&tegra_car 21>;
- reset-names = "2d";
- };
-
- gr3d {
- compatible = "nvidia,tegra20-gr3d";
- reg = <0x54180000 0x00040000>;
- clocks = <&tegra_car TEGRA20_CLK_GR3D>;
- resets = <&tegra_car 24>;
- reset-names = "3d";
- };
-
- dc@54200000 {
- compatible = "nvidia,tegra20-dc";
- reg = <0x54200000 0x00040000>;
- interrupts = <0 73 0x04>;
- clocks = <&tegra_car TEGRA20_CLK_DISP1>,
- <&tegra_car TEGRA20_CLK_PLL_P>;
- clock-names = "dc", "parent";
- resets = <&tegra_car 27>;
- reset-names = "dc";
-
- rgb {
- status = "disabled";
- };
- };
-
- dc@54240000 {
- compatible = "nvidia,tegra20-dc";
- reg = <0x54240000 0x00040000>;
- interrupts = <0 74 0x04>;
- clocks = <&tegra_car TEGRA20_CLK_DISP2>,
- <&tegra_car TEGRA20_CLK_PLL_P>;
- clock-names = "dc", "parent";
- resets = <&tegra_car 26>;
- reset-names = "dc";
-
- rgb {
- status = "disabled";
- };
- };
-
- hdmi {
- compatible = "nvidia,tegra20-hdmi";
- reg = <0x54280000 0x00040000>;
- interrupts = <0 75 0x04>;
- clocks = <&tegra_car TEGRA20_CLK_HDMI>,
- <&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
- clock-names = "hdmi", "parent";
- resets = <&tegra_car 51>;
- reset-names = "hdmi";
- status = "disabled";
- };
-
- tvo {
- compatible = "nvidia,tegra20-tvo";
- reg = <0x542c0000 0x00040000>;
- interrupts = <0 76 0x04>;
- clocks = <&tegra_car TEGRA20_CLK_TVO>;
- status = "disabled";
- };
-
- dsi {
- compatible = "nvidia,tegra20-dsi";
- reg = <0x54300000 0x00040000>;
- clocks = <&tegra_car TEGRA20_CLK_DSI>,
- <&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
- clock-names = "dsi", "parent";
- resets = <&tegra_car 48>;
- reset-names = "dsi";
- status = "disabled";
- };
- };
-
- ...
-};
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
new file mode 100644
index 000000000000..3347e1b3c8f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
@@ -0,0 +1,1418 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-host1x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra host1x controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: The host1x top-level node defines a number of children, each
+ representing one of the host1x client modules defined in this binding.
+
+properties:
+ # required
+ compatible:
+ oneOf:
+ - description: NVIDIA Tegra20
+ items:
+ - const: nvidia,tegra20-host1x
+
+ - description: NVIDIA Tegra30
+ items:
+ - const: nvidia,tegra30-host1x
+
+ - description: NVIDIA Tegra114
+ items:
+ - const: nvidia,tegra114-host1x
+
+ - description: NVIDIA Tegra124
+ items:
+ - const: nvidia,tegra124-host1x
+
+ - description: NVIDIA Tegra132
+ items:
+ - const: nvidia,tegra132-host1x
+ - const: nvidia,tegra124-host1x
+
+ - description: NVIDIA Tegra210
+ items:
+ - const: nvidia,tegra210-host1x
+
+ - description: NVIDIA Tegra186
+ items:
+ - const: nvidia,tegra186-host1x
+
+ - description: NVIDIA Tegra194
+ items:
+ - const: nvidia,tegra194-host1x
+
+ interrupts:
+ items:
+ - description: host1x syncpoint interrupt
+ - description: host1x general interrupt
+ minItems: 1
+ maxItems: 2
+
+ interrupt-names:
+ items:
+ - const: syncpt
+ - const: host1x
+
+ '#address-cells':
+ description: The number of cells used to represent physical base addresses
+ in the host1x address space.
+ enum: [1, 2]
+
+ '#size-cells':
+ description: The number of cells used to represent the size of an address
+ range in the host1x address space.
+ enum: [1, 2]
+
+ # required
+ ranges:
+ description: The mapping of the host1x address space to the CPU address
+ space.
+
+ clocks:
+ description: Must contain one entry, for the module clock. See
+ ../clocks/clock-bindings.txt for details.
+
+ clock-names:
+ items:
+ - const: host1x
+
+ resets:
+ description: Must contain an entry for each entry in reset-names. See
+ ../reset/reset.txt for details.
+
+ reset-names:
+ items:
+ - const: host1x
+
+ # optional
+ iommus:
+ $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
+
+ memory-controllers:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
+required:
+ - compatible
+ - interrupts
+ - interrupt-names
+ - '#address-cells'
+ - '#size-cells'
+ - ranges
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-host1x
+ - nvidia,tegra194-host1x
+ then:
+ properties:
+ reg-names:
+ items:
+ - const: hypervisor
+ - const: vm
+
+ reg:
+ items:
+ - description: physical base address and length of the register
+ region assigned to the VM
+ - description: physical base address and length of the register
+ region used by the hypervisor
+
+ required:
+ - reg-names
+ else:
+ properties:
+ reg:
+ maxItems: 1
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ oneOf:
+ - const: nvidia,tegra20-host1x
+ - const: nvidia,tegra30-host1x
+ - const: nvidia,tegra114-host1x
+ - const: nvidia,tegra124-host1x
+
+ then:
+ patternProperties:
+ "^vi@[0-9a-f]+$":
+ description: video input
+ type: object
+ properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra20-vi
+ - const: nvidia,tegra30-vi
+ - const: nvidia,tegra114-vi
+ - const: nvidia,tegra124-vi
+ - items:
+ - const: nvidia,tegra132-vi
+ - const: nvidia,tegra124-vi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets: true
+
+ reset-names:
+ items:
+ - const: vi
+ else:
+ patternProperties:
+ "^vi@[0-9a-f]+$":
+ description: video input
+ type: object
+ properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra210-vi
+ - const: nvidia,tegra186-vi
+ - const: nvidia,tegra194-vi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains: true
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ oneOf:
+ - const: nvidia,tegra210-host1x
+ then:
+ patternProperties:
+ "^vi@[0-9a-f]+$":
+ patternProperties:
+ "^csi@[0-9a-f]+$":
+ description: camera sensor interface
+ type: object
+ properties:
+ compatible:
+ enum:
+ - nvidia,tegra210-csi
+
+ reg: true
+
+ clocks: true
+
+ clock-names:
+ items:
+ - const: csi
+ - const: cilab
+ - const: cilcd
+ - const: cile
+ - const: csi_tpg
+
+ power-domains: true
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra20-host1x
+ - nvidia,tegra30-host1x
+ - nvidia,tegra114-host1x
+ then:
+ patternProperties:
+ "^epp@[0-9a-f]+$":
+ description: encoder pre-processor
+ type: object
+ properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-epp
+ - nvidia,tegra30-epp
+ - nvidia,tegra114-epp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: epp
+
+ iommus:
+ $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
+
+ unevaluatedProperties: false
+
+ "^mpe@[0-9a-f]+$":
+ description: video encoder
+ type: object
+ properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-mpe
+ - nvidia,tegra30-mpe
+ - nvidia,tegra114-mpe
+
+ reg:
+ minItems: 1
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 1
+
+ resets:
+ minItems: 1
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: mpe
+
+ iommus:
+ $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
+
+ unevaluatedProperties: false
+
+ "^gr2d@[0-9a-f]+$":
+ description: 2D graphics engine
+ type: object
+ properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-gr2d
+ - nvidia,tegra30-gr2d
+ - nvidia,tegra114-gr2d
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: 2d
+
+ iommus:
+ $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
+
+ unevaluatedProperties: false
+
+ "^gr3d@[0-9a-f]+$":
+ description: 3D graphics engine
+ type: object
+ properties:
+ compatible:
+ enum:
+ - nvidia,tegra20-gr3d
+ - nvidia,tegra30-gr3d
+ - nvidia,tegra114-gr3d
+
+ reg:
+ maxItems: 1
+
+ iommus:
+ $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
+
+ allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra30-gr3d
+ then:
+ properties:
+ clocks:
+ items:
+ - description: primary module clock
+ - description: secondary module clock
+
+ clock-names:
+ items:
+ - const: 3d
+ - const: 3d2
+
+ resets:
+ items:
+ - description: primary module reset
+ - description: secondary module reset
+
+ reset-names:
+ items:
+ - const: 3d
+ - const: 3d2
+ else:
+ properties:
+ clocks:
+ items:
+ - description: module clock
+
+ clock-names:
+ items:
+ - const: 3d
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: 3d
+
+ unevaluatedProperties: false
+
+ "^tvo@[0-9a-f]+$":
+ description: TV encoder output
+ type: object
+ properties:
+ # required
+ compatible:
+ enum:
+ - nvidia,tegra20-tvo
+ - nvidia,tegra30-tvo
+ - nvidia,tegra114-tvo
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra20-host1x
+ - nvidia,tegra30-host1x
+ - nvidia,tegra114-host1x
+ - nvidia,tegra124-host1x
+ - nvidia,tegra132-host1x
+ - nvidia,tegra210-host1x
+ then:
+ patternProperties:
+ "^dc@[0-9a-f]+$":
+ description: display controller
+ type: object
+ properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra20-dc
+ - const: nvidia,tegra30-dc
+ - const: nvidia,tegra114-dc
+ - const: nvidia,tegra124-dc
+ - items:
+ - const: nvidia,tegra124-dc
+ - const: nvidia,tegra132-dc
+ - const: nvidia,tegra210-dc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: display controller pixel clock
+
+ clock-names:
+ items:
+ - const: dc
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: dc
+
+ iommus:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ nvidia,head:
+ description: The number of the display controller head. This is
+ used to setup the various types of output to receive video
+ data from the given head.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra20-dc
+ - nvidia,tegra30-dc
+ - nvidia,tegra114-dc
+ then:
+ properties:
+ rgb:
+ description: Each display controller node has a child node,
+ named "rgb", that represents the RGB output associated
+ with the controller.
+ type: object
+ properties:
+ nvidia,ddc-i2c-bus:
+ description: phandle of an I2C controller used for DDC
+ EDID probing
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ nvidia,hpd-gpio:
+ description: specifies a GPIO used for hotplug
+ detection
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ nvidia,edid:
+ description: supplies a binary EDID blob
+ $ref: "/schemas/types.yaml#/definitions/uint8-array"
+
+ nvidia,panel:
+ description: phandle of a display panel
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-host1x
+ - nvidia,tegra194-host1x
+ then:
+ patternProperties:
+ "^display-hub@[0-9a-f]+$":
+ properties:
+ compatible:
+ oneOf:
+ - description: NVIDIA Tegra186
+ const: nvidia,tegra186-display
+
+ - description: NVIDIA Tegra194
+ const: nvidia,tegra194-display
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ranges:
+ $ref: "/schemas/dt-core.yaml#/properties/ranges"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ resets:
+ items:
+ - description: display hub reset
+ - description: window group 0 reset
+ - description: window group 1 reset
+ - description: window group 2 reset
+ - description: window group 3 reset
+ - description: window group 4 reset
+ - description: window group 5 reset
+
+ reset-names:
+ items:
+ - const: misc
+ - const: wgrp0
+ - const: wgrp1
+ - const: wgrp2
+ - const: wgrp3
+ - const: wgrp4
+ - const: wgrp5
+
+ power-domains:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ patternProperties:
+ "^display@[0-9a-f]+$":
+ description: display controller
+ type: object
+ properties:
+ compatible:
+ enum:
+ - nvidia,tegra186-dc
+ - nvidia,tegra194-dc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: display controller pixel clock
+
+ clock-names:
+ items:
+ - const: dc
+
+ resets:
+ items:
+ - description: display controller reset
+
+ reset-names:
+ items:
+ - const: dc
+
+ power-domains:
+ description: A list of phandle and specifiers that identify
+ the power domains that this display controller is part of.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ iommus:
+ description: a phandle and specifier identifying the SMMU
+ master interface of this display controller.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ memory-controllers:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
+ nvidia,outputs:
+ description: A list of phandles of outputs that this display
+ controller can drive.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ nvidia,head:
+ description: The number of the display controller head. This
+ is used to setup the various types of output to receive
+ video data from the given head.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ unevaluatedProperties: false
+
+ allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra186-display
+ then:
+ properties:
+ clocks:
+ items:
+ - description: display core clock
+ - description: display stream compression clock
+ - description: display hub clock
+
+ clock-names:
+ items:
+ - const: disp
+ - const: dsc
+ - const: hub
+ else:
+ properties:
+ clocks:
+ items:
+ - description: display core clock
+ - description: display hub clock
+
+ clock-names:
+ items:
+ - const: disp
+ - const: hub
+
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra20-host1x
+ - nvidia,tegra30-host1x
+ - nvidia,tegra114-host1x
+ - nvidia,tegra124-host1x
+ then:
+ patternProperties:
+ "^hdmi@[0-9a-f]+$":
+ description: High Definition Multimedia Interface
+ type: object
+ properties:
+ # required
+ compatible:
+ oneOf:
+ - const: nvidia,tegra20-hdmi
+ - const: nvidia,tegra30-hdmi
+ - const: nvidia,tegra114-hdmi
+ - const: nvidia,tegra124-hdmi
+ - items:
+ - const: nvidia,tegra132-hdmi
+ - const: nvidia,tegra124-hdmi
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: module clock
+ - description: parent clock
+
+ clock-names:
+ items:
+ - const: hdmi
+ - const: parent
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: hdmi
+
+ hdmi-supply:
+ description: supply for the +5V HDMI connector pin
+
+ vdd-supply:
+ description: regulator for supply voltage
+
+ pll-supply:
+ description: regulator for PLL
+
+ # optional
+ nvidia,ddc-i2c-bus:
+ description: phandle of an I2C controller used for DDC EDID
+ probing
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ nvidia,hpd-gpio:
+ description: specifies a GPIO used for hotplug detection
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ nvidia,edid:
+ description: supplies a binary EDID blob
+ $ref: "/schemas/types.yaml#/definitions/uint8-array"
+
+ nvidia,panel:
+ description: phandle of a display panel
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ phandle:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra124-host1x
+ - nvidia,tegra210-host1x
+ - nvidia,tegra186-host1x
+ - nvidia,tegra194-host1x
+ then:
+ patternProperties:
+ "^sor@[0-9a-f]+$":
+ description: |
+ The Serial Output Resource (SOR) can be used to drive HDMI, LVDS,
+ eDP and DP outputs.
+
+ See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
+ regarding the DPAUX pad controller bindings.
+ type: object
+ properties:
+ # required
+ compatible:
+ oneOf:
+ - const: nvidia,tegra124-sor
+ - items:
+ - const: nvidia,tegra132-sor
+ - const: nvidia,tegra124-sor
+ - const: nvidia,tegra210-sor
+ - const: nvidia,tegra210-sor1
+ - const: nvidia,tegra186-sor
+ - const: nvidia,tegra186-sor1
+ - const: nvidia,tegra194-sor
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: sor
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ power-domains:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ avdd-io-hdmi-dp-supply:
+ description: I/O supply for HDMI/DP
+
+ vdd-hdmi-dp-pll-supply:
+ description: PLL supply for HDMI/DP
+
+ hdmi-supply:
+ description: +5.0V HDMI connector supply
+
+ # Tegra186 and later
+ nvidia,interface:
+ description: index of the SOR interface
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ # optional
+ nvidia,ddc-i2c-bus:
+ description: phandle of an I2C controller used for DDC EDID
+ probing
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ nvidia,hpd-gpio:
+ description: specifies a GPIO used for hotplug detection
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ nvidia,edid:
+ description: supplies a binary EDID blob
+ $ref: "/schemas/types.yaml#/definitions/uint8-array"
+
+ nvidia,panel:
+ description: phandle of a display panel
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ nvidia,xbar-cfg:
+ description: 5 cells containing the crossbar configuration.
+ Each lane of the SOR, identified by the cell's index, is
+ mapped via the crossbar to the pad specified by the cell's
+ value.
+ $ref: "/schemas/types.yaml#/definitions/uint32-array"
+
+ # optional when driving an eDP output
+ nvidia,dpaux:
+ description: phandle to a DispayPort AUX interface
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ pinctrl-names: true
+ phandle:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ patternProperties:
+ "^pinctrl-[0-9]+$": true
+
+ allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-sor
+ - nvidia,tegra194-sor
+ then:
+ properties:
+ clocks:
+ items:
+ - description: clock input for the SOR hardware
+ - description: SOR output clock
+ - description: input for the pixel clock
+ - description: reference clock for the SOR clock
+ - description: safe reference clock for the SOR clock
+ during power up
+ - description: SOR pad output clock
+
+ clock-names:
+ items:
+ - const: sor
+ - enum:
+ - source # deprecated
+ - out
+ - const: parent
+ - const: dp
+ - const: safe
+ - const: pad
+ else:
+ properties:
+ clocks:
+ items:
+ - description: clock input for the SOR hardware
+ - description: SOR output clock
+ - description: input for the pixel clock
+ - description: reference clock for the SOR clock
+ - description: safe reference clock for the SOR clock
+ during power up
+
+ clock-names:
+ items:
+ - const: sor
+ - enum:
+ - source # deprecated
+ - out
+ - const: parent
+ - const: dp
+ - const: safe
+
+ unevaluatedProperties: false
+
+ "^dpaux@[0-9a-f]+$":
+ description: DisplayPort AUX interface
+ type: object
+ properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra124-dpaux
+ - items:
+ - const: nvidia,tegra132-dpaux
+ - const: nvidia,tegra124-dpaux
+ - const: nvidia,tegra210-dpaux
+ - const: nvidia,tegra186-dpaux
+ - const: nvidia,tegra194-dpaux
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: clock input for the DPAUX hardware
+ - description: reference clock
+
+ clock-names:
+ items:
+ - const: dpaux
+ - const: parent
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: dpaux
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ phandle:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ power-domains:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ i2c-bus:
+ description: Subnode where I2C slave devices are listed. This
+ subnode must be always present. If there are no I2C slave
+ devices, an empty node should be added. See ../../i2c/i2c.yaml
+ for more information.
+
+ vdd-supply:
+ description: phandle of a supply that powers the DisplayPort
+ link
+
+ patternProperties:
+ "^pinmux-.*$":
+ type: object
+
+ unevaluatedProperties: false
+
+ "^vic@[0-9a-f]+$":
+ properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra124-vic
+ - items:
+ - const: nvidia,tegra132-vic
+ - const: nvidia,tegra124-vic
+ - const: nvidia,tegra210-vic
+ - const: nvidia,tegra186-vic
+ - const: nvidia,tegra194-vic
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: clock input for the VIC hardware
+
+ clock-names:
+ items:
+ const: vic
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: vic
+
+ power-domains:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ iommus:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ memory-controllers:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra20-host1x
+ - nvidia,tegra30-host1x
+ - nvidia,tegra114-host1x
+ - nvidia,tegra124-host1x
+ - nvidia,tegra210-host1x
+ - nvidia,tegra186-host1x
+ then:
+ patternProperties:
+ "^dsi@[0-9a-f]+$":
+ description: display serial interface
+ type: object
+ properties:
+ # required
+ compatible:
+ oneOf:
+ - const: nvidia,tegra20-dsi
+ - const: nvidia,tegra30-dsi
+ - const: nvidia,tegra114-dsi
+ - const: nvidia,tegra124-dsi
+ - items:
+ - const: nvidia,tegra132-dsi
+ - const: nvidia,tegra124-dsi
+ - const: nvidia,tegra210-dsi
+ - const: nvidia,tegra186-dsi
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ phandle:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: dsi
+
+ power-domains:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ avdd-dsi-csi-supply:
+ description: phandle of a supply that powers the DSI controller
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ nvidia,mipi-calibrate:
+ description: Should contain a phandle and a specifier specifying
+ which pads are used by this DSI output and need to be
+ calibrated. See also ../display/tegra/nvidia,tegra114-mipi.txt.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ # optional
+ nvidia,ddc-i2c-bus:
+ description: phandle of an I2C controller used for DDC EDID
+ probing
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ nvidia,hpd-gpio:
+ description: specifies a GPIO used for hotplug detection
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ nvidia,edid:
+ description: supplies a binary EDID blob
+ $ref: "/schemas/types.yaml#/definitions/uint8-array"
+
+ nvidia,panel:
+ description: phandle of a display panel
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ nvidia,ganged-mode:
+ description: contains a phandle to a second DSI controller to
+ gang up with in order to support up to 8 data lanes
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ patternProperties:
+ "^panel@[0-9]+$":
+ type: object
+
+ allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra20-dsi
+ - nvidia,tegra30-dsi
+ then:
+ properties:
+ clocks:
+ items:
+ - description: DSI module clock
+ - description: input for the pixel clock
+
+ clock-names:
+ items:
+ - const: dsi
+ - const: parent
+ else:
+ properties:
+ clocks:
+ items:
+ - description: DSI module clock
+ - description: low-power module clock
+ - description: input for the pixel clock
+
+ clock-names:
+ items:
+ - const: dsi
+ - const: lp
+ - const: parent
+
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra20-host1x
+ - nvidia,tegra30-host1x
+ - nvidia,tegra210-host1x
+ then:
+ patternProperties:
+ "^isp@[0-9a-f]+$":
+ type: object
+
+ unevaluatedProperties: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra210-host1x
+ then:
+ patternProperties:
+ "^tsec@[0-9a-f]+$":
+ type: object
+
+ "^nvjpg@[0-9a-f]+$":
+ type: object
+
+ "^nvdec@[0-9a-f]+$":
+ type: object
+
+ "^nvenc@[0-9a-f]+$":
+ type: object
+
+ "^i2c@[0-9a-f]+$":
+ type: object
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra186-host1x
+ then:
+ patternProperties:
+ "^padctl@[0-9a-f]+$":
+ type: object
+ $ref: "/schemas/reset/reset.yaml"
+ properties:
+ compatible:
+ const: nvidia,tegra186-dsi-padctl
+
+ reg:
+ $ref: "/schemas/dt-core.yaml#/properties/reg"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra20-car.h>
+
+ host1x@50000000 {
+ compatible = "nvidia,tegra20-host1x", "simple-bus";
+ reg = <0x50000000 0x00024000>;
+ interrupts = <0 65 0x04 /* mpcore syncpt */
+ 0 67 0x04>; /* mpcore general */
+ interrupt-names = "syncpt", "host1x";
+ clocks = <&tegra_car TEGRA20_CLK_HOST1X>;
+ clock-names = "host1x";
+ resets = <&tegra_car 28>;
+ reset-names = "host1x";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0x54000000 0x54000000 0x04000000>;
+
+ mpe@54040000 {
+ compatible = "nvidia,tegra20-mpe";
+ reg = <0x54040000 0x00040000>;
+ interrupts = <0 68 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_MPE>;
+ resets = <&tegra_car 60>;
+ reset-names = "mpe";
+ };
+
+ vi@54080000 {
+ compatible = "nvidia,tegra20-vi";
+ reg = <0x54080000 0x00040000>;
+ interrupts = <0 69 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_VI>;
+ resets = <&tegra_car 100>;
+ reset-names = "vi";
+ };
+
+ epp@540c0000 {
+ compatible = "nvidia,tegra20-epp";
+ reg = <0x540c0000 0x00040000>;
+ interrupts = <0 70 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_EPP>;
+ resets = <&tegra_car 19>;
+ reset-names = "epp";
+ };
+
+ isp@54100000 {
+ compatible = "nvidia,tegra20-isp";
+ reg = <0x54100000 0x00040000>;
+ interrupts = <0 71 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_ISP>;
+ resets = <&tegra_car 23>;
+ reset-names = "isp";
+ };
+
+ gr2d@54140000 {
+ compatible = "nvidia,tegra20-gr2d";
+ reg = <0x54140000 0x00040000>;
+ interrupts = <0 72 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_GR2D>;
+ resets = <&tegra_car 21>;
+ reset-names = "2d";
+ };
+
+ gr3d@54180000 {
+ compatible = "nvidia,tegra20-gr3d";
+ reg = <0x54180000 0x00040000>;
+ clocks = <&tegra_car TEGRA20_CLK_GR3D>;
+ resets = <&tegra_car 24>;
+ reset-names = "3d";
+ };
+
+ dc@54200000 {
+ compatible = "nvidia,tegra20-dc";
+ reg = <0x54200000 0x00040000>;
+ interrupts = <0 73 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_DISP1>;
+ clock-names = "dc";
+ resets = <&tegra_car 27>;
+ reset-names = "dc";
+
+ rgb {
+ status = "disabled";
+ };
+ };
+
+ dc@54240000 {
+ compatible = "nvidia,tegra20-dc";
+ reg = <0x54240000 0x00040000>;
+ interrupts = <0 74 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_DISP2>;
+ clock-names = "dc";
+ resets = <&tegra_car 26>;
+ reset-names = "dc";
+
+ rgb {
+ status = "disabled";
+ };
+ };
+
+ hdmi@54280000 {
+ compatible = "nvidia,tegra20-hdmi";
+ reg = <0x54280000 0x00040000>;
+ interrupts = <0 75 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_HDMI>,
+ <&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
+ clock-names = "hdmi", "parent";
+ resets = <&tegra_car 51>;
+ reset-names = "hdmi";
+ status = "disabled";
+ };
+
+ tvo@542c0000 {
+ compatible = "nvidia,tegra20-tvo";
+ reg = <0x542c0000 0x00040000>;
+ interrupts = <0 76 0x04>;
+ clocks = <&tegra_car TEGRA20_CLK_TVO>;
+ status = "disabled";
+ };
+
+ dsi@54300000 {
+ compatible = "nvidia,tegra20-dsi";
+ reg = <0x54300000 0x00040000>;
+ clocks = <&tegra_car TEGRA20_CLK_DSI>,
+ <&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
+ clock-names = "dsi", "parent";
+ resets = <&tegra_car 48>;
+ reset-names = "dsi";
+ status = "disabled";
+ };
+ };
+
+ - |
+ #include <dt-bindings/clock/tegra210-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/tegra210-mc.h>
+
+ host1x@50000000 {
+ compatible = "nvidia,tegra210-host1x", "simple-bus";
+ reg = <0x50000000 0x00024000>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>, /* mpcore syncpt */
+ <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; /* mpcore general */
+ interrupt-names = "syncpt", "host1x";
+ clocks = <&tegra_car TEGRA210_CLK_HOST1X>;
+ clock-names = "host1x";
+ resets = <&tegra_car 28>;
+ reset-names = "host1x";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0x54000000 0x54000000 0x01000000>;
+ iommus = <&mc TEGRA_SWGROUP_HC>;
+
+ vi@54080000 {
+ compatible = "nvidia,tegra210-vi";
+ reg = <0x54080000 0x00000700>;
+ interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+ assigned-clocks = <&tegra_car TEGRA210_CLK_VI>;
+ assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>;
+
+ clocks = <&tegra_car TEGRA210_CLK_VI>;
+ power-domains = <&pd_venc>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ranges = <0x0 0x54080000 0x2000>;
+
+ csi@838 {
+ compatible = "nvidia,tegra210-csi";
+ reg = <0x838 0x1300>;
+ assigned-clocks = <&tegra_car TEGRA210_CLK_CILAB>,
+ <&tegra_car TEGRA210_CLK_CILCD>,
+ <&tegra_car TEGRA210_CLK_CILE>,
+ <&tegra_car TEGRA210_CLK_CSI_TPG>;
+ assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_P>,
+ <&tegra_car TEGRA210_CLK_PLL_P>,
+ <&tegra_car TEGRA210_CLK_PLL_P>;
+ assigned-clock-rates = <102000000>,
+ <102000000>,
+ <102000000>,
+ <972000000>;
+
+ clocks = <&tegra_car TEGRA210_CLK_CSI>,
+ <&tegra_car TEGRA210_CLK_CILAB>,
+ <&tegra_car TEGRA210_CLK_CILCD>,
+ <&tegra_car TEGRA210_CLK_CILE>,
+ <&tegra_car TEGRA210_CLK_CSI_TPG>;
+ clock-names = "csi", "cilab", "cilcd", "cile", "csi_tpg";
+ power-domains = <&pd_sor>;
+ };
+ };
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
2020-06-12 14:18 ` [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema Thierry Reding
@ 2020-06-12 15:54 ` Dmitry Osipenko
2020-06-16 14:51 ` Thierry Reding
2020-06-17 23:13 ` Rob Herring
1 sibling, 1 reply; 76+ messages in thread
From: Dmitry Osipenko @ 2020-06-12 15:54 UTC (permalink / raw)
To: Thierry Reding, Rob Herring; +Cc: devicetree, linux-tegra
12.06.2020 17:18, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the Tegra host1x controller bindings from the free-form text
> format to json-schema.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
...
> + memory-controllers:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +required:
> + - compatible
> + - interrupts
> + - interrupt-names
> + - '#address-cells'
> + - '#size-cells'
> + - ranges
> + - reg
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
This memory-controllers property didn't exist before the conversion. So
this is not a pure conversion, which makes it a bit difficult to review
the changes. Could you please factor out the addition of new properties
into a separate patch?
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
2020-06-12 15:54 ` Dmitry Osipenko
@ 2020-06-16 14:51 ` Thierry Reding
0 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-16 14:51 UTC (permalink / raw)
To: Dmitry Osipenko; +Cc: Rob Herring, devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]
On Fri, Jun 12, 2020 at 06:54:45PM +0300, Dmitry Osipenko wrote:
> 12.06.2020 17:18, Thierry Reding пишет:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Convert the Tegra host1x controller bindings from the free-form text
> > format to json-schema.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> ...
> > + memory-controllers:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +required:
> > + - compatible
> > + - interrupts
> > + - interrupt-names
> > + - '#address-cells'
> > + - '#size-cells'
> > + - ranges
> > + - reg
> > + - clocks
> > + - clock-names
> > + - resets
> > + - reset-names
>
> This memory-controllers property didn't exist before the conversion. So
> this is not a pure conversion, which makes it a bit difficult to review
> the changes. Could you please factor out the addition of new properties
> into a separate patch?
The memory-controllers property was from an earlier draft of this series
and is no longer needed. I'll remove it.
In my opinion, these schema conversion patches are difficult to review
in general, especially the likes of this one for host1x because they are
fairly complex to begin with. All existing Tegra-based device trees do
pass validation (although there's a small patch needed to support the
unevaluatedProperties keyword that's new in json-schema draft-08), which
gives me some confidence that they are at least correct from a content
point of view.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
2020-06-12 14:18 ` [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema Thierry Reding
2020-06-12 15:54 ` Dmitry Osipenko
@ 2020-06-17 23:13 ` Rob Herring
2020-06-18 14:16 ` Thierry Reding
1 sibling, 1 reply; 76+ messages in thread
From: Rob Herring @ 2020-06-17 23:13 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:18:32PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the Tegra host1x controller bindings from the free-form text
> format to json-schema.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../display/tegra/nvidia,tegra20-host1x.txt | 516 ------
> .../display/tegra/nvidia,tegra20-host1x.yaml | 1418 +++++++++++++++++
> 2 files changed, 1418 insertions(+), 516 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> new file mode 100644
> index 000000000000..3347e1b3c8f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> @@ -0,0 +1,1418 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-host1x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra host1x controller
> +
> +maintainers:
> + - Thierry Reding <thierry.reding@gmail.com>
> + - Jon Hunter <jonathanh@nvidia.com>
> +
> +description: The host1x top-level node defines a number of children, each
> + representing one of the host1x client modules defined in this binding.
> +
> +properties:
> + # required
> + compatible:
> + oneOf:
> + - description: NVIDIA Tegra20
> + items:
> + - const: nvidia,tegra20-host1x
> +
> + - description: NVIDIA Tegra30
> + items:
> + - const: nvidia,tegra30-host1x
> +
> + - description: NVIDIA Tegra114
> + items:
> + - const: nvidia,tegra114-host1x
> +
> + - description: NVIDIA Tegra124
> + items:
> + - const: nvidia,tegra124-host1x
> +
> + - description: NVIDIA Tegra132
> + items:
> + - const: nvidia,tegra132-host1x
> + - const: nvidia,tegra124-host1x
> +
> + - description: NVIDIA Tegra210
> + items:
> + - const: nvidia,tegra210-host1x
> +
> + - description: NVIDIA Tegra186
> + items:
> + - const: nvidia,tegra186-host1x
> +
> + - description: NVIDIA Tegra194
> + items:
> + - const: nvidia,tegra194-host1x
I don't think the descriptions really add much. I'd rather see all the
single entry cases as 1 'enum'.
> +
> + interrupts:
> + items:
> + - description: host1x syncpoint interrupt
> + - description: host1x general interrupt
> + minItems: 1
> + maxItems: 2
> +
> + interrupt-names:
> + items:
> + - const: syncpt
> + - const: host1x
> +
> + '#address-cells':
> + description: The number of cells used to represent physical base addresses
> + in the host1x address space.
> + enum: [1, 2]
> +
> + '#size-cells':
> + description: The number of cells used to represent the size of an address
> + range in the host1x address space.
> + enum: [1, 2]
> +
> + # required
Odd comment...
> + ranges:
> + description: The mapping of the host1x address space to the CPU address
> + space.
That's every 'ranges'. If you know how many entries, then define
'maxItems'. If not, 'ranges: true' is enough.
> +
> + clocks:
> + description: Must contain one entry, for the module clock. See
> + ../clocks/clock-bindings.txt for details.
> +
> + clock-names:
> + items:
> + - const: host1x
> +
> + resets:
> + description: Must contain an entry for each entry in reset-names. See
> + ../reset/reset.txt for details.
> +
> + reset-names:
> + items:
> + - const: host1x
> +
> + # optional
> + iommus:
> + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
This is already applied to every 'iommus' property, so you just need to
define how many entries.
> +
> + memory-controllers:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> +required:
> + - compatible
> + - interrupts
> + - interrupt-names
> + - '#address-cells'
> + - '#size-cells'
> + - ranges
> + - reg
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
> +
> +unevaluatedProperties: false
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra186-host1x
> + - nvidia,tegra194-host1x
> + then:
> + properties:
> + reg-names:
> + items:
> + - const: hypervisor
> + - const: vm
> +
> + reg:
> + items:
> + - description: physical base address and length of the register
> + region assigned to the VM
> + - description: physical base address and length of the register
> + region used by the hypervisor
> +
> + required:
> + - reg-names
> + else:
> + properties:
> + reg:
> + maxItems: 1
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + oneOf:
> + - const: nvidia,tegra20-host1x
> + - const: nvidia,tegra30-host1x
> + - const: nvidia,tegra114-host1x
> + - const: nvidia,tegra124-host1x
Use 'enum'.
> +
> + then:
> + patternProperties:
> + "^vi@[0-9a-f]+$":
> + description: video input
> + type: object
> + properties:
> + compatible:
> + oneOf:
> + - const: nvidia,tegra20-vi
> + - const: nvidia,tegra30-vi
> + - const: nvidia,tegra114-vi
> + - const: nvidia,tegra124-vi
Use a 'enum' for these 4.
> + - items:
> + - const: nvidia,tegra132-vi
> + - const: nvidia,tegra124-vi
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets: true
> +
> + reset-names:
> + items:
> + - const: vi
> + else:
> + patternProperties:
> + "^vi@[0-9a-f]+$":
> + description: video input
> + type: object
> + properties:
> + compatible:
> + oneOf:
> + - const: nvidia,tegra210-vi
> + - const: nvidia,tegra186-vi
> + - const: nvidia,tegra194-vi
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + power-domains: true
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + oneOf:
> + - const: nvidia,tegra210-host1x
> + then:
> + patternProperties:
> + "^vi@[0-9a-f]+$":
type: object
> + patternProperties:
> + "^csi@[0-9a-f]+$":
> + description: camera sensor interface
> + type: object
> + properties:
> + compatible:
> + enum:
> + - nvidia,tegra210-csi
> +
> + reg: true
> +
> + clocks: true
> +
> + clock-names:
> + items:
> + - const: csi
> + - const: cilab
> + - const: cilcd
> + - const: cile
> + - const: csi_tpg
> +
> + power-domains: true
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra20-host1x
> + - nvidia,tegra30-host1x
> + - nvidia,tegra114-host1x
> + then:
> + patternProperties:
> + "^epp@[0-9a-f]+$":
> + description: encoder pre-processor
> + type: object
> + properties:
> + compatible:
> + enum:
> + - nvidia,tegra20-epp
> + - nvidia,tegra30-epp
> + - nvidia,tegra114-epp
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + items:
> + - description: module reset
> +
> + reset-names:
> + items:
> + - const: epp
> +
> + iommus:
> + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> +
> + unevaluatedProperties: false
I think 'additionalProperties: false' will work here.
> +
> + "^mpe@[0-9a-f]+$":
> + description: video encoder
> + type: object
> + properties:
> + compatible:
> + enum:
> + - nvidia,tegra20-mpe
> + - nvidia,tegra30-mpe
> + - nvidia,tegra114-mpe
> +
> + reg:
> + minItems: 1
> + maxItems: 1
> +
> + interrupts:
> + minItems: 1
> + maxItems: 1
> +
> + clocks:
> + minItems: 1
> + maxItems: 1
> +
> + resets:
> + minItems: 1
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: mpe
> +
> + iommus:
> + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> +
> + unevaluatedProperties: false
> +
> + "^gr2d@[0-9a-f]+$":
> + description: 2D graphics engine
> + type: object
> + properties:
> + compatible:
> + enum:
> + - nvidia,tegra20-gr2d
> + - nvidia,tegra30-gr2d
> + - nvidia,tegra114-gr2d
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + resets:
> + items:
> + - description: module reset
> +
> + reset-names:
> + items:
> + - const: 2d
> +
> + iommus:
> + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> +
> + unevaluatedProperties: false
> +
> + "^gr3d@[0-9a-f]+$":
> + description: 3D graphics engine
> + type: object
> + properties:
> + compatible:
> + enum:
> + - nvidia,tegra20-gr3d
> + - nvidia,tegra30-gr3d
> + - nvidia,tegra114-gr3d
> +
> + reg:
> + maxItems: 1
> +
> + iommus:
> + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> +
> + allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nvidia,tegra30-gr3d
> + then:
> + properties:
> + clocks:
> + items:
> + - description: primary module clock
> + - description: secondary module clock
> +
> + clock-names:
> + items:
> + - const: 3d
> + - const: 3d2
> +
> + resets:
> + items:
> + - description: primary module reset
> + - description: secondary module reset
> +
> + reset-names:
> + items:
> + - const: 3d
> + - const: 3d2
> + else:
> + properties:
> + clocks:
> + items:
> + - description: module clock
> +
> + clock-names:
> + items:
> + - const: 3d
> +
> + resets:
> + items:
> + - description: module reset
> +
> + reset-names:
> + items:
> + - const: 3d
> +
> + unevaluatedProperties: false
> +
> + "^tvo@[0-9a-f]+$":
> + description: TV encoder output
> + type: object
> + properties:
> + # required
> + compatible:
> + enum:
> + - nvidia,tegra20-tvo
> + - nvidia,tegra30-tvo
> + - nvidia,tegra114-tvo
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + status:
> + $ref: "/schemas/dt-core.yaml#/properties/status"
> +
> + unevaluatedProperties: false
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra20-host1x
> + - nvidia,tegra30-host1x
> + - nvidia,tegra114-host1x
> + - nvidia,tegra124-host1x
> + - nvidia,tegra132-host1x
> + - nvidia,tegra210-host1x
> + then:
> + patternProperties:
> + "^dc@[0-9a-f]+$":
> + description: display controller
> + type: object
> + properties:
> + compatible:
> + oneOf:
> + - const: nvidia,tegra20-dc
> + - const: nvidia,tegra30-dc
> + - const: nvidia,tegra114-dc
> + - const: nvidia,tegra124-dc
> + - items:
> + - const: nvidia,tegra124-dc
> + - const: nvidia,tegra132-dc
> + - const: nvidia,tegra210-dc
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: display controller pixel clock
> +
> + clock-names:
> + items:
> + - const: dc
> +
> + resets:
> + items:
> + - description: module reset
> +
> + reset-names:
> + items:
> + - const: dc
> +
> + iommus:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + nvidia,head:
> + description: The number of the display controller head. This is
> + used to setup the various types of output to receive video
> + data from the given head.
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> +
> + allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra20-dc
> + - nvidia,tegra30-dc
> + - nvidia,tegra114-dc
> + then:
> + properties:
> + rgb:
> + description: Each display controller node has a child node,
> + named "rgb", that represents the RGB output associated
> + with the controller.
> + type: object
> + properties:
> + nvidia,ddc-i2c-bus:
> + description: phandle of an I2C controller used for DDC
> + EDID probing
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + nvidia,hpd-gpio:
> + description: specifies a GPIO used for hotplug
> + detection
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + nvidia,edid:
> + description: supplies a binary EDID blob
> + $ref: "/schemas/types.yaml#/definitions/uint8-array"
> +
> + nvidia,panel:
> + description: phandle of a display panel
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + unevaluatedProperties: false
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra186-host1x
> + - nvidia,tegra194-host1x
> + then:
> + patternProperties:
> + "^display-hub@[0-9a-f]+$":
> + properties:
> + compatible:
> + oneOf:
> + - description: NVIDIA Tegra186
> + const: nvidia,tegra186-display
> +
> + - description: NVIDIA Tegra194
> + const: nvidia,tegra194-display
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + ranges:
> + $ref: "/schemas/dt-core.yaml#/properties/ranges"
> +
> + status:
> + $ref: "/schemas/dt-core.yaml#/properties/status"
> +
> + resets:
> + items:
> + - description: display hub reset
> + - description: window group 0 reset
> + - description: window group 1 reset
> + - description: window group 2 reset
> + - description: window group 3 reset
> + - description: window group 4 reset
> + - description: window group 5 reset
> +
> + reset-names:
> + items:
> + - const: misc
> + - const: wgrp0
> + - const: wgrp1
> + - const: wgrp2
> + - const: wgrp3
> + - const: wgrp4
> + - const: wgrp5
> +
> + power-domains:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + patternProperties:
> + "^display@[0-9a-f]+$":
> + description: display controller
> + type: object
> + properties:
> + compatible:
> + enum:
> + - nvidia,tegra186-dc
> + - nvidia,tegra194-dc
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: display controller pixel clock
> +
> + clock-names:
> + items:
> + - const: dc
> +
> + resets:
> + items:
> + - description: display controller reset
> +
> + reset-names:
> + items:
> + - const: dc
> +
> + power-domains:
> + description: A list of phandle and specifiers that identify
> + the power domains that this display controller is part of.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + iommus:
> + description: a phandle and specifier identifying the SMMU
> + master interface of this display controller.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + memory-controllers:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> +
> + nvidia,outputs:
> + description: A list of phandles of outputs that this display
> + controller can drive.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + nvidia,head:
> + description: The number of the display controller head. This
> + is used to setup the various types of output to receive
> + video data from the given head.
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> +
> + unevaluatedProperties: false
> +
> + allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nvidia,tegra186-display
> + then:
> + properties:
> + clocks:
> + items:
> + - description: display core clock
> + - description: display stream compression clock
> + - description: display hub clock
> +
> + clock-names:
> + items:
> + - const: disp
> + - const: dsc
> + - const: hub
> + else:
> + properties:
> + clocks:
> + items:
> + - description: display core clock
> + - description: display hub clock
> +
> + clock-names:
> + items:
> + - const: disp
> + - const: hub
> +
> + unevaluatedProperties: false
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra20-host1x
> + - nvidia,tegra30-host1x
> + - nvidia,tegra114-host1x
> + - nvidia,tegra124-host1x
> + then:
> + patternProperties:
> + "^hdmi@[0-9a-f]+$":
> + description: High Definition Multimedia Interface
> + type: object
> + properties:
> + # required
> + compatible:
> + oneOf:
> + - const: nvidia,tegra20-hdmi
> + - const: nvidia,tegra30-hdmi
> + - const: nvidia,tegra114-hdmi
> + - const: nvidia,tegra124-hdmi
> + - items:
> + - const: nvidia,tegra132-hdmi
> + - const: nvidia,tegra124-hdmi
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: module clock
> + - description: parent clock
> +
> + clock-names:
> + items:
> + - const: hdmi
> + - const: parent
> +
> + resets:
> + items:
> + - description: module reset
> +
> + reset-names:
> + items:
> + - const: hdmi
> +
> + hdmi-supply:
> + description: supply for the +5V HDMI connector pin
> +
> + vdd-supply:
> + description: regulator for supply voltage
> +
> + pll-supply:
> + description: regulator for PLL
> +
> + # optional
> + nvidia,ddc-i2c-bus:
> + description: phandle of an I2C controller used for DDC EDID
> + probing
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + nvidia,hpd-gpio:
> + description: specifies a GPIO used for hotplug detection
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
*-gpio has a type already. Just 'maxItems: 1' needed.
> +
> + nvidia,edid:
> + description: supplies a binary EDID blob
> + $ref: "/schemas/types.yaml#/definitions/uint8-array"
> +
> + nvidia,panel:
> + description: phandle of a display panel
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + status:
> + $ref: "/schemas/dt-core.yaml#/properties/status"
> +
> + phandle:
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> +
> + unevaluatedProperties: false
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra124-host1x
> + - nvidia,tegra210-host1x
> + - nvidia,tegra186-host1x
> + - nvidia,tegra194-host1x
> + then:
> + patternProperties:
> + "^sor@[0-9a-f]+$":
> + description: |
> + The Serial Output Resource (SOR) can be used to drive HDMI, LVDS,
> + eDP and DP outputs.
> +
> + See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
> + regarding the DPAUX pad controller bindings.
> + type: object
> + properties:
> + # required
> + compatible:
> + oneOf:
> + - const: nvidia,tegra124-sor
> + - items:
> + - const: nvidia,tegra132-sor
> + - const: nvidia,tegra124-sor
> + - const: nvidia,tegra210-sor
> + - const: nvidia,tegra210-sor1
> + - const: nvidia,tegra186-sor
> + - const: nvidia,tegra186-sor1
> + - const: nvidia,tegra194-sor
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + resets:
> + items:
> + - description: module reset
> +
> + reset-names:
> + items:
> + - const: sor
> +
> + status:
> + $ref: "/schemas/dt-core.yaml#/properties/status"
'status' should never need to be listed.
> +
> + power-domains:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + avdd-io-hdmi-dp-supply:
> + description: I/O supply for HDMI/DP
> +
> + vdd-hdmi-dp-pll-supply:
> + description: PLL supply for HDMI/DP
> +
> + hdmi-supply:
> + description: +5.0V HDMI connector supply
> +
> + # Tegra186 and later
> + nvidia,interface:
> + description: index of the SOR interface
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> +
> + # optional
> + nvidia,ddc-i2c-bus:
> + description: phandle of an I2C controller used for DDC EDID
> + probing
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + nvidia,hpd-gpio:
> + description: specifies a GPIO used for hotplug detection
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + nvidia,edid:
> + description: supplies a binary EDID blob
> + $ref: "/schemas/types.yaml#/definitions/uint8-array"
> +
> + nvidia,panel:
> + description: phandle of a display panel
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + nvidia,xbar-cfg:
> + description: 5 cells containing the crossbar configuration.
> + Each lane of the SOR, identified by the cell's index, is
> + mapped via the crossbar to the pad specified by the cell's
> + value.
> + $ref: "/schemas/types.yaml#/definitions/uint32-array"
> +
> + # optional when driving an eDP output
> + nvidia,dpaux:
> + description: phandle to a DispayPort AUX interface
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + pinctrl-names: true
> + phandle:
> + $ref: "/schemas/types.yaml#/definitions/uint32"
'phandle' shouldn't need to be listed.
> +
> + patternProperties:
> + "^pinctrl-[0-9]+$": true
pinctrl properties are automatically added, but maybe not if under an
'if' schema. Really, I think probably either this should be split
into multiple schema files or all of these child nodes should be
described at the top-level. I'm not sure it's really important to define
which set of child nodes belong or not for each chip.
I'm stopping there. I think the rest is more of the same comments.
Rob
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
2020-06-17 23:13 ` Rob Herring
@ 2020-06-18 14:16 ` Thierry Reding
2020-06-18 15:23 ` Rob Herring
0 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-18 14:16 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 33709 bytes --]
On Wed, Jun 17, 2020 at 05:13:26PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:18:32PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Convert the Tegra host1x controller bindings from the free-form text
> > format to json-schema.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > .../display/tegra/nvidia,tegra20-host1x.txt | 516 ------
> > .../display/tegra/nvidia,tegra20-host1x.yaml | 1418 +++++++++++++++++
> > 2 files changed, 1418 insertions(+), 516 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
>
>
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > new file mode 100644
> > index 000000000000..3347e1b3c8f0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > @@ -0,0 +1,1418 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/tegra/nvidia,tegra20-host1x.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NVIDIA Tegra host1x controller
> > +
> > +maintainers:
> > + - Thierry Reding <thierry.reding@gmail.com>
> > + - Jon Hunter <jonathanh@nvidia.com>
> > +
> > +description: The host1x top-level node defines a number of children, each
> > + representing one of the host1x client modules defined in this binding.
> > +
> > +properties:
> > + # required
> > + compatible:
> > + oneOf:
> > + - description: NVIDIA Tegra20
> > + items:
> > + - const: nvidia,tegra20-host1x
> > +
> > + - description: NVIDIA Tegra30
> > + items:
> > + - const: nvidia,tegra30-host1x
> > +
> > + - description: NVIDIA Tegra114
> > + items:
> > + - const: nvidia,tegra114-host1x
> > +
> > + - description: NVIDIA Tegra124
> > + items:
> > + - const: nvidia,tegra124-host1x
> > +
> > + - description: NVIDIA Tegra132
> > + items:
> > + - const: nvidia,tegra132-host1x
> > + - const: nvidia,tegra124-host1x
> > +
> > + - description: NVIDIA Tegra210
> > + items:
> > + - const: nvidia,tegra210-host1x
> > +
> > + - description: NVIDIA Tegra186
> > + items:
> > + - const: nvidia,tegra186-host1x
> > +
> > + - description: NVIDIA Tegra194
> > + items:
> > + - const: nvidia,tegra194-host1x
>
> I don't think the descriptions really add much. I'd rather see all the
> single entry cases as 1 'enum'.
Okay, done.
> > +
> > + interrupts:
> > + items:
> > + - description: host1x syncpoint interrupt
> > + - description: host1x general interrupt
> > + minItems: 1
> > + maxItems: 2
> > +
> > + interrupt-names:
> > + items:
> > + - const: syncpt
> > + - const: host1x
> > +
> > + '#address-cells':
> > + description: The number of cells used to represent physical base addresses
> > + in the host1x address space.
> > + enum: [1, 2]
> > +
> > + '#size-cells':
> > + description: The number of cells used to represent the size of an address
> > + range in the host1x address space.
> > + enum: [1, 2]
> > +
> > + # required
>
> Odd comment...
There were a couple of others like this. I've removed them all now.
>
> > + ranges:
> > + description: The mapping of the host1x address space to the CPU address
> > + space.
>
> That's every 'ranges'. If you know how many entries, then define
> 'maxItems'. If not, 'ranges: true' is enough.
Done.
> > +
> > + clocks:
> > + description: Must contain one entry, for the module clock. See
> > + ../clocks/clock-bindings.txt for details.
> > +
> > + clock-names:
> > + items:
> > + - const: host1x
> > +
> > + resets:
> > + description: Must contain an entry for each entry in reset-names. See
> > + ../reset/reset.txt for details.
> > +
> > + reset-names:
> > + items:
> > + - const: host1x
> > +
> > + # optional
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
>
> This is already applied to every 'iommus' property, so you just need to
> define how many entries.
Done.
> > +
> > + memory-controllers:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > +required:
> > + - compatible
> > + - interrupts
> > + - interrupt-names
> > + - '#address-cells'
> > + - '#size-cells'
> > + - ranges
> > + - reg
> > + - clocks
> > + - clock-names
> > + - resets
> > + - reset-names
> > +
> > +unevaluatedProperties: false
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra186-host1x
> > + - nvidia,tegra194-host1x
> > + then:
> > + properties:
> > + reg-names:
> > + items:
> > + - const: hypervisor
> > + - const: vm
> > +
> > + reg:
> > + items:
> > + - description: physical base address and length of the register
> > + region assigned to the VM
> > + - description: physical base address and length of the register
> > + region used by the hypervisor
> > +
> > + required:
> > + - reg-names
> > + else:
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + oneOf:
> > + - const: nvidia,tegra20-host1x
> > + - const: nvidia,tegra30-host1x
> > + - const: nvidia,tegra114-host1x
> > + - const: nvidia,tegra124-host1x
>
> Use 'enum'.
Done.
> > +
> > + then:
> > + patternProperties:
> > + "^vi@[0-9a-f]+$":
> > + description: video input
> > + type: object
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra20-vi
> > + - const: nvidia,tegra30-vi
> > + - const: nvidia,tegra114-vi
> > + - const: nvidia,tegra124-vi
>
> Use a 'enum' for these 4.
Done.
>
> > + - items:
> > + - const: nvidia,tegra132-vi
> > + - const: nvidia,tegra124-vi
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + resets: true
> > +
> > + reset-names:
> > + items:
> > + - const: vi
> > + else:
> > + patternProperties:
> > + "^vi@[0-9a-f]+$":
> > + description: video input
> > + type: object
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra210-vi
> > + - const: nvidia,tegra186-vi
> > + - const: nvidia,tegra194-vi
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + power-domains: true
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + oneOf:
> > + - const: nvidia,tegra210-host1x
> > + then:
> > + patternProperties:
> > + "^vi@[0-9a-f]+$":
>
> type: object
Done.
>
> > + patternProperties:
> > + "^csi@[0-9a-f]+$":
> > + description: camera sensor interface
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra210-csi
> > +
> > + reg: true
> > +
> > + clocks: true
> > +
> > + clock-names:
> > + items:
> > + - const: csi
> > + - const: cilab
> > + - const: cilcd
> > + - const: cile
> > + - const: csi_tpg
> > +
> > + power-domains: true
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra20-host1x
> > + - nvidia,tegra30-host1x
> > + - nvidia,tegra114-host1x
> > + then:
> > + patternProperties:
> > + "^epp@[0-9a-f]+$":
> > + description: encoder pre-processor
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-epp
> > + - nvidia,tegra30-epp
> > + - nvidia,tegra114-epp
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: epp
> > +
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> > +
> > + unevaluatedProperties: false
>
> I think 'additionalProperties: false' will work here.
Yes, it does.
>
> > +
> > + "^mpe@[0-9a-f]+$":
> > + description: video encoder
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-mpe
> > + - nvidia,tegra30-mpe
> > + - nvidia,tegra114-mpe
> > +
> > + reg:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + interrupts:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + clocks:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + resets:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: mpe
> > +
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> > +
> > + unevaluatedProperties: false
> > +
> > + "^gr2d@[0-9a-f]+$":
> > + description: 2D graphics engine
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-gr2d
> > + - nvidia,tegra30-gr2d
> > + - nvidia,tegra114-gr2d
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: 2d
> > +
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> > +
> > + unevaluatedProperties: false
> > +
> > + "^gr3d@[0-9a-f]+$":
> > + description: 3D graphics engine
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-gr3d
> > + - nvidia,tegra30-gr3d
> > + - nvidia,tegra114-gr3d
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + iommus:
> > + $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> > +
> > + allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: nvidia,tegra30-gr3d
> > + then:
> > + properties:
> > + clocks:
> > + items:
> > + - description: primary module clock
> > + - description: secondary module clock
> > +
> > + clock-names:
> > + items:
> > + - const: 3d
> > + - const: 3d2
> > +
> > + resets:
> > + items:
> > + - description: primary module reset
> > + - description: secondary module reset
> > +
> > + reset-names:
> > + items:
> > + - const: 3d
> > + - const: 3d2
> > + else:
> > + properties:
> > + clocks:
> > + items:
> > + - description: module clock
> > +
> > + clock-names:
> > + items:
> > + - const: 3d
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: 3d
> > +
> > + unevaluatedProperties: false
> > +
> > + "^tvo@[0-9a-f]+$":
> > + description: TV encoder output
> > + type: object
> > + properties:
> > + # required
> > + compatible:
> > + enum:
> > + - nvidia,tegra20-tvo
> > + - nvidia,tegra30-tvo
> > + - nvidia,tegra114-tvo
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + status:
> > + $ref: "/schemas/dt-core.yaml#/properties/status"
> > +
> > + unevaluatedProperties: false
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra20-host1x
> > + - nvidia,tegra30-host1x
> > + - nvidia,tegra114-host1x
> > + - nvidia,tegra124-host1x
> > + - nvidia,tegra132-host1x
> > + - nvidia,tegra210-host1x
> > + then:
> > + patternProperties:
> > + "^dc@[0-9a-f]+$":
> > + description: display controller
> > + type: object
> > + properties:
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra20-dc
> > + - const: nvidia,tegra30-dc
> > + - const: nvidia,tegra114-dc
> > + - const: nvidia,tegra124-dc
> > + - items:
> > + - const: nvidia,tegra124-dc
> > + - const: nvidia,tegra132-dc
> > + - const: nvidia,tegra210-dc
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: display controller pixel clock
> > +
> > + clock-names:
> > + items:
> > + - const: dc
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: dc
> > +
> > + iommus:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + nvidia,head:
> > + description: The number of the display controller head. This is
> > + used to setup the various types of output to receive video
> > + data from the given head.
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra20-dc
> > + - nvidia,tegra30-dc
> > + - nvidia,tegra114-dc
> > + then:
> > + properties:
> > + rgb:
> > + description: Each display controller node has a child node,
> > + named "rgb", that represents the RGB output associated
> > + with the controller.
> > + type: object
> > + properties:
> > + nvidia,ddc-i2c-bus:
> > + description: phandle of an I2C controller used for DDC
> > + EDID probing
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + nvidia,hpd-gpio:
> > + description: specifies a GPIO used for hotplug
> > + detection
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + nvidia,edid:
> > + description: supplies a binary EDID blob
> > + $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +
> > + nvidia,panel:
> > + description: phandle of a display panel
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + unevaluatedProperties: false
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra186-host1x
> > + - nvidia,tegra194-host1x
> > + then:
> > + patternProperties:
> > + "^display-hub@[0-9a-f]+$":
> > + properties:
> > + compatible:
> > + oneOf:
> > + - description: NVIDIA Tegra186
> > + const: nvidia,tegra186-display
> > +
> > + - description: NVIDIA Tegra194
> > + const: nvidia,tegra194-display
> > +
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 1
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + ranges:
> > + $ref: "/schemas/dt-core.yaml#/properties/ranges"
> > +
> > + status:
> > + $ref: "/schemas/dt-core.yaml#/properties/status"
> > +
> > + resets:
> > + items:
> > + - description: display hub reset
> > + - description: window group 0 reset
> > + - description: window group 1 reset
> > + - description: window group 2 reset
> > + - description: window group 3 reset
> > + - description: window group 4 reset
> > + - description: window group 5 reset
> > +
> > + reset-names:
> > + items:
> > + - const: misc
> > + - const: wgrp0
> > + - const: wgrp1
> > + - const: wgrp2
> > + - const: wgrp3
> > + - const: wgrp4
> > + - const: wgrp5
> > +
> > + power-domains:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + patternProperties:
> > + "^display@[0-9a-f]+$":
> > + description: display controller
> > + type: object
> > + properties:
> > + compatible:
> > + enum:
> > + - nvidia,tegra186-dc
> > + - nvidia,tegra194-dc
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: display controller pixel clock
> > +
> > + clock-names:
> > + items:
> > + - const: dc
> > +
> > + resets:
> > + items:
> > + - description: display controller reset
> > +
> > + reset-names:
> > + items:
> > + - const: dc
> > +
> > + power-domains:
> > + description: A list of phandle and specifiers that identify
> > + the power domains that this display controller is part of.
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + iommus:
> > + description: a phandle and specifier identifying the SMMU
> > + master interface of this display controller.
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + memory-controllers:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > +
> > + nvidia,outputs:
> > + description: A list of phandles of outputs that this display
> > + controller can drive.
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + nvidia,head:
> > + description: The number of the display controller head. This
> > + is used to setup the various types of output to receive
> > + video data from the given head.
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + unevaluatedProperties: false
> > +
> > + allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: nvidia,tegra186-display
> > + then:
> > + properties:
> > + clocks:
> > + items:
> > + - description: display core clock
> > + - description: display stream compression clock
> > + - description: display hub clock
> > +
> > + clock-names:
> > + items:
> > + - const: disp
> > + - const: dsc
> > + - const: hub
> > + else:
> > + properties:
> > + clocks:
> > + items:
> > + - description: display core clock
> > + - description: display hub clock
> > +
> > + clock-names:
> > + items:
> > + - const: disp
> > + - const: hub
> > +
> > + unevaluatedProperties: false
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra20-host1x
> > + - nvidia,tegra30-host1x
> > + - nvidia,tegra114-host1x
> > + - nvidia,tegra124-host1x
> > + then:
> > + patternProperties:
> > + "^hdmi@[0-9a-f]+$":
> > + description: High Definition Multimedia Interface
> > + type: object
> > + properties:
> > + # required
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra20-hdmi
> > + - const: nvidia,tegra30-hdmi
> > + - const: nvidia,tegra114-hdmi
> > + - const: nvidia,tegra124-hdmi
> > + - items:
> > + - const: nvidia,tegra132-hdmi
> > + - const: nvidia,tegra124-hdmi
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + items:
> > + - description: module clock
> > + - description: parent clock
> > +
> > + clock-names:
> > + items:
> > + - const: hdmi
> > + - const: parent
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: hdmi
> > +
> > + hdmi-supply:
> > + description: supply for the +5V HDMI connector pin
> > +
> > + vdd-supply:
> > + description: regulator for supply voltage
> > +
> > + pll-supply:
> > + description: regulator for PLL
> > +
> > + # optional
> > + nvidia,ddc-i2c-bus:
> > + description: phandle of an I2C controller used for DDC EDID
> > + probing
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + nvidia,hpd-gpio:
> > + description: specifies a GPIO used for hotplug detection
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
>
> *-gpio has a type already. Just 'maxItems: 1' needed.
Yes, that seems to work fine.
> > +
> > + nvidia,edid:
> > + description: supplies a binary EDID blob
> > + $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +
> > + nvidia,panel:
> > + description: phandle of a display panel
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + status:
> > + $ref: "/schemas/dt-core.yaml#/properties/status"
> > +
> > + phandle:
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + unevaluatedProperties: false
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - nvidia,tegra124-host1x
> > + - nvidia,tegra210-host1x
> > + - nvidia,tegra186-host1x
> > + - nvidia,tegra194-host1x
> > + then:
> > + patternProperties:
> > + "^sor@[0-9a-f]+$":
> > + description: |
> > + The Serial Output Resource (SOR) can be used to drive HDMI, LVDS,
> > + eDP and DP outputs.
> > +
> > + See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
> > + regarding the DPAUX pad controller bindings.
> > + type: object
> > + properties:
> > + # required
> > + compatible:
> > + oneOf:
> > + - const: nvidia,tegra124-sor
> > + - items:
> > + - const: nvidia,tegra132-sor
> > + - const: nvidia,tegra124-sor
> > + - const: nvidia,tegra210-sor
> > + - const: nvidia,tegra210-sor1
> > + - const: nvidia,tegra186-sor
> > + - const: nvidia,tegra186-sor1
> > + - const: nvidia,tegra194-sor
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + resets:
> > + items:
> > + - description: module reset
> > +
> > + reset-names:
> > + items:
> > + - const: sor
> > +
> > + status:
> > + $ref: "/schemas/dt-core.yaml#/properties/status"
>
> 'status' should never need to be listed.
This seems to be needed at least when I try to validate against a single
binding, like so:
$ make DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml dtbs_check
I assume that that somehow prevents the tooling from looking at any of
the other bindings, which in turn then causes status and other standard
properties to never be defined and then it flags them as extra and
causes a failure.
I think I've even seen this trigger on dt_binding_check if I happened to
have status in there. Now, you've mentioned elsewhere that we shouldn't
use "status" in examples, so that would work around this. However, I
think I've seen this happen as well in examples that referenced some
node via phandle, and then dt_binding_check would emit an error about
phandle being undefined.
Perhaps this is a problem with the tooling? Should we instruct the
scripts to always include the core schema even if we're only testing a
single YAML file via DT_SCHEMA_FILES?
> > +
> > + power-domains:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + avdd-io-hdmi-dp-supply:
> > + description: I/O supply for HDMI/DP
> > +
> > + vdd-hdmi-dp-pll-supply:
> > + description: PLL supply for HDMI/DP
> > +
> > + hdmi-supply:
> > + description: +5.0V HDMI connector supply
> > +
> > + # Tegra186 and later
> > + nvidia,interface:
> > + description: index of the SOR interface
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > +
> > + # optional
> > + nvidia,ddc-i2c-bus:
> > + description: phandle of an I2C controller used for DDC EDID
> > + probing
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + nvidia,hpd-gpio:
> > + description: specifies a GPIO used for hotplug detection
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > +
> > + nvidia,edid:
> > + description: supplies a binary EDID blob
> > + $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +
> > + nvidia,panel:
> > + description: phandle of a display panel
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + nvidia,xbar-cfg:
> > + description: 5 cells containing the crossbar configuration.
> > + Each lane of the SOR, identified by the cell's index, is
> > + mapped via the crossbar to the pad specified by the cell's
> > + value.
> > + $ref: "/schemas/types.yaml#/definitions/uint32-array"
> > +
> > + # optional when driving an eDP output
> > + nvidia,dpaux:
> > + description: phandle to a DispayPort AUX interface
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + pinctrl-names: true
> > + phandle:
> > + $ref: "/schemas/types.yaml#/definitions/uint32"
>
> 'phandle' shouldn't need to be listed.
>
> > +
> > + patternProperties:
> > + "^pinctrl-[0-9]+$": true
>
> pinctrl properties are automatically added, but maybe not if under an
> 'if' schema. Really, I think probably either this should be split
> into multiple schema files or all of these child nodes should be
> described at the top-level. I'm not sure it's really important to define
> which set of child nodes belong or not for each chip.
I'm not too worried about the set of child nodes for each chip, but I
think having this all in one file underlines the importance of the
hierarchy. If these were discrete bindings for each of the compatible
strings it'd be easy for someone to create them as standalone nodes in
device tree, but that's not something that would work. All of these
devices are children of host1x and they do depend on host1x for a lot
of the functionality, so the hierarchy must be respected.
> I'm stopping there. I think the rest is more of the same comments.
I've made a pass over the whole file and fixed the issues that you
pointed out above in other places.
Sounds like the biggest remaining issue is with the duplicated standard
properties. I'm not a huge fan of giving up on doing the right thing
because the tooling can't deal with it. I think we should fix the
tooling to do the right thing. So if there's something in the core DT
schema then it should apply regardless of what mode we run in. Much of
the above issues should go away once that's fixed.
Any thoughts on making some of the schema files "always included"? I
haven't looked at this side of the tooling at all yet, so I'm not sure
how difficult that would be, but if you're okay with it conceptually I
can take a closer look.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
2020-06-18 14:16 ` Thierry Reding
@ 2020-06-18 15:23 ` Rob Herring
2020-06-19 8:08 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Rob Herring @ 2020-06-18 15:23 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Thu, Jun 18, 2020 at 8:16 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, Jun 17, 2020 at 05:13:26PM -0600, Rob Herring wrote:
> > On Fri, Jun 12, 2020 at 04:18:32PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > >
> > > Convert the Tegra host1x controller bindings from the free-form text
> > > format to json-schema.
> > >
> > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > ---
> > > .../display/tegra/nvidia,tegra20-host1x.txt | 516 ------
> > > .../display/tegra/nvidia,tegra20-host1x.yaml | 1418 +++++++++++++++++
> > > 2 files changed, 1418 insertions(+), 516 deletions(-)
> > > delete mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > > create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
[...]
> > > + - if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + enum:
> > > + - nvidia,tegra124-host1x
> > > + - nvidia,tegra210-host1x
> > > + - nvidia,tegra186-host1x
> > > + - nvidia,tegra194-host1x
> > > + then:
> > > + patternProperties:
> > > + "^sor@[0-9a-f]+$":
> > > + description: |
> > > + The Serial Output Resource (SOR) can be used to drive HDMI, LVDS,
> > > + eDP and DP outputs.
> > > +
> > > + See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
> > > + regarding the DPAUX pad controller bindings.
> > > + type: object
> > > + properties:
> > > + # required
> > > + compatible:
> > > + oneOf:
> > > + - const: nvidia,tegra124-sor
> > > + - items:
> > > + - const: nvidia,tegra132-sor
> > > + - const: nvidia,tegra124-sor
> > > + - const: nvidia,tegra210-sor
> > > + - const: nvidia,tegra210-sor1
> > > + - const: nvidia,tegra186-sor
> > > + - const: nvidia,tegra186-sor1
> > > + - const: nvidia,tegra194-sor
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + resets:
> > > + items:
> > > + - description: module reset
> > > +
> > > + reset-names:
> > > + items:
> > > + - const: sor
> > > +
> > > + status:
> > > + $ref: "/schemas/dt-core.yaml#/properties/status"
> >
> > 'status' should never need to be listed.
>
> This seems to be needed at least when I try to validate against a single
> binding, like so:
>
> $ make DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml dtbs_check
>
> I assume that that somehow prevents the tooling from looking at any of
> the other bindings, which in turn then causes status and other standard
> properties to never be defined and then it flags them as extra and
> causes a failure.
I'm surprised using DT_SCHEMA_FILES makes a difference. I'm guessing
that has your 'unevaluatedProperties' support. If so, that means
there's an unintended side effect that any common schema property
becomes always allowed. That's good for 'status' and 'phandle', but
not so much for 'reg', '*-gpios, '*-names', etc.
> I think I've even seen this trigger on dt_binding_check if I happened to
> have status in there. Now, you've mentioned elsewhere that we shouldn't
> use "status" in examples, so that would work around this. However, I
> think I've seen this happen as well in examples that referenced some
> node via phandle, and then dt_binding_check would emit an error about
> phandle being undefined.
>
> Perhaps this is a problem with the tooling? Should we instruct the
> scripts to always include the core schema even if we're only testing a
> single YAML file via DT_SCHEMA_FILES?
The purpose of DT_SCHEMA_FILES is to see warnings just from that
schema file. If the core schema was warning free, we could add that,
but it's not. Plus that wouldn't solve the problem here. 'status' and
'phandle' are added to each schema by the tooling (along with other
things), not by another schema file (well, they are in another schema
file, but they are added to each schema so that 'additionalProperties:
false' works).
This is certainly a limitation in the tooling in that what you have is
a bit different from the expected form. Generally it is expected that
everything is defined under the top-level 'properties' and then any
'if/then' schema only add further constraints. However, you have the
child nodes only defined under an if/then. We could fix that, but I'm
not sure I want to. IMO, extensive use of if/then is a sign the schema
should be split up. More on that below.
> > > + pinctrl-names: true
> > > + phandle:
> > > + $ref: "/schemas/types.yaml#/definitions/uint32"
> >
> > 'phandle' shouldn't need to be listed.
> >
> > > +
> > > + patternProperties:
> > > + "^pinctrl-[0-9]+$": true
> >
> > pinctrl properties are automatically added, but maybe not if under an
> > 'if' schema. Really, I think probably either this should be split
> > into multiple schema files or all of these child nodes should be
> > described at the top-level. I'm not sure it's really important to define
> > which set of child nodes belong or not for each chip.
>
> I'm not too worried about the set of child nodes for each chip, but I
> think having this all in one file underlines the importance of the
> hierarchy. If these were discrete bindings for each of the compatible
> strings it'd be easy for someone to create them as standalone nodes in
> device tree, but that's not something that would work. All of these
> devices are children of host1x and they do depend on host1x for a lot
> of the functionality, so the hierarchy must be respected.
I'm not saying don't describe the hierarchy.
The first option is 1 host1x schema file per SoC (roughly) and the
'host1x' parent node would be duplicated in each one. That doesn't
worry me too much as it's all standard properties and not that many of
them. Though you could have a common 'host1x-bus.yaml' just describing
the parent node properties that each <soc>-host1x.yaml references.
The 2nd option is keep this as a single file, but just move every
child node definition under the top-level 'patternProperties'. This
option has the limitation that you can't enforce which child nodes are
valid per SoC.
> > I'm stopping there. I think the rest is more of the same comments.
>
> I've made a pass over the whole file and fixed the issues that you
> pointed out above in other places.
>
> Sounds like the biggest remaining issue is with the duplicated standard
> properties. I'm not a huge fan of giving up on doing the right thing
> because the tooling can't deal with it. I think we should fix the
> tooling to do the right thing. So if there's something in the core DT
> schema then it should apply regardless of what mode we run in. Much of
> the above issues should go away once that's fixed.
>
> Any thoughts on making some of the schema files "always included"? I
> haven't looked at this side of the tooling at all yet, so I'm not sure
> how difficult that would be, but if you're okay with it conceptually I
> can take a closer look.
Hopefully, it's clear why that doesn't help here. But don't worry,
there's plenty of other work to do on the tooling. :)
Rob
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema
2020-06-18 15:23 ` Rob Herring
@ 2020-06-19 8:08 ` Thierry Reding
0 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-19 8:08 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 8664 bytes --]
On Thu, Jun 18, 2020 at 09:23:58AM -0600, Rob Herring wrote:
> On Thu, Jun 18, 2020 at 8:16 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Wed, Jun 17, 2020 at 05:13:26PM -0600, Rob Herring wrote:
> > > On Fri, Jun 12, 2020 at 04:18:32PM +0200, Thierry Reding wrote:
> > > > From: Thierry Reding <treding@nvidia.com>
> > > >
> > > > Convert the Tegra host1x controller bindings from the free-form text
> > > > format to json-schema.
> > > >
> > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > ---
> > > > .../display/tegra/nvidia,tegra20-host1x.txt | 516 ------
> > > > .../display/tegra/nvidia,tegra20-host1x.yaml | 1418 +++++++++++++++++
> > > > 2 files changed, 1418 insertions(+), 516 deletions(-)
> > > > delete mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
> > > > create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
>
> [...]
>
> > > > + - if:
> > > > + properties:
> > > > + compatible:
> > > > + contains:
> > > > + enum:
> > > > + - nvidia,tegra124-host1x
> > > > + - nvidia,tegra210-host1x
> > > > + - nvidia,tegra186-host1x
> > > > + - nvidia,tegra194-host1x
> > > > + then:
> > > > + patternProperties:
> > > > + "^sor@[0-9a-f]+$":
> > > > + description: |
> > > > + The Serial Output Resource (SOR) can be used to drive HDMI, LVDS,
> > > > + eDP and DP outputs.
> > > > +
> > > > + See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
> > > > + regarding the DPAUX pad controller bindings.
> > > > + type: object
> > > > + properties:
> > > > + # required
> > > > + compatible:
> > > > + oneOf:
> > > > + - const: nvidia,tegra124-sor
> > > > + - items:
> > > > + - const: nvidia,tegra132-sor
> > > > + - const: nvidia,tegra124-sor
> > > > + - const: nvidia,tegra210-sor
> > > > + - const: nvidia,tegra210-sor1
> > > > + - const: nvidia,tegra186-sor
> > > > + - const: nvidia,tegra186-sor1
> > > > + - const: nvidia,tegra194-sor
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + interrupts:
> > > > + maxItems: 1
> > > > +
> > > > + resets:
> > > > + items:
> > > > + - description: module reset
> > > > +
> > > > + reset-names:
> > > > + items:
> > > > + - const: sor
> > > > +
> > > > + status:
> > > > + $ref: "/schemas/dt-core.yaml#/properties/status"
> > >
> > > 'status' should never need to be listed.
> >
> > This seems to be needed at least when I try to validate against a single
> > binding, like so:
> >
> > $ make DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml dtbs_check
> >
> > I assume that that somehow prevents the tooling from looking at any of
> > the other bindings, which in turn then causes status and other standard
> > properties to never be defined and then it flags them as extra and
> > causes a failure.
>
> I'm surprised using DT_SCHEMA_FILES makes a difference. I'm guessing
> that has your 'unevaluatedProperties' support. If so, that means
> there's an unintended side effect that any common schema property
> becomes always allowed. That's good for 'status' and 'phandle', but
> not so much for 'reg', '*-gpios, '*-names', etc.
I don't think that's an unintended side-effect. If the property
validates against a schema it counts as evaluated, doesn't it? In order
to avoid that we would somehow have to restrict which schemas contribute
to the evaluatedProperties annotation and I don't think there's a way to
do that because we don't know which out of all the schemas is relevant.
> > I think I've even seen this trigger on dt_binding_check if I happened to
> > have status in there. Now, you've mentioned elsewhere that we shouldn't
> > use "status" in examples, so that would work around this. However, I
> > think I've seen this happen as well in examples that referenced some
> > node via phandle, and then dt_binding_check would emit an error about
> > phandle being undefined.
> >
> > Perhaps this is a problem with the tooling? Should we instruct the
> > scripts to always include the core schema even if we're only testing a
> > single YAML file via DT_SCHEMA_FILES?
>
> The purpose of DT_SCHEMA_FILES is to see warnings just from that
> schema file. If the core schema was warning free, we could add that,
> but it's not. Plus that wouldn't solve the problem here. 'status' and
> 'phandle' are added to each schema by the tooling (along with other
> things), not by another schema file (well, they are in another schema
> file, but they are added to each schema so that 'additionalProperties:
> false' works).
>
> This is certainly a limitation in the tooling in that what you have is
> a bit different from the expected form. Generally it is expected that
> everything is defined under the top-level 'properties' and then any
> 'if/then' schema only add further constraints. However, you have the
> child nodes only defined under an if/then. We could fix that, but I'm
> not sure I want to. IMO, extensive use of if/then is a sign the schema
> should be split up. More on that below.
Okay, I see your point.
> > > > + pinctrl-names: true
> > > > + phandle:
> > > > + $ref: "/schemas/types.yaml#/definitions/uint32"
> > >
> > > 'phandle' shouldn't need to be listed.
> > >
> > > > +
> > > > + patternProperties:
> > > > + "^pinctrl-[0-9]+$": true
> > >
> > > pinctrl properties are automatically added, but maybe not if under an
> > > 'if' schema. Really, I think probably either this should be split
> > > into multiple schema files or all of these child nodes should be
> > > described at the top-level. I'm not sure it's really important to define
> > > which set of child nodes belong or not for each chip.
> >
> > I'm not too worried about the set of child nodes for each chip, but I
> > think having this all in one file underlines the importance of the
> > hierarchy. If these were discrete bindings for each of the compatible
> > strings it'd be easy for someone to create them as standalone nodes in
> > device tree, but that's not something that would work. All of these
> > devices are children of host1x and they do depend on host1x for a lot
> > of the functionality, so the hierarchy must be respected.
>
> I'm not saying don't describe the hierarchy.
>
> The first option is 1 host1x schema file per SoC (roughly) and the
> 'host1x' parent node would be duplicated in each one. That doesn't
> worry me too much as it's all standard properties and not that many of
> them. Though you could have a common 'host1x-bus.yaml' just describing
> the parent node properties that each <soc>-host1x.yaml references.
>
> The 2nd option is keep this as a single file, but just move every
> child node definition under the top-level 'patternProperties'. This
> option has the limitation that you can't enforce which child nodes are
> valid per SoC.
Okay, I'll give the first option a try and see where I end up.
> > > I'm stopping there. I think the rest is more of the same comments.
> >
> > I've made a pass over the whole file and fixed the issues that you
> > pointed out above in other places.
> >
> > Sounds like the biggest remaining issue is with the duplicated standard
> > properties. I'm not a huge fan of giving up on doing the right thing
> > because the tooling can't deal with it. I think we should fix the
> > tooling to do the right thing. So if there's something in the core DT
> > schema then it should apply regardless of what mode we run in. Much of
> > the above issues should go away once that's fixed.
> >
> > Any thoughts on making some of the schema files "always included"? I
> > haven't looked at this side of the tooling at all yet, so I'm not sure
> > how difficult that would be, but if you're okay with it conceptually I
> > can take a closer look.
>
> Hopefully, it's clear why that doesn't help here. But don't worry,
> there's plenty of other work to do on the tooling. :)
Yes, I think I understand now.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 08/38] dt-bindings: display: tegra: Document interconnect paths
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (6 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 07/38] dt-bindings: display: tegra: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 15:52 ` Dmitry Osipenko
2020-06-12 14:18 ` [PATCH 09/38] dt-bindings: gpu: tegra: Convert to json-schema Thierry Reding
` (29 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../display/tegra/nvidia,tegra20-host1x.yaml | 52 ++++++++++++++++---
1 file changed, 46 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
index 3347e1b3c8f0..684fe25641f1 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
@@ -97,8 +97,17 @@ properties:
iommus:
$ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
- memory-controllers:
- $ref: /schemas/types.yaml#/definitions/phandle-array
+ interconnects:
+ description: Description of the interconnect paths for the host1x
+ controller; see ../interconnect/interconnect.txt for details.
+ items:
+ - description: memory read client for host1x
+
+ interconnect-names:
+ description: A list of names identifying each entry listed in the
+ "interconnects" property.
+ items:
+ - const: dma-mem # read
required:
- compatible
@@ -489,6 +498,26 @@ allOf:
iommus:
$ref: "/schemas/types.yaml#/definitions/phandle-array"
+ #interconnects:
+ # items:
+ # - description: memory read client for window A
+ # - description: memory read client for window B
+ # - description: memory read client for window C
+ # - description: memory read client for cursor
+ # # disp only
+ # - description: memory read client for window T
+ # - description: memory read client for window D
+
+ #interconnect-names:
+ # items:
+ # - const: wina
+ # - const: winb
+ # - const: winc
+ # - const: cursor
+ # # disp only
+ # - const: wint
+ # - const: wind
+
nvidia,head:
description: The number of the display controller head. This is
used to setup the various types of output to receive video
@@ -634,8 +663,15 @@ allOf:
master interface of this display controller.
$ref: "/schemas/types.yaml#/definitions/phandle-array"
- memory-controllers:
- $ref: /schemas/types.yaml#/definitions/phandle-array
+ interconnects:
+ description: Description of the interconnect paths for the
+ display controller; see ../interconnect/interconnect.txt
+ for details.
+
+ interconnect-names:
+ items:
+ - const: dma-mem # read-0
+ - const: read-1
nvidia,outputs:
description: A list of phandles of outputs that this display
@@ -1027,8 +1063,12 @@ allOf:
iommus:
$ref: "/schemas/types.yaml#/definitions/phandle-array"
- memory-controllers:
- $ref: /schemas/types.yaml#/definitions/phandle-array
+ interconnects: true
+
+ interconnect-names:
+ items:
+ - const: dma-mem # read
+ - const: write
unevaluatedProperties: false
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 08/38] dt-bindings: display: tegra: Document interconnect paths
2020-06-12 14:18 ` [PATCH 08/38] dt-bindings: display: tegra: Document interconnect paths Thierry Reding
@ 2020-06-12 15:52 ` Dmitry Osipenko
2020-06-16 14:47 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Dmitry Osipenko @ 2020-06-12 15:52 UTC (permalink / raw)
To: Thierry Reding, Rob Herring; +Cc: devicetree, linux-tegra
Hello Thierry,
12.06.2020 17:18, Thierry Reding пишет:
> From: Thierry Reding <treding@nvidia.com>
Commit description is missing, checkpatch should warn about it.
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../display/tegra/nvidia,tegra20-host1x.yaml | 52 ++++++++++++++++---
> 1 file changed, 46 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> index 3347e1b3c8f0..684fe25641f1 100644
> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> @@ -97,8 +97,17 @@ properties:
> iommus:
> $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
>
> - memory-controllers:
> - $ref: /schemas/types.yaml#/definitions/phandle-array
Why memory-controllers property is removed?
> + interconnects:
> + description: Description of the interconnect paths for the host1x
> + controller; see ../interconnect/interconnect.txt for details.
> + items:
> + - description: memory read client for host1x
> +
> + interconnect-names:
> + description: A list of names identifying each entry listed in the
> + "interconnects" property.
> + items:
> + - const: dma-mem # read
Please notice that Host1x has two memory clients: one for DMA engine and
second I don't know what's for, maybe for indirect memory accesses. Why
you skipped the second path?
> required:
> - compatible
> @@ -489,6 +498,26 @@ allOf:
> iommus:
> $ref: "/schemas/types.yaml#/definitions/phandle-array"
>
> + #interconnects:
> + # items:
> + # - description: memory read client for window A
> + # - description: memory read client for window B
> + # - description: memory read client for window C
> + # - description: memory read client for cursor
> + # # disp only
> + # - description: memory read client for window T
> + # - description: memory read client for window D
> +
> + #interconnect-names:
> + # items:
> + # - const: wina
> + # - const: winb
> + # - const: winc
> + # - const: cursor
> + # # disp only
> + # - const: wint
> + # - const: wind
Is this really intended to be commented out? Looks like this is an
unfinished patch.
In the patch [1] I used memory client names for the interconnect paths.
I like yours variant of the naming, it is more intuitive.
[1]
https://patchwork.ozlabs.org/project/linux-tegra/patch/20200609131404.17523-23-digetx@gmail.com/
I'll rebase my series on top of yours patches once you'll get them into
linux-next. Looking forward to v2!
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 08/38] dt-bindings: display: tegra: Document interconnect paths
2020-06-12 15:52 ` Dmitry Osipenko
@ 2020-06-16 14:47 ` Thierry Reding
0 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-16 14:47 UTC (permalink / raw)
To: Dmitry Osipenko; +Cc: Rob Herring, devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 4748 bytes --]
On Fri, Jun 12, 2020 at 06:52:44PM +0300, Dmitry Osipenko wrote:
> Hello Thierry,
>
> 12.06.2020 17:18, Thierry Reding пишет:
> > From: Thierry Reding <treding@nvidia.com>
> Commit description is missing, checkpatch should warn about it.
>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > .../display/tegra/nvidia,tegra20-host1x.yaml | 52 ++++++++++++++++---
> > 1 file changed, 46 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > index 3347e1b3c8f0..684fe25641f1 100644
> > --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > @@ -97,8 +97,17 @@ properties:
> > iommus:
> > $ref: "/schemas/iommu/iommu.yaml#/properties/iommus"
> >
> > - memory-controllers:
> > - $ref: /schemas/types.yaml#/definitions/phandle-array
>
> Why memory-controllers property is removed?
Because it was accidentally added in patch 7. This is leftover from an
earlier set of patches.
> > + interconnects:
> > + description: Description of the interconnect paths for the host1x
> > + controller; see ../interconnect/interconnect.txt for details.
> > + items:
> > + - description: memory read client for host1x
> > +
> > + interconnect-names:
> > + description: A list of names identifying each entry listed in the
> > + "interconnects" property.
> > + items:
> > + - const: dma-mem # read
>
> Please notice that Host1x has two memory clients: one for DMA engine and
> second I don't know what's for, maybe for indirect memory accesses. Why
> you skipped the second path?
I'm primarily targetting Tegra186 and Tegra194 with these patches
because we need the interconnects properties on those platforms in order
to correctly set the DMA masks at a global scope. For Tegra186 and
Tegra194 I can only see a single memory client for host1x.
Looking at the register documentation, the host1xw and host1xr clients
do exist on Tegra210 and earlier and they are used for indirect writes
and reads, respectively.
I don't think we use indirect reads/writes, so we can probably do
without the corresponding memory clients. Alternatively we could
conditionally add them on Tegra210 and earlier.
Thierry
> > required:
> > - compatible
> > @@ -489,6 +498,26 @@ allOf:
> > iommus:
> > $ref: "/schemas/types.yaml#/definitions/phandle-array"
> >
> > + #interconnects:
> > + # items:
> > + # - description: memory read client for window A
> > + # - description: memory read client for window B
> > + # - description: memory read client for window C
> > + # - description: memory read client for cursor
> > + # # disp only
> > + # - description: memory read client for window T
> > + # - description: memory read client for window D
> > +
> > + #interconnect-names:
> > + # items:
> > + # - const: wina
> > + # - const: winb
> > + # - const: winc
> > + # - const: cursor
> > + # # disp only
> > + # - const: wint
> > + # - const: wind
>
> Is this really intended to be commented out? Looks like this is an
> unfinished patch.
I started adding this after finishing Tegra186 and Tegra194, but then I
ran into various other issues and wanted to do this step by step, so I
plan to go back to Tegra210 and earlier later on and stub them out.
However, since I had already done the research I wanted to leave these
in here for later reference, so I didn't have to go back and look this
up again.
> In the patch [1] I used memory client names for the interconnect paths.
> I like yours variant of the naming, it is more intuitive.
I only noticed after posting this series that you had sent out the
series for interconnects and that it conflicted in the bindings.
But yeah, I do also like the contextual names better because they are
more intuitive.
> [1]
> https://patchwork.ozlabs.org/project/linux-tegra/patch/20200609131404.17523-23-digetx@gmail.com/
>
> I'll rebase my series on top of yours patches once you'll get them into
> linux-next. Looking forward to v2!
There's quite a bit to review here, but I also have a couple of patches
that depend on these, so yeah, it'd be great if this could go in sooner
rather than later.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 09/38] dt-bindings: gpu: tegra: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (7 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 08/38] dt-bindings: display: tegra: Document interconnect paths Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-18 2:29 ` Rob Herring
2020-06-12 14:18 ` [PATCH 10/38] dt-bindings: gpu: tegra: Document interconnect paths Thierry Reding
` (28 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the NVIDIA Tegra GPU bindings from the previous free-form text
format to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/gpu/nvidia,gk20a.txt | 90 ---------
.../devicetree/bindings/gpu/nvidia,gk20a.yaml | 189 ++++++++++++++++++
2 files changed, 189 insertions(+), 90 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
create mode 100644 Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
deleted file mode 100644
index f32bbba4d3bc..000000000000
--- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
+++ /dev/null
@@ -1,90 +0,0 @@
-NVIDIA Tegra Graphics Processing Units
-
-Required properties:
-- compatible: "nvidia,<gpu>"
- Currently recognized values:
- - nvidia,gk20a
- - nvidia,gm20b
- - nvidia,gp10b
-- reg: Physical base address and length of the controller's registers.
- Must contain two entries:
- - first entry for bar0
- - second entry for bar1
-- interrupts: Must contain an entry for each entry in interrupt-names.
- See ../interrupt-controller/interrupts.txt for details.
-- interrupt-names: Must include the following entries:
- - stall
- - nonstall
-- vdd-supply: regulator for supply voltage. Only required for GPUs not using
- power domains.
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - gpu
- - pwr
-If the compatible string is "nvidia,gm20b", then the following clock
-is also required:
- - ref
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - gpu
-- power-domains: GPUs that make use of power domains can define this property
- instead of vdd-supply. Currently "nvidia,gp10b" makes use of this.
-
-Optional properties:
-- iommus: A reference to the IOMMU. See ../iommu/iommu.txt for details.
-
-Example for GK20A:
-
- gpu@57000000 {
- compatible = "nvidia,gk20a";
- reg = <0x0 0x57000000 0x0 0x01000000>,
- <0x0 0x58000000 0x0 0x01000000>;
- interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "stall", "nonstall";
- vdd-supply = <&vdd_gpu>;
- clocks = <&tegra_car TEGRA124_CLK_GPU>,
- <&tegra_car TEGRA124_CLK_PLL_P_OUT5>;
- clock-names = "gpu", "pwr";
- resets = <&tegra_car 184>;
- reset-names = "gpu";
- iommus = <&mc TEGRA_SWGROUP_GPU>;
- };
-
-Example for GM20B:
-
- gpu@57000000 {
- compatible = "nvidia,gm20b";
- reg = <0x0 0x57000000 0x0 0x01000000>,
- <0x0 0x58000000 0x0 0x01000000>;
- interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "stall", "nonstall";
- clocks = <&tegra_car TEGRA210_CLK_GPU>,
- <&tegra_car TEGRA210_CLK_PLL_P_OUT5>,
- <&tegra_car TEGRA210_CLK_PLL_G_REF>;
- clock-names = "gpu", "pwr", "ref";
- resets = <&tegra_car 184>;
- reset-names = "gpu";
- iommus = <&mc TEGRA_SWGROUP_GPU>;
- };
-
-Example for GP10B:
-
- gpu@17000000 {
- compatible = "nvidia,gp10b";
- reg = <0x0 0x17000000 0x0 0x1000000>,
- <0x0 0x18000000 0x0 0x1000000>;
- interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH
- GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "stall", "nonstall";
- clocks = <&bpmp TEGRA186_CLK_GPCCLK>,
- <&bpmp TEGRA186_CLK_GPU>;
- clock-names = "gpu", "pwr";
- resets = <&bpmp TEGRA186_RESET_GPU>;
- reset-names = "gpu";
- power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>;
- iommus = <&smmu TEGRA186_SID_GPU>;
- };
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
new file mode 100644
index 000000000000..726ef39b2221
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
@@ -0,0 +1,189 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/nvidia,gk20a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Graphics Processing Units
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - nvidia,gk20a
+ - nvidia,gm20b
+ - nvidia,gp10b
+
+ reg:
+ items:
+ - description: base address and size for BAR0
+ - description: base address and size for BAR1
+
+ interrupts:
+ items:
+ - description: stalling interrupt
+ - description: non-stalling interrupt
+
+ interrupt-names:
+ items:
+ - const: stall
+ - const: nonstall
+
+ clocks:
+ minItems: 2
+ maxItems: 3
+ items:
+ - description: GPU clock
+ - description: PWR clock
+ - description: REF clock
+
+ clock-names:
+ minItems: 2
+ maxItems: 3
+ items:
+ - const: gpu
+ - const: pwr
+ - const: ref
+
+ resets:
+ items:
+ - description: GPU reset
+
+ reset-names:
+ minItems: 1
+ maxItems: 1
+ items:
+ - const: gpu
+
+ power-domains:
+ description: GPUs that make use of power domains can define this property
+ instead of vdd-supply. Currently "nvidia,gp10b" makes use of this.
+
+ vdd-supply:
+ description: GPU power supply.
+
+ iommus:
+ description: The phandle of the IOMMU and the IOMMU specifier. See
+ ../iommu/iommu.txt for details.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,gm20b
+ then:
+ required:
+ - vdd-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,gm20b
+ then:
+ properties:
+ clock-names:
+ minItems: 3
+
+ required:
+ - vdd-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,gp10b
+ then:
+ required:
+ - power-domains
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra124-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/tegra124-mc.h>
+
+ gpu@57000000 {
+ compatible = "nvidia,gk20a";
+ reg = <0x0 0x57000000 0x0 0x01000000>,
+ <0x0 0x58000000 0x0 0x01000000>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "stall", "nonstall";
+ vdd-supply = <&vdd_gpu>;
+ clocks = <&tegra_car TEGRA124_CLK_GPU>,
+ <&tegra_car TEGRA124_CLK_PLL_P_OUT5>;
+ clock-names = "gpu", "pwr";
+ resets = <&tegra_car 184>;
+ reset-names = "gpu";
+ iommus = <&mc TEGRA_SWGROUP_GPU>;
+ };
+
+ - |
+ #include <dt-bindings/clock/tegra210-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ /*
+ * XXX can't include this because it conflicts with the tegra124-mc.h
+ * include from the Tegra124 example above.
+ */
+ /*
+ #include <dt-bindings/memory/tegra210-mc.h>
+ */
+
+ gpu@57000000 {
+ compatible = "nvidia,gm20b";
+ reg = <0x0 0x57000000 0x0 0x01000000>,
+ <0x0 0x58000000 0x0 0x01000000>;
+ interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "stall", "nonstall";
+ vdd-supply = <&vdd_gpu>;
+ clocks = <&tegra_car TEGRA210_CLK_GPU>,
+ <&tegra_car TEGRA210_CLK_PLL_P_OUT5>,
+ <&tegra_car TEGRA210_CLK_PLL_G_REF>;
+ clock-names = "gpu", "pwr", "ref";
+ resets = <&tegra_car 184>;
+ reset-names = "gpu";
+ iommus = <&mc TEGRA_SWGROUP_GPU>;
+ };
+
+ - |
+ #include <dt-bindings/clock/tegra186-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/tegra186-mc.h>
+ #include <dt-bindings/power/tegra186-powergate.h>
+ #include <dt-bindings/reset/tegra186-reset.h>
+
+ gpu@17000000 {
+ compatible = "nvidia,gp10b";
+ reg = <0x0 0x17000000 0x0 0x1000000>,
+ <0x0 0x18000000 0x0 0x1000000>;
+ interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "stall", "nonstall";
+ clocks = <&bpmp TEGRA186_CLK_GPCCLK>,
+ <&bpmp TEGRA186_CLK_GPU>;
+ clock-names = "gpu", "pwr";
+ resets = <&bpmp TEGRA186_RESET_GPU>;
+ reset-names = "gpu";
+ power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>;
+ iommus = <&smmu TEGRA186_SID_GPU>;
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 09/38] dt-bindings: gpu: tegra: Convert to json-schema
2020-06-12 14:18 ` [PATCH 09/38] dt-bindings: gpu: tegra: Convert to json-schema Thierry Reding
@ 2020-06-18 2:29 ` Rob Herring
0 siblings, 0 replies; 76+ messages in thread
From: Rob Herring @ 2020-06-18 2:29 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:18:34PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the NVIDIA Tegra GPU bindings from the previous free-form text
> format to json-schema.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../devicetree/bindings/gpu/nvidia,gk20a.txt | 90 ---------
> .../devicetree/bindings/gpu/nvidia,gk20a.yaml | 189 ++++++++++++++++++
> 2 files changed, 189 insertions(+), 90 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
> create mode 100644 Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
> new file mode 100644
> index 000000000000..726ef39b2221
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
> @@ -0,0 +1,189 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpu/nvidia,gk20a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra Graphics Processing Units
> +
> +maintainers:
> + - Thierry Reding <thierry.reding@gmail.com>
> + - Jon Hunter <jonathanh@nvidia.com>
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - nvidia,gk20a
> + - nvidia,gm20b
> + - nvidia,gp10b
> +
> + reg:
> + items:
> + - description: base address and size for BAR0
> + - description: base address and size for BAR1
> +
> + interrupts:
> + items:
> + - description: stalling interrupt
> + - description: non-stalling interrupt
> +
> + interrupt-names:
> + items:
> + - const: stall
> + - const: nonstall
> +
> + clocks:
> + minItems: 2
> + maxItems: 3
> + items:
> + - description: GPU clock
> + - description: PWR clock
> + - description: REF clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 3
> + items:
> + - const: gpu
> + - const: pwr
> + - const: ref
> +
> + resets:
> + items:
> + - description: GPU reset
> +
> + reset-names:
> + minItems: 1
> + maxItems: 1
You can drop minItems/maxItems. The tooling will add them based on
'items' length if not specified.
> + items:
> + - const: gpu
> +
> + power-domains:
> + description: GPUs that make use of power domains can define this property
> + instead of vdd-supply. Currently "nvidia,gp10b" makes use of this.
How many?
> +
> + vdd-supply:
> + description: GPU power supply.
> +
> + iommus:
> + description: The phandle of the IOMMU and the IOMMU specifier. See
> + ../iommu/iommu.txt for details.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
Again, just need to define how many.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-names
> + - clocks
> + - clock-names
> + - resets
> + - reset-names
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nvidia,gm20b
> + then:
> + required:
> + - vdd-supply
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nvidia,gm20b
> + then:
> + properties:
> + clock-names:
> + minItems: 3
> +
> + required:
> + - vdd-supply
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nvidia,gp10b
> + then:
> + required:
> + - power-domains
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/tegra124-car.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/memory/tegra124-mc.h>
> +
> + gpu@57000000 {
> + compatible = "nvidia,gk20a";
> + reg = <0x0 0x57000000 0x0 0x01000000>,
> + <0x0 0x58000000 0x0 0x01000000>;
The default size is 1 cell each for examples. So either use that or add
a parent node defining 2 cells.
> + interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "stall", "nonstall";
> + vdd-supply = <&vdd_gpu>;
> + clocks = <&tegra_car TEGRA124_CLK_GPU>,
> + <&tegra_car TEGRA124_CLK_PLL_P_OUT5>;
> + clock-names = "gpu", "pwr";
> + resets = <&tegra_car 184>;
> + reset-names = "gpu";
> + iommus = <&mc TEGRA_SWGROUP_GPU>;
> + };
> +
> + - |
> + #include <dt-bindings/clock/tegra210-car.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + /*
> + * XXX can't include this because it conflicts with the tegra124-mc.h
> + * include from the Tegra124 example above.
> + */
> + /*
> + #include <dt-bindings/memory/tegra210-mc.h>
> + */
> +
> + gpu@57000000 {
> + compatible = "nvidia,gm20b";
> + reg = <0x0 0x57000000 0x0 0x01000000>,
> + <0x0 0x58000000 0x0 0x01000000>;
> + interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "stall", "nonstall";
> + vdd-supply = <&vdd_gpu>;
> + clocks = <&tegra_car TEGRA210_CLK_GPU>,
> + <&tegra_car TEGRA210_CLK_PLL_P_OUT5>,
> + <&tegra_car TEGRA210_CLK_PLL_G_REF>;
> + clock-names = "gpu", "pwr", "ref";
> + resets = <&tegra_car 184>;
> + reset-names = "gpu";
> + iommus = <&mc TEGRA_SWGROUP_GPU>;
> + };
> +
> + - |
> + #include <dt-bindings/clock/tegra186-clock.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/memory/tegra186-mc.h>
> + #include <dt-bindings/power/tegra186-powergate.h>
> + #include <dt-bindings/reset/tegra186-reset.h>
> +
> + gpu@17000000 {
> + compatible = "nvidia,gp10b";
> + reg = <0x0 0x17000000 0x0 0x1000000>,
> + <0x0 0x18000000 0x0 0x1000000>;
> + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "stall", "nonstall";
> + clocks = <&bpmp TEGRA186_CLK_GPCCLK>,
> + <&bpmp TEGRA186_CLK_GPU>;
> + clock-names = "gpu", "pwr";
> + resets = <&bpmp TEGRA186_RESET_GPU>;
> + reset-names = "gpu";
> + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>;
> + iommus = <&smmu TEGRA186_SID_GPU>;
> + };
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 10/38] dt-bindings: gpu: tegra: Document interconnect paths
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (8 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 09/38] dt-bindings: gpu: tegra: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 11/38] dt-bindings: mmc: tegra: Convert to json-schema Thierry Reding
` (27 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/gpu/nvidia,gk20a.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
index 726ef39b2221..40191e1a241e 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
+++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.yaml
@@ -71,6 +71,21 @@ properties:
../iommu/iommu.txt for details.
$ref: "/schemas/types.yaml#/definitions/phandle-array"
+ interconnects:
+ description: A list of phandle and specifier pairs that describe the
+ interconnect paths to and from the GPU.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ interconnect-names:
+ description: One string for each pair of phandle and specifier in the
+ "interconnects" property.
+ $ref: "/schemas/types.yaml#/definitions/string-array"
+ items:
+ - const: dma-mem # read-0
+ - const: write-0
+ - const: read-1
+ - const: write-1
+
required:
- compatible
- reg
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 11/38] dt-bindings: mmc: tegra: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (9 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 10/38] dt-bindings: gpu: tegra: Document interconnect paths Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 12/38] dt-bindings: mmc: tegra: Document interconnect paths Thierry Reding
` (26 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the NVIDIA Tegra SDHCI bindings from the free-form text format
to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/mmc/nvidia,tegra20-sdhci.txt | 117 --------
.../bindings/mmc/nvidia,tegra20-sdhci.yaml | 270 ++++++++++++++++++
2 files changed, 270 insertions(+), 117 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
create mode 100644 Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
deleted file mode 100644
index 2cf3affa1be7..000000000000
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
+++ /dev/null
@@ -1,117 +0,0 @@
-* NVIDIA Tegra Secure Digital Host Controller
-
-This controller on Tegra family SoCs provides an interface for MMC, SD,
-and SDIO types of memory cards.
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the sdhci-tegra driver.
-
-Required properties:
-- compatible : should be one of:
- - "nvidia,tegra20-sdhci": for Tegra20
- - "nvidia,tegra30-sdhci": for Tegra30
- - "nvidia,tegra114-sdhci": for Tegra114
- - "nvidia,tegra124-sdhci": for Tegra124 and Tegra132
- - "nvidia,tegra210-sdhci": for Tegra210
- - "nvidia,tegra186-sdhci": for Tegra186
- - "nvidia,tegra194-sdhci": for Tegra194
-- clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - sdhci
-
-Optional properties:
-- power-gpios : Specify GPIOs for power control
-
-Example:
-
-sdhci@c8000200 {
- compatible = "nvidia,tegra20-sdhci";
- reg = <0xc8000200 0x200>;
- interrupts = <47>;
- clocks = <&tegra_car 14>;
- resets = <&tegra_car 14>;
- reset-names = "sdhci";
- cd-gpios = <&gpio 69 0>; /* gpio PI5 */
- wp-gpios = <&gpio 57 0>; /* gpio PH1 */
- power-gpios = <&gpio 155 0>; /* gpio PT3 */
- bus-width = <8>;
-};
-
-Optional properties for Tegra210, Tegra186 and Tegra194:
-- pinctrl-names, pinctrl-0, pinctrl-1 : Specify pad voltage
- configurations. Valid pinctrl-names are "sdmmc-3v3" and "sdmmc-1v8"
- for controllers supporting multiple voltage levels. The order of names
- should correspond to the pin configuration states in pinctrl-0 and
- pinctrl-1.
-- pinctrl-names : "sdmmc-3v3-drv" and "sdmmc-1v8-drv" are applicable for
- Tegra210 where pad config registers are in the pinmux register domain
- for pull-up-strength and pull-down-strength values configuration when
- using pads at 3V3 and 1V8 levels.
-- nvidia,only-1-8-v : The presence of this property indicates that the
- controller operates at a 1.8 V fixed I/O voltage.
-- nvidia,pad-autocal-pull-up-offset-3v3,
- nvidia,pad-autocal-pull-down-offset-3v3 : Specify drive strength
- calibration offsets for 3.3 V signaling modes.
-- nvidia,pad-autocal-pull-up-offset-1v8,
- nvidia,pad-autocal-pull-down-offset-1v8 : Specify drive strength
- calibration offsets for 1.8 V signaling modes.
-- nvidia,pad-autocal-pull-up-offset-3v3-timeout,
- nvidia,pad-autocal-pull-down-offset-3v3-timeout : Specify drive
- strength used as a fallback in case the automatic calibration times
- out on a 3.3 V signaling mode.
-- nvidia,pad-autocal-pull-up-offset-1v8-timeout,
- nvidia,pad-autocal-pull-down-offset-1v8-timeout : Specify drive
- strength used as a fallback in case the automatic calibration times
- out on a 1.8 V signaling mode.
-- nvidia,pad-autocal-pull-up-offset-sdr104,
- nvidia,pad-autocal-pull-down-offset-sdr104 : Specify drive strength
- calibration offsets for SDR104 mode.
-- nvidia,pad-autocal-pull-up-offset-hs400,
- nvidia,pad-autocal-pull-down-offset-hs400 : Specify drive strength
- calibration offsets for HS400 mode.
-- nvidia,default-tap : Specify the default inbound sampling clock
- trimmer value for non-tunable modes.
-- nvidia,default-trim : Specify the default outbound clock trimmer
- value.
-- nvidia,dqs-trim : Specify DQS trim value for HS400 timing
-
- Notes on the pad calibration pull up and pulldown offset values:
- - The property values are drive codes which are programmed into the
- PD_OFFSET and PU_OFFSET sections of the
- SDHCI_TEGRA_AUTO_CAL_CONFIG register.
- - A higher value corresponds to higher drive strength. Please refer
- to the reference manual of the SoC for correct values.
- - The SDR104 and HS400 timing specific values are used in
- corresponding modes if specified.
-
- Notes on tap and trim values:
- - The values are used for compensating trace length differences
- by adjusting the sampling point.
- - The values are programmed to the Vendor Clock Control Register.
- Please refer to the reference manual of the SoC for correct
- values.
- - The DQS trim values are only used on controllers which support
- HS400 timing. Only SDMMC4 on Tegra210 and Tegra 186 supports
- HS400.
-
-Example:
-sdhci@700b0000 {
- compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci";
- reg = <0x0 0x700b0000 0x0 0x200>;
- interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&tegra_car TEGRA210_CLK_SDMMC1>;
- clock-names = "sdhci";
- resets = <&tegra_car 14>;
- reset-names = "sdhci";
- pinctrl-names = "sdmmc-3v3", "sdmmc-1v8";
- pinctrl-0 = <&sdmmc1_3v3>;
- pinctrl-1 = <&sdmmc1_1v8>;
- nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>;
- nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>;
- nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>;
- nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>;
- status = "disabled";
-};
diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
new file mode 100644
index 000000000000..7652c2c1ff35
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
@@ -0,0 +1,270 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/nvidia,tegra20-sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Secure Digital Host Controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ This controller on Tegra family SoCs provides an interface for MMC, SD, and
+ SDIO types of memory cards.
+
+ This file documents differences between the core properties described by
+ mmc-controller.yaml and the properties for the Tegra SDHCI controller.
+
+properties:
+ # required properties
+ compatible:
+ oneOf:
+ - description: NVIDIA Tegra20
+ const: nvidia,tegra20-sdhci
+
+ - description: NVIDIA Tegra30
+ const: nvidia,tegra30-sdhci
+
+ - description: NVIDIA Tegra114
+ const: nvidia,tegra114-sdhci
+
+ - description: NVIDIA Tegra124
+ const: nvidia,tegra124-sdhci
+
+ - description: NVIDIA Tegra132
+ items:
+ - const: nvidia,tegra132-sdhci
+ - const: nvidia,tegra124-sdhci
+
+ - description: NVIDIA Tegra210
+ const: nvidia,tegra210-sdhci
+
+ - description: NVIDIA Tegra186
+ const: nvidia,tegra186-sdhci
+
+ - description: NVIDIA Tegra194
+ const: nvidia,tegra194-sdhci
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ assigned-clocks:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ assigned-clock-parents:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ assigned-clock-rates:
+ $ref: "/schemas/types.yaml#/definitions/uint32-array"
+
+ clocks:
+ items:
+ - description: module clock
+
+ clock-names:
+ items:
+ - const: sdhci
+
+ resets:
+ items:
+ - description: module reset
+
+ reset-names:
+ items:
+ - const: sdhci
+
+ # optional properties
+ power-gpios:
+ description: specify GPIOs for power control
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ iommus:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ nvidia,default-tap:
+ description: Specify the default inbound sampling clock trimmer value for
+ non-tunable modes.
+
+ The values are used for compensating trace length differences by
+ adjusting the sampling point. The values are programmed to the Vendor
+ Clock Control Register. Please refer to the reference manual of the SoC
+ for correct values.
+
+ The DQS trim values are only used on controllers which support HS400
+ timing. Only SDMMC4 on Tegra210 and Tegra186 supports HS400.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,default-trim:
+ description: Specify the default outbound clock trimmer value.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,dqs-trim:
+ description: Specify DQS trim value for HS400 timing.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-down-offset-1v8:
+ description: Specify drive strength calibration offsets for 1.8 V
+ signaling modes.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-down-offset-1v8-timeout:
+ description: Specify drive strength used as a fallback in case the
+ automatic calibration times out on a 1.8 V signaling mode.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-down-offset-3v3:
+ description: Specify drive strength calibration offsets for 3.3 V
+ signaling modes.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-down-offset-3v3-timeout:
+ description: Specify drive strength used as a fallback in case the
+ automatic calibration times out on a 3.3 V signaling mode.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-down-offset-sdr104:
+ description: Specify drive strength calibration offsets for SDR104 mode.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-down-offset-hs400:
+ description: Specify drive strength calibration offsets for HS400 mode.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ nvidia,pad-autocal-pull-up-offset-1v8:
+ description: Specify drive strength calibration offsets for 1.8 V
+ signaling modes.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-up-offset-1v8-timeout:
+ description: Specify drive strength used as a fallback in case the
+ automatic calibration times out on a 1.8 V signaling mode.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-up-offset-3v3:
+ description: Specify drive strength calibration offsets for 3.3 V
+ signaling modes.
+
+ The property values are drive codes which are programmed into the
+ PD_OFFSET and PU_OFFSET sections of the SDHCI_TEGRA_AUTO_CAL_CONFIG
+ register. A higher value corresponds to higher drive strength. Please
+ refer to the reference manual of the SoC for correct values. The SDR104
+ and HS400 timing specific values are used in corresponding modes if
+ specified.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-up-offset-3v3-timeout:
+ description: Specify drive strength used as a fallback in case the
+ automatic calibration times out on a 3.3 V signaling mode.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-up-offset-sdr104:
+ description: Specify drive strength calibration offsets for SDR104 mode.
+ $ref: "/schemas/types.yaml#definitions/uint32"
+
+ nvidia,pad-autocal-pull-up-offset-hs400:
+ description: Specify drive strength calibration offsets for HS400 mode.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ nvidia,only-1-8v:
+ description: The presence of this property indicates that the controller
+ operates at a 1.8 V fixed I/O voltage.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra210-sdhci
+ then:
+ properties:
+ pinctrl-names:
+ oneOf:
+ - items:
+ - const: sdmmc-3v3
+ description: pad configuration for 3.3 V
+ - const: sdmmc-1v8
+ description: pad configuration for 1.8 V
+ - const: sdmmc-3v3-drv
+ description: pull-up/down configuration for 3.3 V
+ - const: sdmmc-1v8-drv
+ description: pull-up/down configuration for 1.8 V
+ - items:
+ - const: sdmmc-3v3-drv
+ description: pull-up/down configuration for 3.3 V
+ - const: sdmmc-1v8-drv
+ description: pull-up/down configuration for 1.8 V
+ - items:
+ - const: sdmmc-1v8-drv
+ description: pull-up/down configuration for 1.8 V
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-sdhci
+ - nvidia,tegra194-sdhci
+ then:
+ properties:
+ pinctrl-names:
+ items:
+ - const: sdmmc-3v3
+ description: pad configuration for 3.3 V
+ - const: sdmmc-1v8
+ description: pad configuration for 1.8 V
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ sdhci@c8000200 {
+ compatible = "nvidia,tegra20-sdhci";
+ reg = <0xc8000200 0x200>;
+ interrupts = <47>;
+ clocks = <&tegra_car 14>;
+ resets = <&tegra_car 14>;
+ reset-names = "sdhci";
+ cd-gpios = <&gpio 69 0>; /* gpio PI5 */
+ wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+ power-gpios = <&gpio 155 0>; /* gpio PT3 */
+ bus-width = <8>;
+ };
+
+ - |
+ #include <dt-bindings/clock/tegra210-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ sdhci@700b0000 {
+ compatible = "nvidia,tegra210-sdhci";
+ reg = <0x0 0x700b0000 0x0 0x200>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA210_CLK_SDMMC1>;
+ clock-names = "sdhci";
+ resets = <&tegra_car 14>;
+ reset-names = "sdhci";
+ pinctrl-names = "sdmmc-3v3", "sdmmc-1v8";
+ pinctrl-0 = <&sdmmc1_3v3>;
+ pinctrl-1 = <&sdmmc1_1v8>;
+ nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>;
+ nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>;
+ nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>;
+ nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>;
+ status = "disabled";
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 12/38] dt-bindings: mmc: tegra: Document interconnect paths
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (10 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 11/38] dt-bindings: mmc: tegra: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 13/38] dt-bindings: pci: tegra: Convert to json-schema Thierry Reding
` (25 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/mmc/nvidia,tegra20-sdhci.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
index 7652c2c1ff35..70931288bc70 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml
@@ -86,6 +86,19 @@ properties:
iommus:
$ref: "/schemas/types.yaml#/definitions/phandle-array"
+ interconnects:
+ description: A list of phandle and specifier pairs that describe the
+ interconnect paths to and from the SDHCI controller.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ interconnect-names:
+ description: One string for each pair of phandle and specifier in the
+ "interconnects" property.
+ $ref: "/schemas/types.yaml#/definitions/string-array"
+ items:
+ - const: dma-mem # read
+ - const: write
+
nvidia,default-tap:
description: Specify the default inbound sampling clock trimmer value for
non-tunable modes.
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 13/38] dt-bindings: pci: tegra: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (11 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 12/38] dt-bindings: mmc: tegra: Document interconnect paths Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 14/38] dt-bindings: pci: tegra: Document interconnect paths Thierry Reding
` (24 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Tegra PCIe controller bindings from the free-form text
format to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/pci/nvidia,tegra20-pcie.txt | 682 ---------------
.../bindings/pci/nvidia,tegra20-pcie.yaml | 824 ++++++++++++++++++
2 files changed, 824 insertions(+), 682 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
create mode 100644 Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.yaml
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
deleted file mode 100644
index 7939bca47861..000000000000
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
+++ /dev/null
@@ -1,682 +0,0 @@
-NVIDIA Tegra PCIe controller
-
-Required properties:
-- compatible: Must be:
- - "nvidia,tegra20-pcie": for Tegra20
- - "nvidia,tegra30-pcie": for Tegra30
- - "nvidia,tegra124-pcie": for Tegra124 and Tegra132
- - "nvidia,tegra210-pcie": for Tegra210
- - "nvidia,tegra186-pcie": for Tegra186
-- power-domains: To ungate power partition by BPMP powergate driver. Must
- contain BPMP phandle and PCIe power partition ID. This is required only
- for Tegra186.
-- device_type: Must be "pci"
-- reg: A list of physical base address and length for each set of controller
- registers. Must contain an entry for each entry in the reg-names property.
-- reg-names: Must include the following entries:
- "pads": PADS registers
- "afi": AFI registers
- "cs": configuration space region
-- interrupts: A list of interrupt outputs of the controller. Must contain an
- entry for each entry in the interrupt-names property.
-- interrupt-names: Must include the following entries:
- "intr": The Tegra interrupt that is asserted for controller interrupts
- "msi": The Tegra interrupt that is asserted when an MSI is received
-- bus-range: Range of bus numbers associated with this controller
-- #address-cells: Address representation for root ports (must be 3)
- - cell 0 specifies the bus and device numbers of the root port:
- [23:16]: bus number
- [15:11]: device number
- - cell 1 denotes the upper 32 address bits and should be 0
- - cell 2 contains the lower 32 address bits and is used to translate to the
- CPU address space
-- #size-cells: Size representation for root ports (must be 2)
-- ranges: Describes the translation of addresses for root ports and standard
- PCI regions. The entries must be 6 cells each, where the first three cells
- correspond to the address as described for the #address-cells property
- above, the fourth cell is the physical CPU address to translate to and the
- fifth and six cells are as described for the #size-cells property above.
- - The first two entries are expected to translate the addresses for the root
- port registers, which are referenced by the assigned-addresses property of
- the root port nodes (see below).
- - The remaining entries setup the mapping for the standard I/O, memory and
- prefetchable PCI regions. The first cell determines the type of region
- that is setup:
- - 0x81000000: I/O memory region
- - 0x82000000: non-prefetchable memory region
- - 0xc2000000: prefetchable memory region
- Please refer to the standard PCI bus binding document for a more detailed
- explanation.
-- #interrupt-cells: Size representation for interrupts (must be 1)
-- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
- Please refer to the standard PCI bus binding document for a more detailed
- explanation.
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - pex
- - afi
- - pll_e
- - cml (not required for Tegra20)
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - pex
- - afi
- - pcie_x
-
-Optional properties:
-- pinctrl-names: A list of pinctrl state names. Must contain the following
- entries:
- - "default": active state, puts PCIe I/O out of deep power down state
- - "idle": puts PCIe I/O into deep power down state
-- pinctrl-0: phandle for the default/active state of pin configurations.
-- pinctrl-1: phandle for the idle state of pin configurations.
-
-Required properties on Tegra124 and later (deprecated):
-- phys: Must contain an entry for each entry in phy-names.
-- phy-names: Must include the following entries:
- - pcie
-
-These properties are deprecated in favour of per-lane PHYs define in each of
-the root ports (see below).
-
-Power supplies for Tegra20:
-- avdd-pex-supply: Power supply for analog PCIe logic. Must supply 1.05 V.
-- vdd-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
-- avdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must
- supply 1.05 V.
-- avdd-plle-supply: Power supply for PLLE, which is shared with SATA. Must
- supply 1.05 V.
-- vddio-pex-clk-supply: Power supply for PCIe clock. Must supply 3.3 V.
-
-Power supplies for Tegra30:
-- Required:
- - avdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must
- supply 1.05 V.
- - avdd-plle-supply: Power supply for PLLE, which is shared with SATA. Must
- supply 1.05 V.
- - vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must
- supply 1.8 V.
- - hvdd-pex-supply: High-voltage supply for PCIe I/O and PCIe output clocks.
- Must supply 3.3 V.
-- Optional:
- - If lanes 0 to 3 are used:
- - avdd-pexa-supply: Power supply for analog PCIe logic. Must supply 1.05 V.
- - vdd-pexa-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
- - If lanes 4 or 5 are used:
- - avdd-pexb-supply: Power supply for analog PCIe logic. Must supply 1.05 V.
- - vdd-pexb-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
-
-Power supplies for Tegra124:
-- Required:
- - avddio-pex-supply: Power supply for analog PCIe logic. Must supply 1.05 V.
- - dvddio-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
- - avdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must
- supply 1.05 V.
- - hvdd-pex-supply: High-voltage supply for PCIe I/O and PCIe output clocks.
- Must supply 3.3 V.
- - hvdd-pex-pll-e-supply: High-voltage supply for PLLE (shared with USB3).
- Must supply 3.3 V.
- - vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must
- supply 2.8-3.3 V.
- - avdd-pll-erefe-supply: Power supply for PLLE (shared with USB3). Must
- supply 1.05 V.
-
-Power supplies for Tegra210:
-- Required:
- - avdd-pll-uerefe-supply: Power supply for PLLE (shared with USB3). Must
- supply 1.05 V.
- - hvddio-pex-supply: High-voltage supply for PCIe I/O and PCIe output
- clocks. Must supply 1.8 V.
- - dvddio-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
- - dvdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must
- supply 1.05 V.
- - hvdd-pex-pll-e-supply: High-voltage supply for PLLE (shared with USB3).
- Must supply 3.3 V.
- - vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must
- supply 1.8 V.
-
-Power supplies for Tegra186:
-- Required:
- - dvdd-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V.
- - hvdd-pex-pll-supply: High-voltage supply for PLLE (shared with USB3). Must
- supply 1.8 V.
- - hvdd-pex-supply: High-voltage supply for PCIe I/O and PCIe output clocks.
- Must supply 1.8 V.
- - vddio-pexctl-aud-supply: Power supply for PCIe side band signals. Must
- supply 1.8 V.
-
-Root ports are defined as subnodes of the PCIe controller node.
-
-Required properties:
-- device_type: Must be "pci"
-- assigned-addresses: Address and size of the port configuration registers
-- reg: PCI bus address of the root port
-- #address-cells: Must be 3
-- #size-cells: Must be 2
-- ranges: Sub-ranges distributed from the PCIe controller node. An empty
- property is sufficient.
-- nvidia,num-lanes: Number of lanes to use for this port. Valid combinations
- are:
- - Root port 0 uses 4 lanes, root port 1 is unused.
- - Both root ports use 2 lanes.
-
-Required properties for Tegra124 and later:
-- phys: Must contain an phandle to a PHY for each entry in phy-names.
-- phy-names: Must include an entry for each active lane. Note that the number
- of entries does not have to (though usually will) be equal to the specified
- number of lanes in the nvidia,num-lanes property. Entries are of the form
- "pcie-N": where N ranges from 0 to the value specified in nvidia,num-lanes.
-
-Examples:
-=========
-
-Tegra20:
---------
-
-SoC DTSI:
-
- pcie-controller@80003000 {
- compatible = "nvidia,tegra20-pcie";
- device_type = "pci";
- reg = <0x80003000 0x00000800 /* PADS registers */
- 0x80003800 0x00000200 /* AFI registers */
- 0x90000000 0x10000000>; /* configuration space */
- reg-names = "pads", "afi", "cs";
- interrupts = <0 98 0x04 /* controller interrupt */
- 0 99 0x04>; /* MSI interrupt */
- interrupt-names = "intr", "msi";
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
-
- bus-range = <0x00 0xff>;
- #address-cells = <3>;
- #size-cells = <2>;
-
- ranges = <0x82000000 0 0x80000000 0x80000000 0 0x00001000 /* port 0 registers */
- 0x82000000 0 0x80001000 0x80001000 0 0x00001000 /* port 1 registers */
- 0x81000000 0 0 0x82000000 0 0x00010000 /* downstream I/O */
- 0x82000000 0 0xa0000000 0xa0000000 0 0x10000000 /* non-prefetchable memory */
- 0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */
-
- clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 118>;
- clock-names = "pex", "afi", "pll_e";
- resets = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>;
- reset-names = "pex", "afi", "pcie_x";
- status = "disabled";
-
- pci@1,0 {
- device_type = "pci";
- assigned-addresses = <0x82000800 0 0x80000000 0 0x1000>;
- reg = <0x000800 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
-
- ranges;
-
- nvidia,num-lanes = <2>;
- };
-
- pci@2,0 {
- device_type = "pci";
- assigned-addresses = <0x82001000 0 0x80001000 0 0x1000>;
- reg = <0x001000 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
-
- ranges;
-
- nvidia,num-lanes = <2>;
- };
- };
-
-Board DTS:
-
- pcie-controller@80003000 {
- status = "okay";
-
- vdd-supply = <&pci_vdd_reg>;
- pex-clk-supply = <&pci_clk_reg>;
-
- /* root port 00:01.0 */
- pci@1,0 {
- status = "okay";
-
- /* bridge 01:00.0 (optional) */
- pci@0,0 {
- reg = <0x010000 0 0 0 0>;
-
- #address-cells = <3>;
- #size-cells = <2>;
-
- device_type = "pci";
-
- /* endpoint 02:00.0 */
- pci@0,0 {
- reg = <0x020000 0 0 0 0>;
- };
- };
- };
- };
-
-Note that devices on the PCI bus are dynamically discovered using PCI's bus
-enumeration and therefore don't need corresponding device nodes in DT. However
-if a device on the PCI bus provides a non-probeable bus such as I2C or SPI,
-device nodes need to be added in order to allow the bus' children to be
-instantiated at the proper location in the operating system's device tree (as
-illustrated by the optional nodes in the example above).
-
-Tegra30:
---------
-
-SoC DTSI:
-
- pcie-controller@3000 {
- compatible = "nvidia,tegra30-pcie";
- device_type = "pci";
- reg = <0x00003000 0x00000800 /* PADS registers */
- 0x00003800 0x00000200 /* AFI registers */
- 0x10000000 0x10000000>; /* configuration space */
- reg-names = "pads", "afi", "cs";
- interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH /* controller interrupt */
- GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
- interrupt-names = "intr", "msi";
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
-
- bus-range = <0x00 0xff>;
- #address-cells = <3>;
- #size-cells = <2>;
-
- ranges = <0x82000000 0 0x00000000 0x00000000 0 0x00001000 /* port 0 configuration space */
- 0x82000000 0 0x00001000 0x00001000 0 0x00001000 /* port 1 configuration space */
- 0x82000000 0 0x00004000 0x00004000 0 0x00001000 /* port 2 configuration space */
- 0x81000000 0 0 0x02000000 0 0x00010000 /* downstream I/O */
- 0x82000000 0 0x20000000 0x20000000 0 0x08000000 /* non-prefetchable memory */
- 0xc2000000 0 0x28000000 0x28000000 0 0x18000000>; /* prefetchable memory */
-
- clocks = <&tegra_car TEGRA30_CLK_PCIE>,
- <&tegra_car TEGRA30_CLK_AFI>,
- <&tegra_car TEGRA30_CLK_PLL_E>,
- <&tegra_car TEGRA30_CLK_CML0>;
- clock-names = "pex", "afi", "pll_e", "cml";
- resets = <&tegra_car 70>,
- <&tegra_car 72>,
- <&tegra_car 74>;
- reset-names = "pex", "afi", "pcie_x";
- status = "disabled";
-
- pci@1,0 {
- device_type = "pci";
- assigned-addresses = <0x82000800 0 0x00000000 0 0x1000>;
- reg = <0x000800 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <2>;
- };
-
- pci@2,0 {
- device_type = "pci";
- assigned-addresses = <0x82001000 0 0x00001000 0 0x1000>;
- reg = <0x001000 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <2>;
- };
-
- pci@3,0 {
- device_type = "pci";
- assigned-addresses = <0x82001800 0 0x00004000 0 0x1000>;
- reg = <0x001800 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <2>;
- };
- };
-
-Board DTS:
-
- pcie-controller@3000 {
- status = "okay";
-
- avdd-pexa-supply = <&ldo1_reg>;
- vdd-pexa-supply = <&ldo1_reg>;
- avdd-pexb-supply = <&ldo1_reg>;
- vdd-pexb-supply = <&ldo1_reg>;
- avdd-pex-pll-supply = <&ldo1_reg>;
- avdd-plle-supply = <&ldo1_reg>;
- vddio-pex-ctl-supply = <&sys_3v3_reg>;
- hvdd-pex-supply = <&sys_3v3_pexs_reg>;
-
- pci@1,0 {
- status = "okay";
- };
-
- pci@3,0 {
- status = "okay";
- };
- };
-
-Tegra124:
----------
-
-SoC DTSI:
-
- pcie-controller@1003000 {
- compatible = "nvidia,tegra124-pcie";
- device_type = "pci";
- reg = <0x0 0x01003000 0x0 0x00000800 /* PADS registers */
- 0x0 0x01003800 0x0 0x00000800 /* AFI registers */
- 0x0 0x02000000 0x0 0x10000000>; /* configuration space */
- reg-names = "pads", "afi", "cs";
- interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
- <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
- interrupt-names = "intr", "msi";
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
-
- bus-range = <0x00 0xff>;
- #address-cells = <3>;
- #size-cells = <2>;
-
- ranges = <0x82000000 0 0x01000000 0x0 0x01000000 0 0x00001000 /* port 0 configuration space */
- 0x82000000 0 0x01001000 0x0 0x01001000 0 0x00001000 /* port 1 configuration space */
- 0x81000000 0 0x0 0x0 0x12000000 0 0x00010000 /* downstream I/O (64 KiB) */
- 0x82000000 0 0x13000000 0x0 0x13000000 0 0x0d000000 /* non-prefetchable memory (208 MiB) */
- 0xc2000000 0 0x20000000 0x0 0x20000000 0 0x20000000>; /* prefetchable memory (512 MiB) */
-
- clocks = <&tegra_car TEGRA124_CLK_PCIE>,
- <&tegra_car TEGRA124_CLK_AFI>,
- <&tegra_car TEGRA124_CLK_PLL_E>,
- <&tegra_car TEGRA124_CLK_CML0>;
- clock-names = "pex", "afi", "pll_e", "cml";
- resets = <&tegra_car 70>,
- <&tegra_car 72>,
- <&tegra_car 74>;
- reset-names = "pex", "afi", "pcie_x";
- status = "disabled";
-
- pci@1,0 {
- device_type = "pci";
- assigned-addresses = <0x82000800 0 0x01000000 0 0x1000>;
- reg = <0x000800 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <2>;
- };
-
- pci@2,0 {
- device_type = "pci";
- assigned-addresses = <0x82001000 0 0x01001000 0 0x1000>;
- reg = <0x001000 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <1>;
- };
- };
-
-Board DTS:
-
- pcie-controller@1003000 {
- status = "okay";
-
- avddio-pex-supply = <&vdd_1v05_run>;
- dvddio-pex-supply = <&vdd_1v05_run>;
- avdd-pex-pll-supply = <&vdd_1v05_run>;
- hvdd-pex-supply = <&vdd_3v3_lp0>;
- hvdd-pex-pll-e-supply = <&vdd_3v3_lp0>;
- vddio-pex-ctl-supply = <&vdd_3v3_lp0>;
- avdd-pll-erefe-supply = <&avdd_1v05_run>;
-
- /* Mini PCIe */
- pci@1,0 {
- phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-4}>;
- phy-names = "pcie-0";
- status = "okay";
- };
-
- /* Gigabit Ethernet */
- pci@2,0 {
- phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-2}>;
- phy-names = "pcie-0";
- status = "okay";
- };
- };
-
-Tegra210:
----------
-
-SoC DTSI:
-
- pcie-controller@1003000 {
- compatible = "nvidia,tegra210-pcie";
- device_type = "pci";
- reg = <0x0 0x01003000 0x0 0x00000800 /* PADS registers */
- 0x0 0x01003800 0x0 0x00000800 /* AFI registers */
- 0x0 0x02000000 0x0 0x10000000>; /* configuration space */
- reg-names = "pads", "afi", "cs";
- interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
- <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
- interrupt-names = "intr", "msi";
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
-
- bus-range = <0x00 0xff>;
- #address-cells = <3>;
- #size-cells = <2>;
-
- ranges = <0x82000000 0 0x01000000 0x0 0x01000000 0 0x00001000 /* port 0 configuration space */
- 0x82000000 0 0x01001000 0x0 0x01001000 0 0x00001000 /* port 1 configuration space */
- 0x81000000 0 0x0 0x0 0x12000000 0 0x00010000 /* downstream I/O (64 KiB) */
- 0x82000000 0 0x13000000 0x0 0x13000000 0 0x0d000000 /* non-prefetchable memory (208 MiB) */
- 0xc2000000 0 0x20000000 0x0 0x20000000 0 0x20000000>; /* prefetchable memory (512 MiB) */
-
- clocks = <&tegra_car TEGRA210_CLK_PCIE>,
- <&tegra_car TEGRA210_CLK_AFI>,
- <&tegra_car TEGRA210_CLK_PLL_E>,
- <&tegra_car TEGRA210_CLK_CML0>;
- clock-names = "pex", "afi", "pll_e", "cml";
- resets = <&tegra_car 70>,
- <&tegra_car 72>,
- <&tegra_car 74>;
- reset-names = "pex", "afi", "pcie_x";
- status = "disabled";
-
- pci@1,0 {
- device_type = "pci";
- assigned-addresses = <0x82000800 0 0x01000000 0 0x1000>;
- reg = <0x000800 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <4>;
- };
-
- pci@2,0 {
- device_type = "pci";
- assigned-addresses = <0x82001000 0 0x01001000 0 0x1000>;
- reg = <0x001000 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <1>;
- };
- };
-
-Board DTS:
-
- pcie-controller@1003000 {
- status = "okay";
-
- avdd-pll-uerefe-supply = <&avdd_1v05_pll>;
- hvddio-pex-supply = <&vdd_1v8>;
- dvddio-pex-supply = <&vdd_pex_1v05>;
- dvdd-pex-pll-supply = <&vdd_pex_1v05>;
- hvdd-pex-pll-e-supply = <&vdd_1v8>;
- vddio-pex-ctl-supply = <&vdd_1v8>;
-
- pci@1,0 {
- phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-0}>,
- <&{/padctl@7009f000/pads/pcie/lanes/pcie-1}>,
- <&{/padctl@7009f000/pads/pcie/lanes/pcie-2}>,
- <&{/padctl@7009f000/pads/pcie/lanes/pcie-3}>;
- phy-names = "pcie-0", "pcie-1", "pcie-2", "pcie-3";
- status = "okay";
- };
-
- pci@2,0 {
- phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-4}>;
- phy-names = "pcie-0";
- status = "okay";
- };
- };
-
-Tegra186:
----------
-
-SoC DTSI:
-
- pcie@10003000 {
- compatible = "nvidia,tegra186-pcie";
- power-domains = <&bpmp TEGRA186_POWER_DOMAIN_PCX>;
- device_type = "pci";
- reg = <0x0 0x10003000 0x0 0x00000800 /* PADS registers */
- 0x0 0x10003800 0x0 0x00000800 /* AFI registers */
- 0x0 0x40000000 0x0 0x10000000>; /* configuration space */
- reg-names = "pads", "afi", "cs";
-
- interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
- <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
- interrupt-names = "intr", "msi";
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 &gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
-
- bus-range = <0x00 0xff>;
- #address-cells = <3>;
- #size-cells = <2>;
-
- ranges = <0x82000000 0 0x10000000 0x0 0x10000000 0 0x00001000 /* port 0 configuration space */
- 0x82000000 0 0x10001000 0x0 0x10001000 0 0x00001000 /* port 1 configuration space */
- 0x82000000 0 0x10004000 0x0 0x10004000 0 0x00001000 /* port 2 configuration space */
- 0x81000000 0 0x0 0x0 0x50000000 0 0x00010000 /* downstream I/O (64 KiB) */
- 0x82000000 0 0x50100000 0x0 0x50100000 0 0x07F00000 /* non-prefetchable memory (127 MiB) */
- 0xc2000000 0 0x58000000 0x0 0x58000000 0 0x28000000>; /* prefetchable memory (640 MiB) */
-
- clocks = <&bpmp TEGRA186_CLK_AFI>,
- <&bpmp TEGRA186_CLK_PCIE>,
- <&bpmp TEGRA186_CLK_PLLE>;
- clock-names = "afi", "pex", "pll_e";
-
- resets = <&bpmp TEGRA186_RESET_AFI>,
- <&bpmp TEGRA186_RESET_PCIE>,
- <&bpmp TEGRA186_RESET_PCIEXCLK>;
- reset-names = "afi", "pex", "pcie_x";
-
- status = "disabled";
-
- pci@1,0 {
- device_type = "pci";
- assigned-addresses = <0x82000800 0 0x10000000 0 0x1000>;
- reg = <0x000800 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <2>;
- };
-
- pci@2,0 {
- device_type = "pci";
- assigned-addresses = <0x82001000 0 0x10001000 0 0x1000>;
- reg = <0x001000 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <1>;
- };
-
- pci@3,0 {
- device_type = "pci";
- assigned-addresses = <0x82001800 0 0x10004000 0 0x1000>;
- reg = <0x001800 0 0 0 0>;
- status = "disabled";
-
- #address-cells = <3>;
- #size-cells = <2>;
- ranges;
-
- nvidia,num-lanes = <1>;
- };
- };
-
-Board DTS:
-
- pcie@10003000 {
- status = "okay";
-
- dvdd-pex-supply = <&vdd_pex>;
- hvdd-pex-pll-supply = <&vdd_1v8>;
- hvdd-pex-supply = <&vdd_1v8>;
- vddio-pexctl-aud-supply = <&vdd_1v8>;
-
- pci@1,0 {
- nvidia,num-lanes = <4>;
- status = "okay";
- };
-
- pci@2,0 {
- nvidia,num-lanes = <0>;
- status = "disabled";
- };
-
- pci@3,0 {
- nvidia,num-lanes = <1>;
- status = "disabled";
- };
- };
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.yaml
new file mode 100644
index 000000000000..e7cc95bfa810
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.yaml
@@ -0,0 +1,824 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/nvidia,tegra20-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra PCIe controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - description: NVIDIA Tegra20
+ const: nvidia,tegra20-pcie
+
+ - description: NVIDIA Tegra30
+ const: nvidia,tegra30-pcie
+
+ - description: NVIDIA Tegra124
+ const: nvidia,tegra124-pcie
+
+ - description: NVIDIA Tegra132
+ items:
+ - const: nvidia,tegra132-pcie
+ - const: nvidia,tegra124-pcie
+
+ - description: NVIDIA Tegra210
+ const: nvidia,tegra210-pcie
+
+ - description: NVIDIA Tegra186
+ const: nvidia,tegra186-pcie
+
+ reg:
+ items:
+ - description: PADS registers
+ - description: AFI registers
+ - description: configuration space region
+
+ reg-names:
+ items:
+ - const: pads
+ - const: afi
+ - const: cs
+
+ interrupts:
+ items:
+ - description: PCIe controller interrupt
+ - description: MSI controller interrupt
+
+ interrupt-names:
+ items:
+ - const: intr
+ - const: msi
+
+ "#address-cells":
+ description: |
+ Address representation for root ports. Cell 0 specifies the bus and
+ device numbers of the root port:
+
+ [23:16]: bus number
+ [15:11]: device number
+
+ Cell 1 denotes the upper 32 address bits and should be 0, while cell 2
+ contains the lower 32 address bits and is used to translate to the CPU
+ address space.
+ const: 3
+
+ "#size-cells":
+ const: 2
+
+ clocks:
+ items:
+ - description: AFI interface clock
+ - description: PCI controller clock
+ - description: reference PLL clock
+ - description: CML clock
+ minItems: 3
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: pex
+ - const: afi
+ - const: pll_e
+ - const: cml
+ minItems: 3
+ maxItems: 4
+
+ resets:
+ items:
+ - description: AFI interface reset
+ - description: PCI controller reset
+ - description: PCI bus reset
+
+ reset-names:
+ items:
+ - const: pex
+ - const: afi
+ - const: pcie_x
+
+ iommus:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ pinctrl-names:
+ items:
+ # active state, puts PCIe I/O out of deep power down state
+ - const: default
+ # puts PCIe I/O into deep power down state
+ - const: idle
+
+patternProperties:
+ "^pci@1?[0-9a-f](,[0-7])?$":
+ description: Root ports are defined as subnodes of the PCIe controller
+ node.
+
+ Note that devices on the PCI bus are dynamically discovered using PCI's
+ bus enumeration and therefore don't need corresponding device nodes in
+ DT. However if a device on the PCI bus provides a non-probeable bus such
+ as I2C or SPI, device nodes need to be added in order to allow the bus'
+ children to be instantiated at the proper location in the operating
+ system's device tree (as illustrated by the optional nodes in the
+ examples below).
+
+ type: object
+ properties:
+ device_type:
+ const: pci
+
+ assigned-addresses:
+ description: Address and size of the port configuration registers
+
+ "#address-cells":
+ const: 3
+
+ "#size-cells":
+ const: 2
+
+ ranges:
+ description: Sub-ranges distributed from the PCIe controller node. An
+ empty property is sufficient.
+
+ nvidia,num-lanes:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ description: |
+ Number of lanes to use for this port. Valid combinations
+ are:
+
+ - Root port 0 uses 4 lanes, root port 1 is unused.
+ - Both root ports use 2 lanes.
+
+required:
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: "/schemas/pinctrl/pinctrl-consumer.yaml"
+ - $ref: "/schemas/pci/pci-bus.yaml"
+ - $ref: "pci-iommu.yaml"
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra20-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ maxItems: 3
+
+ avdd-pex-supply:
+ description: Power supply for analog PCIe logic. Must supply 1.05 V.
+
+ vdd-pex-supply:
+ description: Power supply for digital PCIe I/O. Must supply 1.05 V.
+
+ avdd-pex-pll-supply:
+ description: Power supply for dedicated (internal) PCIe PLL. Must
+ supply 1.05 V.
+
+ avdd-plle-supply:
+ description: Power supply for PLLE, which is shared with SATA. Must
+ supply 1.05 V.
+
+ vddio-pex-clk-supply:
+ description: Power supply for PCIe clock. Must supply 3.3 V.
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra30-pcie
+ then:
+ properties:
+ avdd-pex-pll-supply:
+ description: Power supply for dedicated (internal) PCIe PLL. Must
+ supply 1.05 V.
+
+ avdd-plle-supply:
+ description: Power supply for PLLE, which is shared with SATA. Must
+ supply 1.05 V.
+
+ vddio-pex-ctl-supply:
+ description: Power supply for PCIe control I/O partition. Must
+ supply 1.8 V.
+
+ hvdd-pex-supply:
+ description: High-voltage supply for PCIe I/O and PCIe output
+ clocks. Must supply 3.3 V.
+
+ # optional
+ avdd-pexa-supply:
+ description: Power supply for analog PCIe logic. Must supply 1.05 V.
+ Required if lanes 0 through 3 are used.
+
+ vdd-pexa-supply:
+ description: Power supply for digital PCIe I/O. Must supply 1.05 V.
+ Required if lanes 0 through 3 are used.
+
+ avdd-pexb-supply:
+ description: Power supply for analog PCIe logic. Must supply 1.05 V.
+ Required if lanes 4 and 5 are used.
+
+ vdd-pexb-supply:
+ description: Power supply for digital PCIe I/O. Must supply 1.05 V.
+ Required if lanes 4 and 5 are used.
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra124-pcie
+ then:
+ properties:
+ phys:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ deprecated: true
+
+ phy-names:
+ items:
+ - const: pcie
+ deprecated: true
+
+ avddio-pex-supply:
+ description: Power supply for analog PCIe logic. Must supply 1.05 V.
+
+ dvddio-pex-supply:
+ description: Power supply for digital PCIe I/O. Must supply 1.05 V.
+
+ avdd-pex-pll-supply:
+ description: Power supply for dedicated (internal) PCIe PLL. Must
+ supply 1.05 V.
+
+ hvdd-pex-supply:
+ description: High-voltage supply for PCIe I/O and PCIe output
+ clocks. Must supply 3.3 V.
+
+ hvdd-pex-pll-e-supply:
+ description: High-voltage supply for PLLE (shared with USB3). Must
+ supply 3.3 V.
+
+ vddio-pex-ctl-supply:
+ description: Power supply for PCIe control I/O partition. Must
+ supply 2.8-3.3 V.
+
+ avdd-pll-erefe-supply:
+ description: Power supply for PLLE (shared with USB3). Must supply
+ 1.05 V.
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra210-pcie
+ then:
+ properties:
+ avdd-pll-uerefe-supply:
+ description: Power supply for PLLE (shared with USB3). Must supply
+ 1.05 V.
+
+ hvddio-pex-supply:
+ description: High-voltage supply for PCIe I/O and PCIe output
+ clocks. Must supply 1.8 V.
+
+ dvddio-pex-supply:
+ description: Power supply for digital PCIe I/O. Must supply 1.05 V.
+
+ dvdd-pex-pll-supply:
+ description: Power supply for dedicated (internal) PCIe PLL. Must
+ supply 1.05 V.
+
+ hvdd-pex-pll-e-supply:
+ description: High-voltage supply for PLLE (shared with USB3). Must
+ supply 3.3 V.
+
+ vddio-pex-ctl-supply:
+ description: Power supply for PCIe control I/O partition. Must
+ supply 1.8 V.
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra186-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ maxItems: 3
+
+ power-domains:
+ description: To ungate power partition by BPMP powergate driver.
+ Must contain BPMP phandle and PCIe power partition ID.
+
+ dvdd-pex-supply:
+ description: Power supply for digital PCIe I/O. Must supply 1.05 V.
+
+ hvdd-pex-pll-supply:
+ description: High-voltage supply for PLLE (shared with USB3). Must
+ supply 1.8 V.
+
+ hvdd-pex-supply:
+ description: High-voltage supply for PCIe I/O and PCIe output
+ clocks. Must supply 1.8 V.
+
+ vddio-pexctl-aud-supply:
+ description: Power supply for PCIe side band signals. Must supply
+ 1.8 V.
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra124-pcie
+ - nvidia,tegra210-pcie
+ - nvidia,tegra186-pcie
+ then:
+ patternProperties:
+ "^pci@1?[0-9a-f](,[0-7])?$":
+ properties:
+ phys:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ description: Must contain an phandle to a PHY for each entry in
+ phy-names.
+
+ phy-names:
+ $ref: "/schemas/types.yaml#/definitions/string-array"
+ description: Must include an entry for each active lane. Note
+ that the number of entries does not have to (though usually
+ will) be equal to the specified number of lanes in the
+ nvidia,num-lanes property. Entries are of the form "pcie-N",
+ where N ranges from 0 to the value specified in
+ nvidia,num-lanes.
+
+examples:
+ # Tegra20
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pcie@80003000 {
+ compatible = "nvidia,tegra20-pcie";
+ device_type = "pci";
+ reg = <0x80003000 0x00000800>, /* PADS registers */
+ <0x80003800 0x00000200>, /* AFI registers */
+ <0x90000000 0x10000000>; /* configuration space */
+ reg-names = "pads", "afi", "cs";
+ interrupts = <0 98 0x04>, /* controller interrupt */
+ <0 99 0x04>; /* MSI interrupt */
+ interrupt-names = "intr", "msi";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+
+ bus-range = <0x00 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x02000000 0 0x80000000 0x80000000 0 0x00001000>, /* port 0 registers */
+ <0x02000000 0 0x80001000 0x80001000 0 0x00001000>, /* port 1 registers */
+ <0x01000000 0 0 0x82000000 0 0x00010000>, /* downstream I/O */
+ <0x02000000 0 0xa0000000 0xa0000000 0 0x10000000>, /* non-prefetchable memory */
+ <0x42000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */
+
+ clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 118>;
+ clock-names = "pex", "afi", "pll_e";
+ resets = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>;
+ reset-names = "pex", "afi", "pcie_x";
+ status = "okay";
+
+ avdd-pex-supply = <&pci_vdd_reg>;
+ vdd-pex-supply = <&pci_vdd_reg>;
+ avdd-pex-pll-supply = <&pci_vdd_reg>;
+ avdd-plle-supply = <&pci_vdd_reg>;
+ vddio-pex-clk-supply = <&pci_clk_reg>;
+
+ /* root port 00:01.0 */
+ pci@1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x80000000 0 0x1000>;
+ reg = <0x000800 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "okay";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges;
+
+ nvidia,num-lanes = <2>;
+
+ /* bridge 01:00.0 (optional) */
+ pci@0,0 {
+ reg = <0x010000 0 0 0 0>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ device_type = "pci";
+
+ /* endpoint 02:00.0 */
+ pci@0,0 {
+ reg = <0x020000 0 0 0 0>;
+ };
+ };
+ };
+
+ pci@2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001000 0 0x80001000 0 0x1000>;
+ reg = <0x001000 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "disabled";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges;
+
+ nvidia,num-lanes = <2>;
+ };
+ };
+
+ # Tegra30
+ - |
+ #include <dt-bindings/clock/tegra30-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pcie@3000 {
+ compatible = "nvidia,tegra30-pcie";
+ device_type = "pci";
+ reg = <0x00003000 0x00000800>, /* PADS registers */
+ <0x00003800 0x00000200>, /* AFI registers */
+ <0x10000000 0x10000000>; /* configuration space */
+ reg-names = "pads", "afi", "cs";
+ interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
+ interrupt-names = "intr", "msi";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+
+ bus-range = <0x00 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00001000>, /* port 0 configuration space */
+ <0x02000000 0 0x00001000 0x00001000 0 0x00001000>, /* port 1 configuration space */
+ <0x02000000 0 0x00004000 0x00004000 0 0x00001000>, /* port 2 configuration space */
+ <0x01000000 0 0 0x02000000 0 0x00010000>, /* downstream I/O */
+ <0x02000000 0 0x20000000 0x20000000 0 0x08000000>, /* non-prefetchable memory */
+ <0x42000000 0 0x28000000 0x28000000 0 0x18000000>; /* prefetchable memory */
+
+ clocks = <&tegra_car TEGRA30_CLK_PCIE>,
+ <&tegra_car TEGRA30_CLK_AFI>,
+ <&tegra_car TEGRA30_CLK_PLL_E>,
+ <&tegra_car TEGRA30_CLK_CML0>;
+ clock-names = "pex", "afi", "pll_e", "cml";
+ resets = <&tegra_car 70>,
+ <&tegra_car 72>,
+ <&tegra_car 74>;
+ reset-names = "pex", "afi", "pcie_x";
+ status = "okay";
+
+ avdd-pexa-supply = <&ldo1_reg>;
+ vdd-pexa-supply = <&ldo1_reg>;
+ avdd-pexb-supply = <&ldo1_reg>;
+ vdd-pexb-supply = <&ldo1_reg>;
+ avdd-pex-pll-supply = <&ldo1_reg>;
+ avdd-plle-supply = <&ldo1_reg>;
+ vddio-pex-ctl-supply = <&sys_3v3_reg>;
+ hvdd-pex-supply = <&sys_3v3_pexs_reg>;
+
+ pci@1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x00000000 0 0x1000>;
+ reg = <0x000800 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "okay";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <2>;
+ };
+
+ pci@2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001000 0 0x00001000 0 0x1000>;
+ reg = <0x001000 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "disabled";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <2>;
+ };
+
+ pci@3,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001800 0 0x00004000 0 0x1000>;
+ reg = <0x001800 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "okay";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <2>;
+ };
+ };
+
+ # Tegra124
+ - |
+ #include <dt-bindings/clock/tegra124-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pcie@1003000 {
+ compatible = "nvidia,tegra124-pcie";
+ device_type = "pci";
+ reg = <0x01003000 0x00000800>, /* PADS registers */
+ <0x01003800 0x00000800>, /* AFI registers */
+ <0x02000000 0x10000000>; /* configuration space */
+ reg-names = "pads", "afi", "cs";
+ interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
+ interrupt-names = "intr", "msi";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+
+ bus-range = <0x00 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x02000000 0 0x01000000 0x01000000 0 0x00001000>, /* port 0 configuration space */
+ <0x02000000 0 0x01001000 0x01001000 0 0x00001000>, /* port 1 configuration space */
+ <0x01000000 0 0x0 0x12000000 0 0x00010000>, /* downstream I/O (64 KiB) */
+ <0x02000000 0 0x13000000 0x13000000 0 0x0d000000>, /* non-prefetchable memory (208 MiB) */
+ <0x42000000 0 0x20000000 0x20000000 0 0x20000000>; /* prefetchable memory (512 MiB) */
+
+ clocks = <&tegra_car TEGRA124_CLK_PCIE>,
+ <&tegra_car TEGRA124_CLK_AFI>,
+ <&tegra_car TEGRA124_CLK_PLL_E>,
+ <&tegra_car TEGRA124_CLK_CML0>;
+ clock-names = "pex", "afi", "pll_e", "cml";
+ resets = <&tegra_car 70>,
+ <&tegra_car 72>,
+ <&tegra_car 74>;
+ reset-names = "pex", "afi", "pcie_x";
+ status = "okay";
+
+ avddio-pex-supply = <&vdd_1v05_run>;
+ dvddio-pex-supply = <&vdd_1v05_run>;
+ avdd-pex-pll-supply = <&vdd_1v05_run>;
+ hvdd-pex-supply = <&vdd_3v3_lp0>;
+ hvdd-pex-pll-e-supply = <&vdd_3v3_lp0>;
+ vddio-pex-ctl-supply = <&vdd_3v3_lp0>;
+ avdd-pll-erefe-supply = <&avdd_1v05_run>;
+
+ /* Mini PCIe */
+ pci@1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x01000000 0 0x1000>;
+ reg = <0x000800 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "okay";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <2>;
+
+ phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-4}>;
+ phy-names = "pcie-0";
+ };
+
+ /* Gigabit Ethernet */
+ pci@2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001000 0 0x01001000 0 0x1000>;
+ reg = <0x001000 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "okay";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <1>;
+
+ phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-2}>;
+ phy-names = "pcie-0";
+ };
+ };
+
+ # Tegra210
+ - |
+ #include <dt-bindings/clock/tegra210-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ pcie@1003000 {
+ compatible = "nvidia,tegra210-pcie";
+ device_type = "pci";
+ reg = <0x01003000 0x00000800>, /* PADS registers */
+ <0x01003800 0x00000800>, /* AFI registers */
+ <0x02000000 0x10000000>; /* configuration space */
+ reg-names = "pads", "afi", "cs";
+ interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
+ <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
+ interrupt-names = "intr", "msi";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+
+ bus-range = <0x00 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x02000000 0 0x01000000 0x01000000 0 0x00001000>, /* port 0 configuration space */
+ <0x02000000 0 0x01001000 0x01001000 0 0x00001000>, /* port 1 configuration space */
+ <0x01000000 0 0x0 0x12000000 0 0x00010000>, /* downstream I/O (64 KiB) */
+ <0x02000000 0 0x13000000 0x13000000 0 0x0d000000>, /* non-prefetchable memory (208 MiB) */
+ <0x42000000 0 0x20000000 0x20000000 0 0x20000000>; /* prefetchable memory (512 MiB) */
+
+ clocks = <&tegra_car TEGRA210_CLK_PCIE>,
+ <&tegra_car TEGRA210_CLK_AFI>,
+ <&tegra_car TEGRA210_CLK_PLL_E>,
+ <&tegra_car TEGRA210_CLK_CML0>;
+ clock-names = "pex", "afi", "pll_e", "cml";
+ resets = <&tegra_car 70>,
+ <&tegra_car 72>,
+ <&tegra_car 74>;
+ reset-names = "pex", "afi", "pcie_x";
+ status = "okay";
+
+ avdd-pll-uerefe-supply = <&avdd_1v05_pll>;
+ hvddio-pex-supply = <&vdd_1v8>;
+ dvddio-pex-supply = <&vdd_pex_1v05>;
+ dvdd-pex-pll-supply = <&vdd_pex_1v05>;
+ hvdd-pex-pll-e-supply = <&vdd_1v8>;
+ vddio-pex-ctl-supply = <&vdd_1v8>;
+
+ pci@1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x01000000 0 0x1000>;
+ reg = <0x000800 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "okay";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <4>;
+
+ phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-0}>,
+ <&{/padctl@7009f000/pads/pcie/lanes/pcie-1}>,
+ <&{/padctl@7009f000/pads/pcie/lanes/pcie-2}>,
+ <&{/padctl@7009f000/pads/pcie/lanes/pcie-3}>;
+ phy-names = "pcie-0", "pcie-1", "pcie-2", "pcie-3";
+ };
+
+ pci@2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001000 0 0x01001000 0 0x1000>;
+ reg = <0x001000 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "okay";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <1>;
+
+ phys = <&{/padctl@7009f000/pads/pcie/lanes/pcie-4}>;
+ phy-names = "pcie-0";
+ };
+ };
+
+ # Tegra186
+ - |
+ #include <dt-bindings/clock/tegra186-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/memory/tegra186-mc.h>
+ #include <dt-bindings/power/tegra186-powergate.h>
+ #include <dt-bindings/reset/tegra186-reset.h>
+
+ pcie@10003000 {
+ compatible = "nvidia,tegra186-pcie";
+ power-domains = <&bpmp TEGRA186_POWER_DOMAIN_PCX>;
+ device_type = "pci";
+ reg = <0x10003000 0x00000800>, /* PADS registers */
+ <0x10003800 0x00000800>, /* AFI registers */
+ <0x40000000 0x10000000>; /* configuration space */
+ reg-names = "pads", "afi", "cs";
+
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
+ <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
+ interrupt-names = "intr", "msi";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+
+ bus-range = <0x00 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ ranges = <0x02000000 0 0x10000000 0x10000000 0 0x00001000>, /* port 0 configuration space */
+ <0x02000000 0 0x10001000 0x10001000 0 0x00001000>, /* port 1 configuration space */
+ <0x02000000 0 0x10004000 0x10004000 0 0x00001000>, /* port 2 configuration space */
+ <0x01000000 0 0x0 0x50000000 0 0x00010000>, /* downstream I/O (64 KiB) */
+ <0x02000000 0 0x50100000 0x50100000 0 0x07F00000>, /* non-prefetchable memory (127 MiB) */
+ <0x42000000 0 0x58000000 0x58000000 0 0x28000000>; /* prefetchable memory (640 MiB) */
+
+ clocks = <&bpmp TEGRA186_CLK_PCIE>,
+ <&bpmp TEGRA186_CLK_AFI>,
+ <&bpmp TEGRA186_CLK_PLLE>;
+ clock-names = "pex", "afi", "pll_e";
+
+ resets = <&bpmp TEGRA186_RESET_PCIE>,
+ <&bpmp TEGRA186_RESET_AFI>,
+ <&bpmp TEGRA186_RESET_PCIEXCLK>;
+ reset-names = "pex", "afi", "pcie_x";
+
+ iommus = <&smmu TEGRA186_SID_AFI>;
+ iommu-map = <0x0 &smmu TEGRA186_SID_AFI 0x1000>;
+ iommu-map-mask = <0x0>;
+
+ status = "okay";
+
+ dvdd-pex-supply = <&vdd_pex>;
+ hvdd-pex-pll-supply = <&vdd_1v8>;
+ hvdd-pex-supply = <&vdd_1v8>;
+ vddio-pexctl-aud-supply = <&vdd_1v8>;
+
+ pci@1,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82000800 0 0x10000000 0 0x1000>;
+ reg = <0x000800 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "okay";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <4>;
+ };
+
+ pci@2,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001000 0 0x10001000 0 0x1000>;
+ reg = <0x001000 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "disabled";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <0>;
+ };
+
+ pci@3,0 {
+ device_type = "pci";
+ assigned-addresses = <0x82001800 0 0x10004000 0 0x1000>;
+ reg = <0x001800 0 0 0 0>;
+ bus-range = <0x00 0xff>;
+ status = "disabled";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ nvidia,num-lanes = <1>;
+ };
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 14/38] dt-bindings: pci: tegra: Document interconnect paths
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (12 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 13/38] dt-bindings: pci: tegra: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 15/38] dt-bindings: sound: tegra: hda: Convert to json-schema Thierry Reding
` (23 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Add optional interconnects and interconnect-names properties to allow
describing the interconnect paths to and from the PCIe controller.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/pci/nvidia,tegra20-pcie.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.yaml b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.yaml
index e7cc95bfa810..3b8a4da23934 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.yaml
@@ -104,6 +104,17 @@ properties:
iommus:
$ref: "/schemas/types.yaml#/definitions/phandle-array"
+ interconnects:
+ description: Description of the interconnect paths for the PCIe controller;
+ see ../interconnect/interconnect.txt for details.
+
+ interconnect-names:
+ description: A list of names identifying each entry listed in the
+ "interconnects" property.
+ items:
+ - const: dma-mem # read
+ - const: write
+
pinctrl-names:
items:
# active state, puts PCIe I/O out of deep power down state
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 15/38] dt-bindings: sound: tegra: hda: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (13 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 14/38] dt-bindings: pci: tegra: Document interconnect paths Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 16/38] dt-bindings: sound: tegra: hda: Document interconnect paths Thierry Reding
` (22 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Tegra HDA controller bindings from the free-form text format
to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/sound/nvidia,tegra30-hda.txt | 35 -----
.../bindings/sound/nvidia,tegra30-hda.yaml | 128 ++++++++++++++++++
2 files changed, 128 insertions(+), 35 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
deleted file mode 100644
index 21cd310963b1..000000000000
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-NVIDIA Tegra30 HDA controller
-
-Required properties:
-- compatible : For Tegra30, must contain "nvidia,tegra30-hda". Otherwise,
- must contain '"nvidia,<chip>-hda", "nvidia,tegra30-hda"', where <chip> is
- tegra114, tegra124, or tegra132.
-- reg : Should contain the HDA registers location and length.
-- interrupts : The interrupt from the HDA controller.
-- clocks : Must contain an entry for each required entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names : Must include the following entries: hda, hda2hdmi, hda2codec_2x
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries: hda, hda2hdmi, hda2codec_2x
-
-Optional properties:
-- nvidia,model : The user-visible name of this sound complex. Since the property
- is optional, legacy boards can use default name provided in hda driver.
-
-Example:
-
-hda@70030000 {
- compatible = "nvidia,tegra124-hda", "nvidia,tegra30-hda";
- reg = <0x0 0x70030000 0x0 0x10000>;
- interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&tegra_car TEGRA124_CLK_HDA>,
- <&tegra_car TEGRA124_CLK_HDA2HDMI>,
- <&tegra_car TEGRA124_CLK_HDA2CODEC_2X>;
- clock-names = "hda", "hda2hdmi", "hda2codec_2x";
- resets = <&tegra_car 125>, /* hda */
- <&tegra_car 128>, /* hda2hdmi */
- <&tegra_car 111>; /* hda2codec_2x */
- reset-names = "hda", "hda2hdmi", "hda2codec_2x";
- nvidia,model = "jetson-tk1-hda";
-};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
new file mode 100644
index 000000000000..ea8e39934945
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
@@ -0,0 +1,128 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/nvidia,tegra30-hda.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra30 HDA controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@nvidia.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - description: NVIDIA Tegra30
+ const: nvidia,tegra30-hda
+
+ - description: NVIDIA Tegra114
+ items:
+ - const: nvidia,tegra114-hda
+ - const: nvidia,tegra30-hda
+
+ - description: NVIDIA Tegra124
+ items:
+ - const: nvidia,tegra124-hda
+ - const: nvidia,tegra30-hda
+
+ - description: NVIDIA Tegra132
+ items:
+ - const: nvidia,tegra132-hda
+ - const: nvidia,tegra124-hda
+ - const: nvidia,tegra30-hda
+
+ - description: NVIDIA Tegra210
+ items:
+ - const: nvidia,tegra210-hda
+ - const: nvidia,tegra30-hda
+
+ - description: NVIDIA Tegra186
+ items:
+ - const: nvidia,tegra186-hda
+ - const: nvidia,tegra30-hda
+
+ - description: NVIDIA Tegra194
+ items:
+ - const: nvidia,tegra194-hda
+ - const: nvidia,tegra30-hda
+
+ reg:
+ description: base address and size of the register region for the HDA
+ controller
+
+ interrupts:
+ description: interrupt from the HDA controller
+
+ clocks:
+ items:
+ - description: The main HDA controller clock
+ - description: The clock for the logic feeding data from HDA to HDMI.
+ - description: The clock for the logic feeding data from HDA to codec.
+
+ clock-names:
+ contains:
+ enum:
+ - hda
+ - hda2hdmi
+ - hda2codec_2x
+
+ resets:
+ items:
+ - description: Reset for the HDA controller.
+ - description: Reset for the HDA to HDMI logic.
+ - description: Reset for the HDA to codec logic.
+
+ reset-names:
+ contains:
+ enum:
+ - hda
+ - hda2hdmi
+ - hda2codec_2x
+
+ power-domains:
+ description: A list of PM domain specifiers that reference each
+ power-domain used by the xHCI controller. This list must comprise
+ of a specifier for the XUSBA and XUSBC power-domains. See
+ ../power/power_domain.txt and ../arm/tegra/nvidia,tegra20-pmc.txt
+ for details.
+
+ iommus:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ nvidia,model:
+ description: The user-visible name of this sound complex. Since the
+ property is optional, legacy boards can use default name provided in HDA
+ driver.
+ $ref: "/schemas/types.yaml#/definitions/string"
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/tegra124-car.h>
+
+ hda@70030000 {
+ compatible = "nvidia,tegra124-hda", "nvidia,tegra30-hda";
+ reg = <0x0 0x70030000 0x0 0x10000>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA124_CLK_HDA>,
+ <&tegra_car TEGRA124_CLK_HDA2HDMI>,
+ <&tegra_car TEGRA124_CLK_HDA2CODEC_2X>;
+ clock-names = "hda", "hda2hdmi", "hda2codec_2x";
+ resets = <&tegra_car 125>, /* hda */
+ <&tegra_car 128>, /* hda2hdmi */
+ <&tegra_car 111>; /* hda2codec_2x */
+ reset-names = "hda", "hda2hdmi", "hda2codec_2x";
+ nvidia,model = "jetson-tk1-hda";
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 16/38] dt-bindings: sound: tegra: hda: Document interconnect paths
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (14 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 15/38] dt-bindings: sound: tegra: hda: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 17/38] dt-bindings: usb: tegra-xusb: Convert to json-schema Thierry Reding
` (21 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/sound/nvidia,tegra30-hda.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
index ea8e39934945..15043c896c54 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml
@@ -90,6 +90,19 @@ properties:
iommus:
$ref: "/schemas/types.yaml#/definitions/phandle-array"
+ interconnects:
+ description: Description of the interconnect paths for the HDA controller;
+ see ../interconnect/interconnect.txt for details.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ interconnect-names:
+ description: A list of names identifying each entry listed in the
+ "interconnects" property.
+ $ref: "/schemas/types.yaml#/definitions/string-array"
+ items:
+ - const: dma-mem # read
+ - const: write
+
nvidia,model:
description: The user-visible name of this sound complex. Since the
property is optional, legacy boards can use default name provided in HDA
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 17/38] dt-bindings: usb: tegra-xusb: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (15 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 16/38] dt-bindings: sound: tegra: hda: Document interconnect paths Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 18/38] dt-bindings: usb: tegra-xusb: Document interconnect paths Thierry Reding
` (20 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Tegra XUSB controller bindings from the free-form text
format to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/usb/nvidia,tegra124-xusb.txt | 132 -------
.../bindings/usb/nvidia,tegra124-xusb.yaml | 360 ++++++++++++++++++
2 files changed, 360 insertions(+), 132 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
deleted file mode 100644
index 5bfcc0b4d6b9..000000000000
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-NVIDIA Tegra xHCI controller
-============================
-
-The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed by
-the Tegra XUSB pad controller.
-
-Required properties:
---------------------
-- compatible: Must be:
- - Tegra124: "nvidia,tegra124-xusb"
- - Tegra132: "nvidia,tegra132-xusb", "nvidia,tegra124-xusb"
- - Tegra210: "nvidia,tegra210-xusb"
- - Tegra186: "nvidia,tegra186-xusb"
-- reg: Must contain the base and length of the xHCI host registers, XUSB FPCI
- registers and XUSB IPFS registers.
-- reg-names: Must contain the following entries:
- - "hcd"
- - "fpci"
- - "ipfs"
-- interrupts: Must contain the xHCI host interrupt and the mailbox interrupt.
-- clocks: Must contain an entry for each entry in clock-names.
- See ../clock/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - xusb_host
- - xusb_host_src
- - xusb_falcon_src
- - xusb_ss
- - xusb_ss_src
- - xusb_ss_div2
- - xusb_hs_src
- - xusb_fs_src
- - pll_u_480m
- - clk_m
- - pll_e
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - xusb_host
- - xusb_ss
- - xusb_src
- Note that xusb_src is the shared reset for xusb_{ss,hs,fs,falcon,host}_src.
-- nvidia,xusb-padctl: phandle to the XUSB pad controller that is used to
- configure the USB pads used by the XHCI controller
-
-For Tegra124 and Tegra132:
-- avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
-- dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply 1.05 V.
-- avdd-usb-supply: USB controller power supply. Must supply 3.3 V.
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- avdd-usb-ss-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3 V.
-- hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3 V.
-
-For Tegra210:
-- dvddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
-- hvddio-pex-supply: High-voltage PCIe/USB3 power supply. Must supply 1.8 V.
-- avdd-usb-supply: USB controller power supply. Must supply 3.3 V.
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-uerefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- dvdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 1.8 V.
-
-For Tegra210 and Tegra186:
-- power-domains: A list of PM domain specifiers that reference each power-domain
- used by the xHCI controller. This list must comprise of a specifier for the
- XUSBA and XUSBC power-domains. See ../power/power_domain.txt and
- ../arm/tegra/nvidia,tegra20-pmc.txt for details.
-- power-domain-names: A list of names that represent each of the specifiers in
- the 'power-domains' property. Must include 'xusb_ss' and 'xusb_host' which
- represent the power-domains XUSBA and XUSBC, respectively. See
- ../power/power_domain.txt for details.
-
-Optional properties:
---------------------
-- phys: Must contain an entry for each entry in phy-names.
- See ../phy/phy-bindings.txt for details.
-- phy-names: Should include an entry for each PHY used by the controller. The
- following PHYs are available:
- - Tegra124: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1
- - Tegra132: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1
- - Tegra210: usb2-0, usb2-1, usb2-2, usb2-3, hsic-0, usb3-0, usb3-1, usb3-2,
- usb3-3
- - Tegra186: usb2-0, usb2-1, usb2-2, hsic-0, usb3-0, usb3-1, usb3-2
-
-Example:
---------
-
- usb@0,70090000 {
- compatible = "nvidia,tegra124-xusb";
- reg = <0x0 0x70090000 0x0 0x8000>,
- <0x0 0x70098000 0x0 0x1000>,
- <0x0 0x70099000 0x0 0x1000>;
- reg-names = "hcd", "fpci", "ipfs";
-
- interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
-
- clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>,
- <&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>,
- <&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>,
- <&tegra_car TEGRA124_CLK_XUSB_SS>,
- <&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>,
- <&tegra_car TEGRA124_CLK_XUSB_SS_SRC>,
- <&tegra_car TEGRA124_CLK_XUSB_HS_SRC>,
- <&tegra_car TEGRA124_CLK_XUSB_FS_SRC>,
- <&tegra_car TEGRA124_CLK_PLL_U_480M>,
- <&tegra_car TEGRA124_CLK_CLK_M>,
- <&tegra_car TEGRA124_CLK_PLL_E>;
- clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src",
- "xusb_ss", "xusb_ss_div2", "xusb_ss_src",
- "xusb_hs_src", "xusb_fs_src", "pll_u_480m",
- "clk_m", "pll_e";
- resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>;
- reset-names = "xusb_host", "xusb_ss", "xusb_src";
-
- nvidia,xusb-padctl = <&padctl>;
-
- phys = <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-1}>, /* mini-PCIe USB */
- <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-2}>, /* USB A */
- <&{/padctl@0,7009f000/pads/pcie/lanes/pcie-0}>; /* USB A */
- phy-names = "usb2-1", "usb2-2", "usb3-0";
-
- avddio-pex-supply = <&vdd_1v05_run>;
- dvddio-pex-supply = <&vdd_1v05_run>;
- avdd-usb-supply = <&vdd_3v3_lp0>;
- avdd-pll-utmip-supply = <&vddio_1v8>;
- avdd-pll-erefe-supply = <&avdd_1v05_run>;
- avdd-usb-ss-pll-supply = <&vdd_1v05_run>;
- hvdd-usb-ss-supply = <&vdd_3v3_lp0>;
- hvdd-usb-ss-pll-e-supply = <&vdd_3v3_lp0>;
- };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml
new file mode 100644
index 000000000000..4d9e4cfc459a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml
@@ -0,0 +1,360 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nvidia,tegra124-xusb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra xHCI controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ The Tegra xHCI controller supports both USB2 and USB3 interfaces exposed by
+ the Tegra XUSB pad controller.
+
+properties:
+ compatible:
+ oneOf:
+ - description: NVIDIA Tegra124
+ const: nvidia,tegra124-xusb
+
+ - description: NVIDIA Tegra132
+ items:
+ - const: nvidia,tegra132-xusb
+ - const: nvidia,tegra124-xusb
+
+ - description: NVIDIA Tegra210
+ const: nvidia,tegra210-xusb
+
+ - description: NVIDIA Tegra186
+ const: nvidia,tegra186-xusb
+
+ - description: NVIDIA Tegra194
+ const: nvidia,tegra194-xusb
+
+ reg:
+ minItems: 1
+ maxItems: 3
+
+ reg-names:
+ minItems: 1
+ maxItems: 3
+
+ interrupts:
+ items:
+ - description: xHCI host interrupt
+ - description: mailbox interrupt
+
+ clocks:
+ minItems: 9
+ maxItems: 11
+
+ clock-names:
+ minItems: 9
+ maxItems: 11
+
+ nvidia,xusb-padctl:
+ description: phandle to the XUSB pad controller that is used to configure
+ the USB pads used by the XHCI controller
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ # optional
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ resets:
+ items:
+ - description: reset for the XUSB host controller
+ - description: reset for the SuperSpeed logic
+ - description: shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+
+ reset-names:
+ items:
+ - const: xusb_host
+ - const: xusb_ss
+ - const: xusb_src
+
+ iommus:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ phys:
+ description: Must contain an entry for each entry in phy-names. See
+ ../phy/phy-bindings.txt for details.
+
+ phy-names:
+ description: Should include an entry for each PHY used by the controller.
+
+ power-domains:
+ description: A list of PM domain specifiers that reference each
+ power-domain used by the xHCI controller. This list must comprise
+ of a specifier for the XUSBA and XUSBC power-domains. See
+ ../power/power_domain.txt and ../arm/tegra/nvidia,tegra20-pmc.txt
+ for details.
+
+ power-domain-names:
+ description: A list of names that represent each of the specifiers
+ in the 'power-domains' property. See ../power/power_domain.txt for
+ details.
+
+patternProperties:
+ # USB device nodes can have arbitrary names, but always need a unit-address
+ "^.*@[0-9]+$":
+ type: object
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - clocks
+ - clock-names
+ - nvidia,xusb-padctl
+
+unevaluatedProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra124-xusb
+ then:
+ properties:
+ reg:
+ items:
+ - description: base and length of the xHCI host registers
+ - description: base and length of the XUSB FPCI registers
+ - description: base and length of the XUSB IPFS registers
+
+ reg-names:
+ items:
+ - const: hcd
+ - const: fpci
+ - const: ipfs
+
+ clocks:
+ minItems: 11
+
+ clock-names:
+ items:
+ - const: xusb_host
+ - const: xusb_host_src
+ - const: xusb_falcon_src
+ - const: xusb_ss
+ - const: xusb_ss_src
+ - const: xusb_ss_div2
+ - const: xusb_hs_src
+ - const: xusb_fs_src
+ - const: pll_u_480m
+ - const: clk_m
+ - const: pll_e
+
+ phy-names:
+ contains:
+ anyOf:
+ - const: usb2-0
+ - const: usb2-1
+ - const: usb2-2
+ - const: hsic-0
+ - const: hsic-1
+ - const: usb3-0
+ - const: usb3-1
+
+ avddio-pex-supply:
+ description: PCIe/USB3 analog logic power supply. Must supply
+ 1.05 V.
+
+ dvddio-pex-supply:
+ description: PCIe/USB3 digital logic power supply. Must supply
+ 1.05 V.
+
+ avdd-usb-supply:
+ description: USB controller power supply. Must supply 3.3 V.
+
+ hvdd-usb-ss-supply:
+ description: High-voltage PCIe/USB3 power supply. Must supply 3.3 V.
+
+ required:
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra210-xusb
+ then:
+ properties:
+ reg:
+ items:
+ - description: base and length of the xHCI host registers
+ - description: base and length of the XUSB FPCI registers
+ - description: base and length of the XUSB IPFS registers
+
+ reg-names:
+ items:
+ - const: hcd
+ - const: fpci
+ - const: ipfs
+
+ clocks:
+ minItems: 11
+
+ clock-names:
+ items:
+ - const: xusb_host
+ - const: xusb_host_src
+ - const: xusb_falcon_src
+ - const: xusb_ss
+ - const: xusb_ss_src
+ - const: xusb_ss_div2
+ - const: xusb_hs_src
+ - const: xusb_fs_src
+ - const: pll_u_480m
+ - const: clk_m
+ - const: pll_e
+
+ phy-names:
+ contains:
+ anyOf:
+ - const: usb2-0
+ - const: usb2-1
+ - const: usb2-2
+ - const: usb2-3
+ - const: hsic-0
+ - const: usb3-0
+ - const: usb3-1
+ - const: usb3-2
+ - const: usb3-3
+
+ dvddio-pex-supply:
+ description: PCIe/USB3 analog logic power supply. Must supply
+ 1.05 V.
+
+ hvddio-pex-supply:
+ description: High-voltage PCIe/USB3 power supply. Must supply 1.8 V.
+
+ avdd-usb-supply:
+ description: USB controller power supply. Must supply 3.3 V.
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra210-xusb
+ - nvidia,tegra186-xusb
+ - nvidia,tegra194-xusb
+ then:
+ properties:
+ power-domain-names:
+ items:
+ - description: the XUSBC power domain
+ const: xusb_host
+ - description: the XUSBA power domain
+ const: xusb_ss
+
+ required:
+ - power-domains
+ - power-domain-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-xusb
+ - nvidia,tegra194-xusb
+ then:
+ properties:
+ # Tegra186 doesn't have the IPFS registers
+ reg:
+ items:
+ - description: base and length of the xHCI host registers
+ - description: base and length of the XUSB FPCI registers
+
+ reg-names:
+ items:
+ - const: hcd
+ - const: fpci
+
+ clocks:
+ maxItems: 9
+
+ clock-names:
+ items:
+ - const: xusb_host
+ - const: xusb_falcon_src
+ - const: xusb_ss
+ - const: xusb_ss_src
+ - const: xusb_hs_src
+ - const: xusb_fs_src
+ - const: pll_u_480m
+ - const: clk_m
+ - const: pll_e
+
+ phy-names:
+ contains:
+ anyOf:
+ - const: usb2-0
+ - const: usb2-1
+ - const: usb2-2
+ - const: hsic-0
+ - const: usb3-0
+ - const: usb3-1
+ - const: usb3-2
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/tegra124-car.h>
+
+ usb@0,70090000 {
+ compatible = "nvidia,tegra124-xusb";
+ reg = <0x0 0x70090000 0x0 0x8000>,
+ <0x0 0x70098000 0x0 0x1000>,
+ <0x0 0x70099000 0x0 0x1000>;
+ reg-names = "hcd", "fpci", "ipfs";
+
+ interrupts = <GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&tegra_car TEGRA124_CLK_XUSB_HOST>,
+ <&tegra_car TEGRA124_CLK_XUSB_HOST_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FALCON_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_DIV2>,
+ <&tegra_car TEGRA124_CLK_XUSB_SS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_HS_SRC>,
+ <&tegra_car TEGRA124_CLK_XUSB_FS_SRC>,
+ <&tegra_car TEGRA124_CLK_PLL_U_480M>,
+ <&tegra_car TEGRA124_CLK_CLK_M>,
+ <&tegra_car TEGRA124_CLK_PLL_E>;
+ clock-names = "xusb_host", "xusb_host_src", "xusb_falcon_src",
+ "xusb_ss", "xusb_ss_div2", "xusb_ss_src",
+ "xusb_hs_src", "xusb_fs_src", "pll_u_480m",
+ "clk_m", "pll_e";
+ resets = <&tegra_car 89>, <&tegra_car 156>, <&tegra_car 143>;
+ reset-names = "xusb_host", "xusb_ss", "xusb_src";
+
+ nvidia,xusb-padctl = <&padctl>;
+
+ phys = <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-1}>, /* mini-PCIe USB */
+ <&{/padctl@0,7009f000/pads/usb2/lanes/usb2-2}>, /* USB A */
+ <&{/padctl@0,7009f000/pads/pcie/lanes/pcie-0}>; /* USB A */
+ phy-names = "usb2-1", "usb2-2", "usb3-0";
+
+ avddio-pex-supply = <&vdd_1v05_run>;
+ dvddio-pex-supply = <&vdd_1v05_run>;
+ avdd-usb-supply = <&vdd_3v3_lp0>;
+ avdd-pll-utmip-supply = <&vddio_1v8>;
+ avdd-pll-erefe-supply = <&avdd_1v05_run>;
+ avdd-usb-ss-pll-supply = <&vdd_1v05_run>;
+ hvdd-usb-ss-supply = <&vdd_3v3_lp0>;
+ hvdd-usb-ss-pll-e-supply = <&vdd_3v3_lp0>;
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 18/38] dt-bindings: usb: tegra-xusb: Document interconnect paths
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (16 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 17/38] dt-bindings: usb: tegra-xusb: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 19/38] dt-bindings: net: dwc-qos-ethernet: Convert to json-schema Thierry Reding
` (19 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Add optional interconnects and interconnect-names properties to allow
describing the interconnect paths to and from the XUSB controller.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/usb/nvidia,tegra124-xusb.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml
index 4d9e4cfc459a..cb1d9a6f5acc 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.yaml
@@ -82,6 +82,17 @@ properties:
iommus:
$ref: "/schemas/types.yaml#/definitions/phandle-array"
+ interconnects:
+ description: Description of the interconnect paths for the XHCI
+ controller; see ../interconnect/interconnect.txt for details.
+
+ interconnect-names:
+ description: A list of names identifying each entry listed in the
+ "interconnects" property.
+ items:
+ - const: dma-mem # read
+ - const: write
+
phys:
description: Must contain an entry for each entry in phy-names. See
../phy/phy-bindings.txt for details.
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 19/38] dt-bindings: net: dwc-qos-ethernet: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (17 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 18/38] dt-bindings: usb: tegra-xusb: Document interconnect paths Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 20/38] dt-bindings: net: dwc-qos-ethernet: Document interconnect paths Thierry Reding
` (18 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Synopsis/DesignWare Ethernet QOS device tree bindings from
free-form text format to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/net/snps,dwc-qos-ethernet.txt | 168 ----------
.../bindings/net/snps,dwc-qos-ethernet.yaml | 308 ++++++++++++++++++
2 files changed, 308 insertions(+), 168 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
create mode 100644 Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.yaml
diff --git a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
deleted file mode 100644
index ad3c6e109ce1..000000000000
--- a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.txt
+++ /dev/null
@@ -1,168 +0,0 @@
-* Synopsys DWC Ethernet QoS IP version 4.10 driver (GMAC)
-
-This binding is deprecated, but it continues to be supported, but new
-features should be preferably added to the stmmac binding document.
-
-This binding supports the Synopsys Designware Ethernet QoS (Quality Of Service)
-IP block. The IP supports multiple options for bus type, clocking and reset
-structure, and feature list. Consequently, a number of properties and list
-entries in properties are marked as optional, or only required in specific HW
-configurations.
-
-Required properties:
-- compatible: One of:
- - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10"
- Represents the IP core when integrated into the Axis ARTPEC-6 SoC.
- - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10"
- Represents the IP core when integrated into the NVIDIA Tegra186 SoC.
- - "snps,dwc-qos-ethernet-4.10"
- This combination is deprecated. It should be treated as equivalent to
- "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10". It is supported to be
- compatible with earlier revisions of this binding.
-- reg: Address and length of the register set for the device
-- clocks: Phandle and clock specifiers for each entry in clock-names, in the
- same order. See ../clock/clock-bindings.txt.
-- clock-names: May contain any/all of the following depending on the IP
- configuration, in any order:
- - "tx"
- The EQOS transmit path clock. The HW signal name is clk_tx_i.
- In some configurations (e.g. GMII/RGMII), this clock also drives the PHY TX
- path. In other configurations, other clocks (such as tx_125, rmii) may
- drive the PHY TX path.
- - "rx"
- The EQOS receive path clock. The HW signal name is clk_rx_i.
- In some configurations (e.g. GMII/RGMII), this clock is derived from the
- PHY's RX clock output. In other configurations, other clocks (such as
- rx_125, rmii) may drive the EQOS RX path.
- In cases where the PHY clock is directly fed into the EQOS receive path
- without intervening logic, the DT need not represent this clock, since it
- is assumed to be fully under the control of the PHY device/driver. In
- cases where SoC integration adds additional logic to this path, such as a
- SW-controlled clock gate, this clock should be represented in DT.
- - "slave_bus"
- The CPU/slave-bus (CSR) interface clock. This applies to any bus type;
- APB, AHB, AXI, etc. The HW signal name is hclk_i (AHB) or clk_csr_i (other
- buses).
- - "master_bus"
- The master bus interface clock. Only required in configurations that use a
- separate clock for the master and slave bus interfaces. The HW signal name
- is hclk_i (AHB) or aclk_i (AXI).
- - "ptp_ref"
- The PTP reference clock. The HW signal name is clk_ptp_ref_i.
- - "phy_ref_clk"
- This clock is deprecated and should not be used by new compatible values.
- It is equivalent to "tx".
- - "apb_pclk"
- This clock is deprecated and should not be used by new compatible values.
- It is equivalent to "slave_bus".
-
- Note: Support for additional IP configurations may require adding the
- following clocks to this list in the future: clk_rx_125_i, clk_tx_125_i,
- clk_pmarx_0_i, clk_pmarx1_i, clk_rmii_i, clk_revmii_rx_i, clk_revmii_tx_i.
- Configurations exist where multiple similar clocks are used at once, e.g. all
- of clk_rx_125_i, clk_pmarx_0_i, clk_pmarx1_i. For this reason it is best to
- extend the binding with a separate clock-names entry for each of those RX
- clocks, rather than repurposing the existing "rx" clock-names entry as a
- generic/logical clock in a similar fashion to "master_bus" and "slave_bus".
- This will allow easy support for configurations that support multiple PHY
- interfaces using a mux, and hence need to have explicit control over
- specific RX clocks.
-
- The following compatible values require the following set of clocks:
- - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10":
- - "slave_bus"
- - "master_bus"
- - "rx"
- - "tx"
- - "ptp_ref"
- - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10":
- - "slave_bus"
- - "master_bus"
- - "tx"
- - "ptp_ref"
- - "snps,dwc-qos-ethernet-4.10" (deprecated):
- - "phy_ref_clk"
- - "apb_clk"
-- interrupts: Should contain the core's combined interrupt signal
-- phy-mode: See ethernet.txt file in the same directory
-- resets: Phandle and reset specifiers for each entry in reset-names, in the
- same order. See ../reset/reset.txt.
-- reset-names: May contain any/all of the following depending on the IP
- configuration, in any order:
- - "eqos". The reset to the entire module. The HW signal name is hreset_n
- (AHB) or aresetn_i (AXI).
-
- The following compatible values require the following set of resets:
- (the reset properties may be omitted if empty)
- - "nvidia,tegra186-eqos", "snps,dwc-qos-ethernet-4.10":
- - "eqos".
- - "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10":
- - None.
- - "snps,dwc-qos-ethernet-4.10" (deprecated):
- - None.
-
-Optional properties:
-- dma-coherent: Present if dma operations are coherent
-- phy-reset-gpios: Phandle and specifier for any GPIO used to reset the PHY.
- See ../gpio/gpio.txt.
-- snps,en-lpi: If present it enables use of the AXI low-power interface
-- snps,write-requests: Number of write requests that the AXI port can issue.
- It depends on the SoC configuration.
-- snps,read-requests: Number of read requests that the AXI port can issue.
- It depends on the SoC configuration.
-- snps,burst-map: Bitmap of allowed AXI burst lengts, with the LSB
- representing 4, then 8 etc.
-- snps,txpbl: DMA Programmable burst length for the TX DMA
-- snps,rxpbl: DMA Programmable burst length for the RX DMA
-- snps,en-tx-lpi-clockgating: Enable gating of the MAC TX clock during
- TX low-power mode.
-- phy-handle: See ethernet.txt file in the same directory
-- mdio device tree subnode: When the GMAC has a phy connected to its local
- mdio, there must be device tree subnode with the following
- required properties:
- - compatible: Must be "snps,dwc-qos-ethernet-mdio".
- - #address-cells: Must be <1>.
- - #size-cells: Must be <0>.
-
- For each phy on the mdio bus, there must be a node with the following
- fields:
-
- - reg: phy id used to communicate to phy.
- - device_type: Must be "ethernet-phy".
- - fixed-mode device tree subnode: see fixed-link.txt in the same directory
-
-The MAC address will be determined using the optional properties
-defined in ethernet.txt.
-
-Examples:
-ethernet2@40010000 {
- clock-names = "phy_ref_clk", "apb_pclk";
- clocks = <&clkc 17>, <&clkc 15>;
- compatible = "snps,dwc-qos-ethernet-4.10";
- interrupt-parent = <&intc>;
- interrupts = <0x0 0x1e 0x4>;
- reg = <0x40010000 0x4000>;
- phy-handle = <&phy2>;
- phy-mode = "gmii";
- phy-reset-gpios = <&gpioctlr 43 GPIO_ACTIVE_LOW>;
-
- snps,en-tx-lpi-clockgating;
- snps,en-lpi;
- snps,write-requests = <2>;
- snps,read-requests = <16>;
- snps,burst-map = <0x7>;
- snps,txpbl = <8>;
- snps,rxpbl = <2>;
-
- dma-coherent;
-
- mdio {
- #address-cells = <0x1>;
- #size-cells = <0x0>;
- phy2: phy@1 {
- compatible = "ethernet-phy-ieee802.3-c22";
- device_type = "ethernet-phy";
- reg = <0x1>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.yaml b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.yaml
new file mode 100644
index 000000000000..252f11affd6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.yaml
@@ -0,0 +1,308 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/snps,dwc-qos-ethernet.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DWC Ethernet QoS IP version 4.10 driver (GMAC)
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Alexandre Torgue <alexandre.torgue@st.com>
+ - Giuseppe Cavallaro <peppe.cavallaro@st.com>
+ - Jose Abreu <joabreu@synopsys.com>
+
+description: |
+ This binding is deprecated, but it continues to be supported, but new
+ features should be preferably added to the stmmac binding document.
+
+ This binding supports the Synopsys Designware Ethernet QoS (Quality Of
+ Service) IP block. The IP supports multiple options for bus type, clocking
+ and reset structure, and feature list. Consequently, a number of properties
+ and list entries in properties are marked as optional, or only required in
+ specific HW configurations.
+
+properties:
+ compatible:
+ oneOf:
+ - description: Represents the IP core when integrated into the Axis
+ ARTPEC-6 SoC.
+ items:
+ - const: axis,artpec6-eqos
+ - const: snps,dwc-qos-ethernet-4.10
+
+ - description: Represents the IP core when integrated into the NVIDIA
+ Tegra186 SoC.
+ items:
+ - const: nvidia,tegra186-eqos
+ - const: snps,dwc-qos-ethernet-4.10
+
+ - description: Represents the IP core when integrated into the NVIDIA
+ Tegra194 SoC.
+ items:
+ - const: nvidia,tegra194-eqos
+ - const: nvidia,tegra186-eqos
+ - const: snps,dwc-qos-ethernet-4.10
+
+ - description: This combination is deprecated. It should be treated as
+ equivalent to "axis,artpec6-eqos", "snps,dwc-qos-ethernet-4.10". It
+ is supported to be compatible with earlier revisions of this binding.
+ items:
+ - const: snps,dwc-qos-ethernet-4.10
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ description: |
+ A phandle and specifier pair for each entry in the clock-names property.
+
+ Note: Support for additional IP configurations may require adding the
+ following clocks to this list in the future: clk_rx_125_i, clk_tx_125_i,
+ clk_pmarx_0_i, clk_pmarx1_i, clk_rmii_i, clk_revmii_rx_i,
+ clk_revmii_tx_i. Configurations exist where multiple similar clocks are
+ used at once, e.g. all of clk_rx_125_i, clk_pmarx_0_i, clk_pmarx1_i. For
+ this reason it is best to extend the binding with a separate clock-names
+ entry for each of those RX clocks, rather than repurposing the existing
+ "rx" clock-names entry as a generic/logical clock in a similar fashion
+ to "master_bus" and "slave_bus". This will allow easy support for
+ configurations that support multiple PHY interfaces using a mux, and
+ hence need to have explicit control over specific RX clocks.
+
+ interrupts:
+ description: Should contain the core's combined interrupt signal.
+
+ resets:
+ description: A phandle and reset specifier for each entry in reset-names,
+ in the same order.
+
+ reset-names:
+ description: A list of names corresponding to each entry in the resets
+ property.
+
+ dma-coherent:
+ description: Present if DMA operations are coherent.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ iommus:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ phy-reset-gpios:
+ description: A list of phandle and specifier for any GPIO used to reset
+ the PHY. See ../gpio/gpio.txt.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ snps,en-lpi:
+ description: If present it enables use of the AXI low-power interface.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ snps,write-requests:
+ description: Number of write requests that the AXI port can issue. It
+ depends on the SoC configuration.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ snps,read-requests:
+ description: Number of read requests that the AXI port can issue. It
+ depends on the SoC configuration.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ snps,burst-map:
+ description: Bitmap of allowed AXI burst lengts, with the LSB representing
+ 4, then 8 etc.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ snps,txpbl:
+ description: DMA Programmable burst length for the TX DMA.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ snps,rxpbl:
+ description: DMA Programmable burst length for the RX DMA.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ snps,en-tx-lpi-clockgating:
+ description: Enable gating of the MAC TX clock during TX low-power mode.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ mdio:
+ description: A subnode representing the GMAC's MDIO bus.
+ type: object
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^phy@[0-9a-f]+$":
+ $ref: "ethernet-phy.yaml"
+ description: Each PHY on the MDIO bus is represented by one of these
+ nodes.
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - phy-mode
+
+allOf:
+ - $ref: "ethernet-controller.yaml"
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra186-eqos
+ then:
+ properties:
+ reset-names:
+ items:
+ - description: The reset to the entire module. The HW signal name
+ is hreset_n (AHB) or aresetn_i (AXI).
+ const: eqos
+
+ clocks:
+ items:
+ - description: The master bus interface clock. Only required in
+ configurations that use a separate clock for the master and
+ slave bus interfaces. The HW signal name is hclk_i (AHB) or
+ aclk_i (AXI).
+
+ - description: The CPU/slave-bus (CSR) interface clock. This
+ applies to any bus type; APB, AHB, AXI, etc. The HW signal
+ name is hclk_i (AHB) or clk_csr_i (other buses).
+
+ - description: The EQOS receive path clock. The HW signal name is
+ clk_rx_i. In some configurations (e.g. GMII/RGMII), this clock
+ is derived from the PHY's RX clock output. In other
+ configurations, other clocks (such as rx_125, rmii) may drive
+ the EQOS RX path. In cases where the PHY clock is directly fed
+ into the EQOS receive path without intervening logic, the DT
+ need not represent this clock, since it is assumed to be fully
+ under the control of the PHY device or driver. In cases where
+ SoC integration adds additional logic to this path, such as a
+ SW-controlled clock gate, this clock should be represented in
+ DT.
+
+ - description: The EQOS transmit path clock. The HW signal name is
+ clk_tx_i. In some configurations (e.g. GMII/RGMII), this clock
+ also drives the PHY TX path. In other configurations, other
+ clocks (such as tx_125, rmii) may drive the PHY TX path.
+
+ - description: The PTP reference clock. The HW signal name is
+ clk_ptp_ref_i.
+
+ clock-names:
+ items:
+ - const: master_bus
+ - const: slave_bus
+ - const: rx
+ - const: tx
+ - const: ptp_ref
+
+ required:
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ allOf:
+ - const: axis,artpec6-eqos
+ - const: snps,dwc-qos-ethernet-4.10
+ then:
+ properties:
+ clocks:
+ items:
+ - description: The CPU/slave-bus (CSR) interface clock. This
+ applies to any bus type; APB, AHB, AXI, etc. The HW signal
+ name is hclk_i (AHB) or clk_csr_i (other buses).
+
+ - description: The master bus interface clock. Only required in
+ configurations that use a separate clock for the master and
+ slave bus interfaces. The HW signal name is hclk_i (AHB) or
+ aclk_i (AXI).
+
+ - description: The EQOS transmit path clock. The HW signal name is
+ clk_tx_i. In some configurations (e.g. GMII/RGMII), this clock
+ also drives the PHY TX path. In other configurations, other
+ clocks (such as tx_125, rmii) may drive the PHY TX path.
+
+ - description: The PTP reference clock. The HW signal name is
+ clk_ptp_ref_i.
+
+ clock-names:
+ items:
+ - const: slave_bus
+ - const: master_bus
+ - const: tx
+ - const: ptp_ref
+
+ - if:
+ properties:
+ compatible:
+ const: snps,dwc-qos-ethernet-4.10
+ then:
+ properties:
+ clocks:
+ items:
+ - description: The EQOS transmit path clock. The HW signal name is
+ clk_tx_i. In some configurations (e.g. GMII/RGMII), this clock
+ also drives the PHY TX path. In other configurations, other
+ clocks (such as tx_125, rmii) may drive the PHY TX path.
+
+ - description: The CPU/slave-bus (CSR) interface clock. This
+ applies to any bus type; APB, AHB, AXI, etc. The HW signal
+ name is hclk_i (AHB) or clk_csr_i (other buses).
+
+ clock-names:
+ items:
+ - const: phy_ref_clk
+ - const: apb_pclk
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ ethernet@40010000 {
+ clock-names = "phy_ref_clk", "apb_pclk";
+ clocks = <&clkc 17>, <&clkc 15>;
+ compatible = "snps,dwc-qos-ethernet-4.10";
+ interrupt-parent = <&intc>;
+ interrupts = <0x0 0x1e 0x4>;
+ reg = <0x40010000 0x4000>;
+ phy-handle = <&phy2>;
+ phy-mode = "gmii";
+ phy-reset-gpios = <&gpioctlr 43 GPIO_ACTIVE_LOW>;
+
+ snps,en-tx-lpi-clockgating;
+ snps,en-lpi;
+ snps,write-requests = <2>;
+ snps,read-requests = <16>;
+ snps,burst-map = <0x7>;
+ snps,txpbl = <8>;
+ snps,rxpbl = <2>;
+
+ dma-coherent;
+
+ mdio {
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+ phy2: phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ device_type = "ethernet-phy";
+ #phy-cells = <0>;
+ reg = <0x1>;
+ };
+ };
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 20/38] dt-bindings: net: dwc-qos-ethernet: Document interconnect paths
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (18 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 19/38] dt-bindings: net: dwc-qos-ethernet: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 21/38] dt-bindings: sound: sgtl5000: Convert to json-schema Thierry Reding
` (17 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Add optional interconnects and interconnect-names properties to allow
describing the interconnect paths to and from the Ethernet device.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/net/snps,dwc-qos-ethernet.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.yaml b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.yaml
index 252f11affd6b..779e06b32278 100644
--- a/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwc-qos-ethernet.yaml
@@ -123,6 +123,15 @@ properties:
description: Enable gating of the MAC TX clock during TX low-power mode.
$ref: "/schemas/types.yaml#/definitions/flag"
+ interconnects:
+ description: Description of the interconnect paths for the ethernet
+ controller; see ../interconnect/interconnect.txt for details.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ interconnect-names:
+ description: A list of names identifying each entry listed in the
+ "interconnects" property.
+
mdio:
description: A subnode representing the GMAC's MDIO bus.
type: object
@@ -208,6 +217,11 @@ allOf:
- const: tx
- const: ptp_ref
+ interconnect-names:
+ items:
+ - const: dma-mem # read
+ - const: write
+
required:
- resets
- reset-names
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 21/38] dt-bindings: sound: sgtl5000: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (19 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 20/38] dt-bindings: net: dwc-qos-ethernet: Document interconnect paths Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-18 2:41 ` Rob Herring
2020-06-12 14:18 ` [PATCH 22/38] dt-bindings: gpio: tegra186: Use unique include guard Thierry Reding
` (16 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Freescale SGTL5000 device tree bindings from free-form text
format to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/sound/sgtl5000.txt | 60 ----------
.../devicetree/bindings/sound/sgtl5000.yaml | 103 ++++++++++++++++++
.../devicetree/bindings/trivial-devices.yaml | 2 -
3 files changed, 103 insertions(+), 62 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/sgtl5000.txt
create mode 100644 Documentation/devicetree/bindings/sound/sgtl5000.yaml
diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.txt b/Documentation/devicetree/bindings/sound/sgtl5000.txt
deleted file mode 100644
index 9d9ff5184939..000000000000
--- a/Documentation/devicetree/bindings/sound/sgtl5000.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-* Freescale SGTL5000 Stereo Codec
-
-Required properties:
-- compatible : "fsl,sgtl5000".
-
-- reg : the I2C address of the device
-
-- #sound-dai-cells: must be equal to 0
-
-- clocks : the clock provider of SYS_MCLK
-
-- VDDA-supply : the regulator provider of VDDA
-
-- VDDIO-supply: the regulator provider of VDDIO
-
-Optional properties:
-
-- VDDD-supply : the regulator provider of VDDD
-
-- micbias-resistor-k-ohms : the bias resistor to be used in kOhms
- The resistor can take values of 2k, 4k or 8k.
- If set to 0 it will be off.
- If this node is not mentioned or if the value is unknown, then
- micbias resistor is set to 4K.
-
-- micbias-voltage-m-volts : the bias voltage to be used in mVolts
- The voltage can take values from 1.25V to 3V by 250mV steps
- If this node is not mentioned or the value is unknown, then
- the value is set to 1.25V.
-
-- lrclk-strength: the LRCLK pad strength. Possible values are:
-0, 1, 2 and 3 as per the table below:
-
-VDDIO 1.8V 2.5V 3.3V
-0 = Disable
-1 = 1.66 mA 2.87 mA 4.02 mA
-2 = 3.33 mA 5.74 mA 8.03 mA
-3 = 4.99 mA 8.61 mA 12.05 mA
-
-- sclk-strength: the SCLK pad strength. Possible values are:
-0, 1, 2 and 3 as per the table below:
-
-VDDIO 1.8V 2.5V 3.3V
-0 = Disable
-1 = 1.66 mA 2.87 mA 4.02 mA
-2 = 3.33 mA 5.74 mA 8.03 mA
-3 = 4.99 mA 8.61 mA 12.05 mA
-
-Example:
-
-sgtl5000: codec@a {
- compatible = "fsl,sgtl5000";
- reg = <0x0a>;
- #sound-dai-cells = <0>;
- clocks = <&clks 150>;
- micbias-resistor-k-ohms = <2>;
- micbias-voltage-m-volts = <2250>;
- VDDA-supply = <®_3p3v>;
- VDDIO-supply = <®_3p3v>;
-};
diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml
new file mode 100644
index 000000000000..4f29b63c54d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/sgtl5000.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale SGTL5000 Stereo Codec
+
+maintainers:
+ - Fabio Estevam <festevam@gmail.com>
+
+properties:
+ compatible:
+ const: fsl,sgtl5000
+
+ reg:
+ maxItems: 1
+
+ "#sound-dai-cells":
+ const: 0
+
+ clocks:
+ items:
+ - description: the clock provider of SYS_MCLK
+
+ VDDA-supply:
+ description: the regulator provider of VDDA
+
+ VDDIO-supply:
+ description: the regulator provider of VDDIO
+
+ VDDD-supply:
+ description: the regulator provider of VDDD
+
+ micbias-resistor-k-ohms:
+ description: The bias resistor to be used in kOhms. The resistor can take
+ values of 2k, 4k or 8k. If set to 0 it will be off. If this node is not
+ mentioned or if the value is unknown, then micbias resistor is set to
+ 4k.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 2, 4, 8 ]
+
+ micbias-voltage-m-volts:
+ description: The bias voltage to be used in mVolts. The voltage can take
+ values from 1.25V to 3V by 250mV steps. If this node is not mentioned
+ or the value is unknown, then the value is set to 1.25V.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000 ]
+
+ lrclk-strength:
+ description: |
+ The LRCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
+ table below:
+
+ VDDIO 1.8V 2.5V 3.3V
+ 0 = Disable
+ 1 = 1.66 mA 2.87 mA 4.02 mA
+ 2 = 3.33 mA 5.74 mA 8.03 mA
+ 3 = 4.99 mA 8.61 mA 12.05 mA
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3 ]
+
+ sclk-strength:
+ description: |
+ The SCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
+ table below:
+
+ VDDIO 1.8V 2.5V 3.3V
+ 0 = Disable
+ 1 = 1.66 mA 2.87 mA 4.02 mA
+ 2 = 3.33 mA 5.74 mA 8.03 mA
+ 3 = 4.99 mA 8.61 mA 12.05 mA
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3 ]
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+ - clocks
+ - VDDA-supply
+ - VDDIO-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ #sound-dai-cells = <0>;
+ clocks = <&clks 150>;
+ micbias-resistor-k-ohms = <2>;
+ micbias-voltage-m-volts = <2250>;
+ VDDA-supply = <®_3p3v>;
+ VDDIO-supply = <®_3p3v>;
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 4165352a590a..b7e94fe8643f 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -80,8 +80,6 @@ properties:
- fsl,mpl3115
# MPR121: Proximity Capacitive Touch Sensor Controller
- fsl,mpr121
- # SGTL5000: Ultra Low-Power Audio Codec
- - fsl,sgtl5000
# G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface
- gmt,g751
# Infineon IR38064 Voltage Regulator
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 21/38] dt-bindings: sound: sgtl5000: Convert to json-schema
2020-06-12 14:18 ` [PATCH 21/38] dt-bindings: sound: sgtl5000: Convert to json-schema Thierry Reding
@ 2020-06-18 2:41 ` Rob Herring
0 siblings, 0 replies; 76+ messages in thread
From: Rob Herring @ 2020-06-18 2:41 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:18:46PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the Freescale SGTL5000 device tree bindings from free-form text
> format to json-schema.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../devicetree/bindings/sound/sgtl5000.txt | 60 ----------
> .../devicetree/bindings/sound/sgtl5000.yaml | 103 ++++++++++++++++++
> .../devicetree/bindings/trivial-devices.yaml | 2 -
> 3 files changed, 103 insertions(+), 62 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/sgtl5000.txt
> create mode 100644 Documentation/devicetree/bindings/sound/sgtl5000.yaml
> diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml
> new file mode 100644
> index 000000000000..4f29b63c54d3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml
> @@ -0,0 +1,103 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/sgtl5000.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale SGTL5000 Stereo Codec
> +
> +maintainers:
> + - Fabio Estevam <festevam@gmail.com>
> +
> +properties:
> + compatible:
> + const: fsl,sgtl5000
> +
> + reg:
> + maxItems: 1
> +
> + "#sound-dai-cells":
> + const: 0
> +
> + clocks:
> + items:
> + - description: the clock provider of SYS_MCLK
> +
> + VDDA-supply:
> + description: the regulator provider of VDDA
> +
> + VDDIO-supply:
> + description: the regulator provider of VDDIO
> +
> + VDDD-supply:
> + description: the regulator provider of VDDD
> +
> + micbias-resistor-k-ohms:
> + description: The bias resistor to be used in kOhms. The resistor can take
> + values of 2k, 4k or 8k. If set to 0 it will be off. If this node is not
> + mentioned or if the value is unknown, then micbias resistor is set to
> + 4k.
> + $ref: "/schemas/types.yaml#/definitions/uint32"
Anything with standard unit suffix already has a type.
> + enum: [ 0, 2, 4, 8 ]
> +
> + micbias-voltage-m-volts:
> + description: The bias voltage to be used in mVolts. The voltage can take
> + values from 1.25V to 3V by 250mV steps. If this node is not mentioned
> + or the value is unknown, then the value is set to 1.25V.
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + enum: [ 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000 ]
> +
> + lrclk-strength:
> + description: |
> + The LRCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
> + table below:
> +
> + VDDIO 1.8V 2.5V 3.3V
> + 0 = Disable
> + 1 = 1.66 mA 2.87 mA 4.02 mA
> + 2 = 3.33 mA 5.74 mA 8.03 mA
> + 3 = 4.99 mA 8.61 mA 12.05 mA
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + enum: [ 0, 1, 2, 3 ]
> +
> + sclk-strength:
> + description: |
> + The SCLK pad strength. Possible values are: 0, 1, 2 and 3 as per the
> + table below:
> +
> + VDDIO 1.8V 2.5V 3.3V
> + 0 = Disable
> + 1 = 1.66 mA 2.87 mA 4.02 mA
> + 2 = 3.33 mA 5.74 mA 8.03 mA
> + 3 = 4.99 mA 8.61 mA 12.05 mA
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + enum: [ 0, 1, 2, 3 ]
> +
> +required:
> + - compatible
> + - reg
> + - "#sound-dai-cells"
> + - clocks
> + - VDDA-supply
> + - VDDIO-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + codec@a {
> + compatible = "fsl,sgtl5000";
> + reg = <0x0a>;
> + #sound-dai-cells = <0>;
> + clocks = <&clks 150>;
> + micbias-resistor-k-ohms = <2>;
> + micbias-voltage-m-volts = <2250>;
> + VDDA-supply = <®_3p3v>;
> + VDDIO-supply = <®_3p3v>;
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> index 4165352a590a..b7e94fe8643f 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> @@ -80,8 +80,6 @@ properties:
> - fsl,mpl3115
> # MPR121: Proximity Capacitive Touch Sensor Controller
> - fsl,mpr121
> - # SGTL5000: Ultra Low-Power Audio Codec
> - - fsl,sgtl5000
> # G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface
> - gmt,g751
> # Infineon IR38064 Voltage Regulator
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 22/38] dt-bindings: gpio: tegra186: Use unique include guard
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (20 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 21/38] dt-bindings: sound: sgtl5000: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 23/38] dt-bindings: gpio: tegra186: Convert to json-schema Thierry Reding
` (15 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
This header file can be included from the same source or DTS files as
the existing dt-bindings/gpio/tegra-gpio.h header, so make sure its
include guard is unique.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
include/dt-bindings/gpio/tegra186-gpio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/dt-bindings/gpio/tegra186-gpio.h b/include/dt-bindings/gpio/tegra186-gpio.h
index 0782b05e2775..af0d9583be70 100644
--- a/include/dt-bindings/gpio/tegra186-gpio.h
+++ b/include/dt-bindings/gpio/tegra186-gpio.h
@@ -8,8 +8,8 @@
* The second cell contains standard flag values specified in gpio.h.
*/
-#ifndef _DT_BINDINGS_GPIO_TEGRA_GPIO_H
-#define _DT_BINDINGS_GPIO_TEGRA_GPIO_H
+#ifndef _DT_BINDINGS_GPIO_TEGRA186_GPIO_H
+#define _DT_BINDINGS_GPIO_TEGRA186_GPIO_H
#include <dt-bindings/gpio/gpio.h>
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 23/38] dt-bindings: gpio: tegra186: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (21 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 22/38] dt-bindings: gpio: tegra186: Use unique include guard Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-18 2:44 ` Rob Herring
2020-06-12 14:18 ` [PATCH 24/38] dt-bindings: mfd: max77620: " Thierry Reding
` (14 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Tegra186 GPIO controller device tree bindings from free-form
text format to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/gpio/nvidia,tegra186-gpio.txt | 165 --------------
.../bindings/gpio/nvidia,tegra186-gpio.yaml | 215 ++++++++++++++++++
2 files changed, 215 insertions(+), 165 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt
create mode 100644 Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt
deleted file mode 100644
index adff16c71d21..000000000000
--- a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt
+++ /dev/null
@@ -1,165 +0,0 @@
-NVIDIA Tegra186 GPIO controllers
-
-Tegra186 contains two GPIO controllers; a main controller and an "AON"
-controller. This binding document applies to both controllers. The register
-layouts for the controllers share many similarities, but also some significant
-differences. Hence, this document describes closely related but different
-bindings and compatible values.
-
-The Tegra186 GPIO controller allows software to set the IO direction of, and
-read/write the value of, numerous GPIO signals. Routing of GPIO signals to
-package balls is under the control of a separate pin controller HW block. Two
-major sets of registers exist:
-
-a) Security registers, which allow configuration of allowed access to the GPIO
-register set. These registers exist in a single contiguous block of physical
-address space. The size of this block, and the security features available,
-varies between the different GPIO controllers.
-
-Access to this set of registers is not necessary in all circumstances. Code
-that wishes to configure access to the GPIO registers needs access to these
-registers to do so. Code which simply wishes to read or write GPIO data does not
-need access to these registers.
-
-b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO
-controllers, these registers are exposed via multiple "physical aliases" in
-address space, each of which access the same underlying state. See the hardware
-documentation for rationale. Any particular GPIO client is expected to access
-just one of these physical aliases.
-
-Tegra HW documentation describes a unified naming convention for all GPIOs
-implemented by the SoC. Each GPIO is assigned to a port, and a port may control
-a number of GPIOs. Thus, each GPIO is named according to an alphabetical port
-name and an integer GPIO name within the port. For example, GPIO_PA0, GPIO_PN6,
-or GPIO_PCC3.
-
-The number of ports implemented by each GPIO controller varies. The number of
-implemented GPIOs within each port varies. GPIO registers within a controller
-are grouped and laid out according to the port they affect.
-
-The mapping from port name to the GPIO controller that implements that port, and
-the mapping from port name to register offset within a controller, are both
-extremely non-linear. The header file <dt-bindings/gpio/tegra186-gpio.h>
-describes the port-level mapping. In that file, the naming convention for ports
-matches the HW documentation. The values chosen for the names are alphabetically
-sorted within a particular controller. Drivers need to map between the DT GPIO
-IDs and HW register offsets using a lookup table.
-
-Each GPIO controller can generate a number of interrupt signals. Each signal
-represents the aggregate status for all GPIOs within a set of ports. Thus, the
-number of interrupt signals generated by a controller varies as a rough function
-of the number of ports it implements. Note that the HW documentation refers to
-both the overall controller HW module and the sets-of-ports as "controllers".
-
-Each GPIO controller in fact generates multiple interrupts signals for each set
-of ports. Each GPIO may be configured to feed into a specific one of the
-interrupt signals generated by a set-of-ports. The intent is for each generated
-signal to be routed to a different CPU, thus allowing different CPUs to each
-handle subsets of the interrupts within a port. The status of each of these
-per-port-set signals is reported via a separate register. Thus, a driver needs
-to know which status register to observe. This binding currently defines no
-configuration mechanism for this. By default, drivers should use register
-GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could
-define a property to configure this.
-
-Required properties:
-- compatible
- Array of strings.
- One of:
- - "nvidia,tegra186-gpio".
- - "nvidia,tegra186-gpio-aon".
- - "nvidia,tegra194-gpio".
- - "nvidia,tegra194-gpio-aon".
-- reg-names
- Array of strings.
- Contains a list of names for the register spaces described by the reg
- property. May contain the following entries, in any order:
- - "gpio": Mandatory. GPIO control registers. This may cover either:
- a) The single physical alias that this OS should use.
- b) All physical aliases that exist in the controller. This is
- appropriate when the OS is responsible for managing assignment of
- the physical aliases.
- - "security": Optional. Security configuration registers.
- Users of this binding MUST look up entries in the reg property by name,
- using this reg-names property to do so.
-- reg
- Array of (physical base address, length) tuples.
- Must contain one entry per entry in the reg-names property, in a matching
- order.
-- interrupts
- Array of interrupt specifiers.
- The interrupt outputs from the HW block, one per set of ports, in the
- order the HW manual describes them. The number of entries required varies
- depending on compatible value:
- - "nvidia,tegra186-gpio": 6 entries.
- - "nvidia,tegra186-gpio-aon": 1 entry.
- - "nvidia,tegra194-gpio": 6 entries.
- - "nvidia,tegra194-gpio-aon": 1 entry.
-- gpio-controller
- Boolean.
- Marks the device node as a GPIO controller/provider.
-- #gpio-cells
- Single-cell integer.
- Must be <2>.
- Indicates how many cells are used in a consumer's GPIO specifier.
- In the specifier:
- - The first cell is the pin number.
- See <dt-bindings/gpio/tegra186-gpio.h>.
- - The second cell contains flags:
- - Bit 0 specifies polarity
- - 0: Active-high (normal).
- - 1: Active-low (inverted).
-- interrupt-controller
- Boolean.
- Marks the device node as an interrupt controller/provider.
-- #interrupt-cells
- Single-cell integer.
- Must be <2>.
- Indicates how many cells are used in a consumer's interrupt specifier.
- In the specifier:
- - The first cell is the GPIO number.
- See <dt-bindings/gpio/tegra186-gpio.h>.
- - The second cell is contains flags:
- - Bits [3:0] indicate trigger type and level:
- - 1: Low-to-high edge triggered.
- - 2: High-to-low edge triggered.
- - 4: Active high level-sensitive.
- - 8: Active low level-sensitive.
- Valid combinations are 1, 2, 3, 4, 8.
-
-Example:
-
-#include <dt-bindings/interrupt-controller/irq.h>
-
-gpio@2200000 {
- compatible = "nvidia,tegra186-gpio";
- reg-names = "security", "gpio";
- reg =
- <0x0 0x2200000 0x0 0x10000>,
- <0x0 0x2210000 0x0 0x10000>;
- interrupts =
- <0 47 IRQ_TYPE_LEVEL_HIGH>,
- <0 50 IRQ_TYPE_LEVEL_HIGH>,
- <0 53 IRQ_TYPE_LEVEL_HIGH>,
- <0 56 IRQ_TYPE_LEVEL_HIGH>,
- <0 59 IRQ_TYPE_LEVEL_HIGH>,
- <0 180 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
-};
-
-gpio@c2f0000 {
- compatible = "nvidia,tegra186-gpio-aon";
- reg-names = "security", "gpio";
- reg =
- <0x0 0xc2f0000 0x0 0x1000>,
- <0x0 0xc2f1000 0x0 0x1000>;
- interrupts =
- <0 60 IRQ_TYPE_LEVEL_HIGH>;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
new file mode 100644
index 000000000000..94cf164c9abf
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
@@ -0,0 +1,215 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/nvidia,tegra186-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra GPIO Controller (Tegra186 and later)
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description: |
+ Tegra186 contains two GPIO controllers; a main controller and an "AON"
+ controller. This binding document applies to both controllers. The register
+ layouts for the controllers share many similarities, but also some
+ significant differences. Hence, this document describes closely related but
+ different bindings and compatible values.
+
+ The Tegra186 GPIO controller allows software to set the IO direction of,
+ and read/write the value of, numerous GPIO signals. Routing of GPIO signals
+ to package balls is under the control of a separate pin controller hardware
+ block. Two major sets of registers exist:
+
+ a) Security registers, which allow configuration of allowed access to the
+ GPIO register set. These registers exist in a single contiguous block
+ of physical address space. The size of this block, and the security
+ features available, varies between the different GPIO controllers.
+
+ Access to this set of registers is not necessary in all circumstances.
+ Code that wishes to configure access to the GPIO registers needs access
+ to these registers to do so. Code which simply wishes to read or write
+ GPIO data does not need access to these registers.
+
+ b) GPIO registers, which allow manipulation of the GPIO signals. In some
+ GPIO controllers, these registers are exposed via multiple "physical
+ aliases" in address space, each of which access the same underlying
+ state. See the hardware documentation for rationale. Any particular
+ GPIO client is expected to access just one of these physical aliases.
+
+ Tegra HW documentation describes a unified naming convention for all GPIOs
+ implemented by the SoC. Each GPIO is assigned to a port, and a port may
+ control a number of GPIOs. Thus, each GPIO is named according to an
+ alphabetical port name and an integer GPIO name within the port. For
+ example, GPIO_PA0, GPIO_PN6, or GPIO_PCC3.
+
+ The number of ports implemented by each GPIO controller varies. The number
+ of implemented GPIOs within each port varies. GPIO registers within a
+ controller are grouped and laid out according to the port they affect.
+
+ The mapping from port name to the GPIO controller that implements that
+ port, and the mapping from port name to register offset within a
+ controller, are both extremely non-linear. The header file
+ <dt-bindings/gpio/tegra186-gpio.h> describes the port-level mapping. In
+ that file, the naming convention for ports matches the HW documentation.
+ The values chosen for the names are alphabetically sorted within a
+ particular controller. Drivers need to map between the DT GPIO IDs and HW
+ register offsets using a lookup table.
+
+ Each GPIO controller can generate a number of interrupt signals. Each
+ signal represents the aggregate status for all GPIOs within a set of
+ ports. Thus, the number of interrupt signals generated by a controller
+ varies as a rough function of the number of ports it implements. Note
+ that the HW documentation refers to both the overall controller HW
+ module and the sets-of-ports as "controllers".
+
+ Each GPIO controller in fact generates multiple interrupts signals for
+ each set of ports. Each GPIO may be configured to feed into a specific
+ one of the interrupt signals generated by a set-of-ports. The intent is
+ for each generated signal to be routed to a different CPU, thus allowing
+ different CPUs to each handle subsets of the interrupts within a port.
+ The status of each of these per-port-set signals is reported via a
+ separate register. Thus, a driver needs to know which status register to
+ observe. This binding currently defines no configuration mechanism for
+ this. By default, drivers should use register
+ GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could
+ define a property to configure this.
+
+properties:
+ compatible:
+ enum:
+ - nvidia,tegra186-gpio
+ - nvidia,tegra186-gpio-aon
+ - nvidia,tegra194-gpio
+ - nvidia,tegra194-gpio-aon
+
+ reg-names:
+ items:
+ - const: security
+ - const: gpio
+ minItems: 1
+ maxItems: 2
+
+ reg:
+ items:
+ - description: |
+ GPIO control registers. This may cover either:
+
+ a) The single physical alias that this OS should use.
+ b) All physical aliases that exist in the controller. This is
+ appropriate when the OS is responsible for managing assignment
+ of the physical aliases.
+ - description: Security configuration registers.
+ minItems: 1
+ maxItems: 2
+
+ interrupts:
+ description: The interrupt outputs from the HW block, one per set of
+ ports, in the order the HW manual describes them. The number of entries
+ required varies depending on compatible value.
+
+ gpio-controller:
+ description: Marks the device node as a GPIO controller/provider.
+ type: boolean
+
+ "#gpio-cells":
+ description: |
+ Indicates how many cells are used in a consumer's GPIO specifier. In the
+ specifier:
+
+ - The first cell is the pin number.
+ See <dt-bindings/gpio/tegra186-gpio.h>.
+ - The second cell contains flags:
+ - Bit 0 specifies polarity
+ - 0: Active-high (normal).
+ - 1: Active-low (inverted).
+ const: 2
+
+ interrupt-controller:
+ description: Marks the device node as an interrupt controller/provider.
+ type: boolean
+
+ "#interrupt-cells":
+ description: |
+ Indicates how many cells are used in a consumer's interrupt specifier.
+ In the specifier:
+
+ - The first cell is the GPIO number.
+ See <dt-bindings/gpio/tegra186-gpio.h>.
+ - The second cell is contains flags:
+ - Bits [3:0] indicate trigger type and level:
+ - 1: Low-to-high edge triggered.
+ - 2: High-to-low edge triggered.
+ - 4: Active high level-sensitive.
+ - 8: Active low level-sensitive.
+
+ Valid combinations are 1, 2, 3, 4, 8.
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-gpio
+ - nvidia,tegra194-gpio
+ then:
+ properties:
+ interrupts:
+ minItems: 6
+ maxItems: 6
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra186-gpio-aon
+ - nvidia,tegra194-gpio-aon
+ then:
+ properties:
+ interrupts:
+ minItems: 1
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ gpio@2200000 {
+ compatible = "nvidia,tegra186-gpio";
+ reg-names = "security", "gpio";
+ reg = <0x0 0x2200000 0x0 0x10000>,
+ <0x0 0x2210000 0x0 0x10000>;
+ interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>,
+ <0 50 IRQ_TYPE_LEVEL_HIGH>,
+ <0 53 IRQ_TYPE_LEVEL_HIGH>,
+ <0 56 IRQ_TYPE_LEVEL_HIGH>,
+ <0 59 IRQ_TYPE_LEVEL_HIGH>,
+ <0 180 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio@c2f0000 {
+ compatible = "nvidia,tegra186-gpio-aon";
+ reg-names = "security", "gpio";
+ reg = <0x0 0xc2f0000 0x0 0x1000>,
+ <0x0 0xc2f1000 0x0 0x1000>;
+ interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 23/38] dt-bindings: gpio: tegra186: Convert to json-schema
2020-06-12 14:18 ` [PATCH 23/38] dt-bindings: gpio: tegra186: Convert to json-schema Thierry Reding
@ 2020-06-18 2:44 ` Rob Herring
0 siblings, 0 replies; 76+ messages in thread
From: Rob Herring @ 2020-06-18 2:44 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:18:48PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the Tegra186 GPIO controller device tree bindings from free-form
> text format to json-schema.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../bindings/gpio/nvidia,tegra186-gpio.txt | 165 --------------
> .../bindings/gpio/nvidia,tegra186-gpio.yaml | 215 ++++++++++++++++++
> 2 files changed, 215 insertions(+), 165 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt
> create mode 100644 Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
> diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
> new file mode 100644
> index 000000000000..94cf164c9abf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml
> @@ -0,0 +1,215 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/nvidia,tegra186-gpio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra GPIO Controller (Tegra186 and later)
> +
> +maintainers:
> + - Thierry Reding <thierry.reding@gmail.com>
> + - Jon Hunter <jonathanh@nvidia.com>
> +
> +description: |
> + Tegra186 contains two GPIO controllers; a main controller and an "AON"
> + controller. This binding document applies to both controllers. The register
> + layouts for the controllers share many similarities, but also some
> + significant differences. Hence, this document describes closely related but
> + different bindings and compatible values.
> +
> + The Tegra186 GPIO controller allows software to set the IO direction of,
> + and read/write the value of, numerous GPIO signals. Routing of GPIO signals
> + to package balls is under the control of a separate pin controller hardware
> + block. Two major sets of registers exist:
> +
> + a) Security registers, which allow configuration of allowed access to the
> + GPIO register set. These registers exist in a single contiguous block
> + of physical address space. The size of this block, and the security
> + features available, varies between the different GPIO controllers.
> +
> + Access to this set of registers is not necessary in all circumstances.
> + Code that wishes to configure access to the GPIO registers needs access
> + to these registers to do so. Code which simply wishes to read or write
> + GPIO data does not need access to these registers.
> +
> + b) GPIO registers, which allow manipulation of the GPIO signals. In some
> + GPIO controllers, these registers are exposed via multiple "physical
> + aliases" in address space, each of which access the same underlying
> + state. See the hardware documentation for rationale. Any particular
> + GPIO client is expected to access just one of these physical aliases.
> +
> + Tegra HW documentation describes a unified naming convention for all GPIOs
> + implemented by the SoC. Each GPIO is assigned to a port, and a port may
> + control a number of GPIOs. Thus, each GPIO is named according to an
> + alphabetical port name and an integer GPIO name within the port. For
> + example, GPIO_PA0, GPIO_PN6, or GPIO_PCC3.
> +
> + The number of ports implemented by each GPIO controller varies. The number
> + of implemented GPIOs within each port varies. GPIO registers within a
> + controller are grouped and laid out according to the port they affect.
> +
> + The mapping from port name to the GPIO controller that implements that
> + port, and the mapping from port name to register offset within a
> + controller, are both extremely non-linear. The header file
> + <dt-bindings/gpio/tegra186-gpio.h> describes the port-level mapping. In
> + that file, the naming convention for ports matches the HW documentation.
> + The values chosen for the names are alphabetically sorted within a
> + particular controller. Drivers need to map between the DT GPIO IDs and HW
> + register offsets using a lookup table.
> +
> + Each GPIO controller can generate a number of interrupt signals. Each
> + signal represents the aggregate status for all GPIOs within a set of
> + ports. Thus, the number of interrupt signals generated by a controller
> + varies as a rough function of the number of ports it implements. Note
> + that the HW documentation refers to both the overall controller HW
> + module and the sets-of-ports as "controllers".
> +
> + Each GPIO controller in fact generates multiple interrupts signals for
> + each set of ports. Each GPIO may be configured to feed into a specific
> + one of the interrupt signals generated by a set-of-ports. The intent is
> + for each generated signal to be routed to a different CPU, thus allowing
> + different CPUs to each handle subsets of the interrupts within a port.
> + The status of each of these per-port-set signals is reported via a
> + separate register. Thus, a driver needs to know which status register to
> + observe. This binding currently defines no configuration mechanism for
> + this. By default, drivers should use register
> + GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could
> + define a property to configure this.
> +
> +properties:
> + compatible:
> + enum:
> + - nvidia,tegra186-gpio
> + - nvidia,tegra186-gpio-aon
> + - nvidia,tegra194-gpio
> + - nvidia,tegra194-gpio-aon
> +
> + reg-names:
> + items:
> + - const: security
> + - const: gpio
Wrong order? Doesn't match 'reg' description.
> + minItems: 1
> + maxItems: 2
> +
> + reg:
> + items:
> + - description: |
> + GPIO control registers. This may cover either:
> +
> + a) The single physical alias that this OS should use.
> + b) All physical aliases that exist in the controller. This is
> + appropriate when the OS is responsible for managing assignment
> + of the physical aliases.
> + - description: Security configuration registers.
> + minItems: 1
> + maxItems: 2
> +
> + interrupts:
> + description: The interrupt outputs from the HW block, one per set of
> + ports, in the order the HW manual describes them. The number of entries
> + required varies depending on compatible value.
> +
> + gpio-controller:
> + description: Marks the device node as a GPIO controller/provider.
> + type: boolean
Just:
gpio-controller: true
> +
> + "#gpio-cells":
> + description: |
> + Indicates how many cells are used in a consumer's GPIO specifier. In the
> + specifier:
> +
> + - The first cell is the pin number.
> + See <dt-bindings/gpio/tegra186-gpio.h>.
> + - The second cell contains flags:
> + - Bit 0 specifies polarity
> + - 0: Active-high (normal).
> + - 1: Active-low (inverted).
> + const: 2
> +
> + interrupt-controller:
> + description: Marks the device node as an interrupt controller/provider.
> + type: boolean
Just:
interrupt-controller: true
> +
> + "#interrupt-cells":
> + description: |
> + Indicates how many cells are used in a consumer's interrupt specifier.
> + In the specifier:
> +
> + - The first cell is the GPIO number.
> + See <dt-bindings/gpio/tegra186-gpio.h>.
> + - The second cell is contains flags:
> + - Bits [3:0] indicate trigger type and level:
> + - 1: Low-to-high edge triggered.
> + - 2: High-to-low edge triggered.
> + - 4: Active high level-sensitive.
> + - 8: Active low level-sensitive.
> +
> + Valid combinations are 1, 2, 3, 4, 8.
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra186-gpio
> + - nvidia,tegra194-gpio
> + then:
> + properties:
> + interrupts:
> + minItems: 6
> + maxItems: 6
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra186-gpio-aon
> + - nvidia,tegra194-gpio-aon
> + then:
> + properties:
> + interrupts:
> + minItems: 1
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + gpio@2200000 {
> + compatible = "nvidia,tegra186-gpio";
> + reg-names = "security", "gpio";
> + reg = <0x0 0x2200000 0x0 0x10000>,
> + <0x0 0x2210000 0x0 0x10000>;
> + interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>,
> + <0 50 IRQ_TYPE_LEVEL_HIGH>,
> + <0 53 IRQ_TYPE_LEVEL_HIGH>,
> + <0 56 IRQ_TYPE_LEVEL_HIGH>,
> + <0 59 IRQ_TYPE_LEVEL_HIGH>,
> + <0 180 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + gpio@c2f0000 {
> + compatible = "nvidia,tegra186-gpio-aon";
> + reg-names = "security", "gpio";
> + reg = <0x0 0xc2f0000 0x0 0x1000>,
> + <0x0 0xc2f1000 0x0 0x1000>;
> + interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 24/38] dt-bindings: mfd: max77620: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (22 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 23/38] dt-bindings: gpio: tegra186: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 25/38] dt-bindings: gpio: tegra: " Thierry Reding
` (13 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Maxim MAX77620 PMIC device tree bindings from free-form text
format to json-schema.
This also pulls in the GPIO, regulator, pinmux and thermal bindings for
the corresponding subdevices into the top-level binding so that it can
be described more consistently.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/gpio/gpio-max77620.txt | 25 -
.../devicetree/bindings/mfd/max77620.txt | 162 -----
.../devicetree/bindings/mfd/max77620.yaml | 662 ++++++++++++++++++
.../bindings/pinctrl/pinctrl-max77620.txt | 127 ----
.../bindings/regulator/regulator-max77620.txt | 222 ------
.../bindings/thermal/max77620_thermal.txt | 70 --
6 files changed, 662 insertions(+), 606 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-max77620.txt
delete mode 100644 Documentation/devicetree/bindings/mfd/max77620.txt
create mode 100644 Documentation/devicetree/bindings/mfd/max77620.yaml
delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
delete mode 100644 Documentation/devicetree/bindings/regulator/regulator-max77620.txt
delete mode 100644 Documentation/devicetree/bindings/thermal/max77620_thermal.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-max77620.txt b/Documentation/devicetree/bindings/gpio/gpio-max77620.txt
deleted file mode 100644
index 410e716fd3d2..000000000000
--- a/Documentation/devicetree/bindings/gpio/gpio-max77620.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-GPIO driver for MAX77620 Power management IC from Maxim Semiconductor.
-
-Device has 8 GPIO pins which can be configured as GPIO as well as the
-special IO functions.
-
-Required properties:
--------------------
-- gpio-controller : Marks the device node as a gpio controller.
-- #gpio-cells : Should be two. The first cell is the pin number and
- the second cell is used to specify the gpio polarity:
- 0 = active high
- 1 = active low
-For more details, please refer generic GPIO DT binding document
-<devicetree/bindings/gpio/gpio.txt>.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-...
-max77620@3c {
- compatible = "maxim,max77620";
-
- gpio-controller;
- #gpio-cells = <2>;
-};
diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt
deleted file mode 100644
index 5a642a51d58e..000000000000
--- a/Documentation/devicetree/bindings/mfd/max77620.txt
+++ /dev/null
@@ -1,162 +0,0 @@
-MAX77620 Power management IC from Maxim Semiconductor.
-
-Required properties:
--------------------
-- compatible: Must be one of
- "maxim,max77620"
- "maxim,max20024"
- "maxim,max77663"
-- reg: I2C device address.
-
-Optional properties:
--------------------
-- interrupts: The interrupt on the parent the controller is
- connected to.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: is <2> and their usage is compliant to the 2 cells
- variant of <../interrupt-controller/interrupts.txt>
- IRQ numbers for different interrupt source of MAX77620
- are defined at dt-bindings/mfd/max77620.h.
-
-- system-power-controller: Indicates that this PMIC is controlling the
- system power, see [1] for more details.
-
-[1] Documentation/devicetree/bindings/power/power-controller.txt
-
-Optional subnodes and their properties:
-=======================================
-
-Flexible power sequence configurations:
---------------------------------------
-The Flexible Power Sequencer (FPS) allows each regulator to power up under
-hardware or software control. Additionally, each regulator can power on
-independently or among a group of other regulators with an adjustable power-up
-and power-down delays (sequencing). GPIO1, GPIO2, and GPIO3 can be programmed
-to be part of a sequence allowing external regulators to be sequenced along
-with internal regulators. 32KHz clock can be programmed to be part of a
-sequence.
-
-The flexible sequencing structure consists of two hardware enable inputs
-(EN0, EN1), and 3 master sequencing timers called FPS0, FPS1 and FPS2.
-Each master sequencing timer is programmable through its configuration
-register to have a hardware enable source (EN1 or EN2) or a software enable
-source (SW). When enabled/disabled, the master sequencing timer generates
-eight sequencing events on different time periods called slots. The time
-period between each event is programmable within the configuration register.
-Each regulator, GPIO1, GPIO2, GPIO3, and 32KHz clock has a flexible power
-sequence slave register which allows its enable source to be specified as
-a flexible power sequencer timer or a software bit. When a FPS source of
-regulators, GPIOs and clocks specifies the enable source to be a flexible
-power sequencer, the power up and power down delays can be specified in
-the regulators, GPIOs and clocks flexible power sequencer configuration
-registers.
-
-When FPS event cleared (set to LOW), regulators, GPIOs and 32KHz
-clock are set into following state at the sequencing event that
-corresponds to its flexible sequencer configuration register.
- Sleep state: In this state, regulators, GPIOs
- and 32KHz clock get disabled at
- the sequencing event.
- Global Low Power Mode (GLPM): In this state, regulators are set in
- low power mode at the sequencing event.
-
-The configuration parameters of FPS is provided through sub-node "fps"
-and their child for FPS specific. The child node name for FPS are "fps0",
-"fps1", and "fps2" for FPS0, FPS1 and FPS2 respectively.
-
-The FPS configurations like FPS source, power up and power down slots for
-regulators, GPIOs and 32kHz clocks are provided in their respective
-configuration nodes which is explained in respective sub-system DT
-binding document.
-
-There is need for different FPS configuration parameters based on system
-state like when system state changed from active to suspend or active to
-power off (shutdown).
-
-Optional properties:
--------------------
--maxim,fps-event-source: u32, FPS event source like external
- hardware input to PMIC i.e. EN0, EN1 or
- software (SW).
- The macros are defined on
- dt-bindings/mfd/max77620.h
- for different control source.
- - MAX77620_FPS_EVENT_SRC_EN0
- for hardware input pin EN0.
- - MAX77620_FPS_EVENT_SRC_EN1
- for hardware input pin EN1.
- - MAX77620_FPS_EVENT_SRC_SW
- for software control.
-
--maxim,shutdown-fps-time-period-us: u32, FPS time period in microseconds
- when system enters in to shutdown
- state.
-
--maxim,suspend-fps-time-period-us: u32, FPS time period in microseconds
- when system enters in to suspend state.
-
--maxim,device-state-on-disabled-event: u32, describe the PMIC state when FPS
- event cleared (set to LOW) whether it
- should go to sleep state or low-power
- state. Following are valid values:
- - MAX77620_FPS_INACTIVE_STATE_SLEEP
- to set the PMIC state to sleep.
- - MAX77620_FPS_INACTIVE_STATE_LOW_POWER
- to set the PMIC state to low
- power.
- Absence of this property or other value
- will not change device state when FPS
- event get cleared.
-
-Here supported time periods by device in microseconds are as follows:
-MAX77620 supports 40, 80, 160, 320, 640, 1280, 2560 and 5120 microseconds.
-MAX20024 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds.
-MAX77663 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds.
-
--maxim,power-ok-control: configure map power ok bit
- 1: Enables POK(Power OK) to control nRST_IO and GPIO1
- POK function.
- 0: Disables POK control.
- if property missing, do not configure MPOK bit.
- If POK mapping is enabled for GPIO1/nRST_IO then,
- GPIO1/nRST_IO pins are HIGH only if all rails
- that have POK control enabled are HIGH.
- If any of the rails goes down(which are enabled for POK
- control) then, GPIO1/nRST_IO goes LOW.
- this property is valid for max20024 only.
-
-For DT binding details of different sub modules like GPIO, pincontrol,
-regulator, power, please refer respective device-tree binding document
-under their respective sub-system directories.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-
-max77620@3c {
- compatible = "maxim,max77620";
- reg = <0x3c>;
-
- interrupt-parent = <&intc>;
- interrupts = <0 86 IRQ_TYPE_NONE>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
-
- fps {
- fps0 {
- maxim,shutdown-fps-time-period-us = <1280>;
- maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN1>;
- };
-
- fps1 {
- maxim,shutdown-fps-time-period-us = <1280>;
- maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>;
- };
-
- fps2 {
- maxim,shutdown-fps-time-period-us = <1280>;
- maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_SW>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/max77620.yaml b/Documentation/devicetree/bindings/mfd/max77620.yaml
new file mode 100644
index 000000000000..ad2f58ce3d5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77620.yaml
@@ -0,0 +1,662 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/max77620.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim Semiconductor MAX77620 Power Management IC
+
+maintainers:
+ - Rob Herring <robh+dt@kernel.org>
+
+description:
+ The Maxim MAX77620 is a system power management IC that can be used to
+ drive the power sequences need to boot an SoC as well as provide runtime
+ configurable power supplies for various aspects of that SoC.
+
+ In addition, the MAX77620 has 8 GPIO pins which can be configured as GPIO
+ as well as a set of special I/O functions.
+
+ The MAX77620 also supports alarm interrupts when its die temperature crosses
+ 120° C and 140° C. These threshold temperatures are not configurable. The
+ device does not provide the real temperature of die, but merely indicates
+ whether the temperature is above or below the threshold levels.
+
+properties:
+ compatible:
+ enum:
+ - maxim,max77620
+ - maxim,max20024
+ - maxim,max77663
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: The interrupt on the parent the controller is connected to.
+ $ref: "/schemas/types.yaml#/definitions/uint32-array"
+
+ interrupt-controller:
+ description: Marks the device node as an interrupt controller.
+
+ "#interrupt-cells":
+ description: Must be 2 and their usage is compliant to the 2 cells
+ variant of <../interrupt-controller/interrupts.txt>. IRQ numbers for
+ different interrupt source of MAX77620 are defined at
+ dt-bindings/mfd/max77620.h.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ const: 2
+
+ system-power-controller:
+ $ref: "/schemas/types.yaml#/definitions/flag"
+ description:
+ Indicates that this PMIC is controlling the system power, see
+ ../power/power-controller.txt for more details.
+
+ "#gpio-cells":
+ description: The first cell is the pin number and the second cell is used
+ to specify the GPIO polarity (0 = active high, 1 = active low).
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ const: 2
+
+ gpio-controller:
+ description: Marks the device node as a GPIO controller.
+ type: boolean
+
+ "#thermal-sensor-cells":
+ description: Please refer to ../thermal/thermal.txt for more details.
+ const: 0
+
+ fps:
+ description: |
+ The Flexible Power Sequencer (FPS) allows each regulator to power up
+ under hardware or software control. Additionally, each regulator can
+ power on independently or among a group of other regulators with an
+ adjustable power-up and power-down delays (sequencing). GPIO1, GPIO2,
+ and GPIO3 can be programmed to be part of a sequence allowing external
+ regulators to be sequenced along with internal regulators. 32KHz clock
+ can be programmed to be part of a sequence.
+
+ The flexible sequencing structure consists of two hardware enable
+ inputs (EN0, EN1), and 3 master sequencing timers called FPS0, FPS1
+ and FPS2. Each master sequencing timer is programmable through its
+ configuration register to have a hardware enable source (EN1 or EN2)
+ or a software enable source (SW). When enabled/disabled, the master
+ sequencing timer generates eight sequencing events on different time
+ periods called slots. The time period between each event is
+ programmable within the configuration register. Each regulator,
+ GPIO1, GPIO2, GPIO3, and 32KHz clock has a flexible power sequence
+ slave register which allows its enable source to be specified as a
+ flexible power sequencer timer or a software bit. When a FPS source
+ of regulators, GPIOs and clocks specifies the enable source to be a
+ flexible power sequencer, the power up and power down delays can be
+ specified in the regulators, GPIOs and clocks flexible power
+ sequencer configuration registers.
+
+ When FPS event cleared (set to LOW), regulators, GPIOs and 32KHz
+ clock are set into following state at the sequencing event that
+ corresponds to its flexible sequencer configuration register.
+
+ Sleep state: In this state, regulators, GPIOs and 32KHz clock get
+ disabled at the sequencing event.
+
+ Global Low Power Mode (GLPM): In this state, regulators are set in
+ low power mode at the sequencing event.
+
+ The configuration parameters of FPS is provided through sub-node
+ "fps" and their child for FPS specific. The child node name for FPS
+ are "fps0", "fps1", and "fps2" for FPS0, FPS1 and FPS2 respectively.
+
+ The FPS configurations like FPS source, power up and power down slots
+ for regulators, GPIOs and 32kHz clocks are provided in their respective
+ configuration nodes which is explained in respective sub-system DT
+ binding document.
+
+ There is need for different FPS configuration parameters based on
+ system state like when system state changed from active to suspend or
+ active to power off (shutdown).
+ type: object
+ properties:
+ maxim,fps-event-source:
+ description: |
+ FPS event source like external hardware input to PMIC i.e. EN0, EN1
+ or software (SW).
+
+ The macros are defined on dt-bindings/mfd/max77620.h for different
+ control source.
+
+ - MAX77620_FPS_EVENT_SRC_EN0: for hardware input pin EN0
+ - MAX77620_FPS_EVENT_SRC_EN1: for hardware input pin EN1
+ - MAX77620_FPS_EVENT_SRC_SW: for software control
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ maxim,shutdown-fps-time-period-us:
+ description: FPS time period in microseconds when system enters into
+ shutdown state.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ maxim,suspend-fps-time-period-us:
+ description: FPS time period in microseconds when system enters into
+ suspend state.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ maxim,device-state-on-disabled-event:
+ description: |
+ Describe the PMIC state when FPS event cleared (set to LOW) whether
+ it should go to sleep state or low-power state. Following are valid
+ values:
+
+ - MAX77620_FPS_INACTIVE_STATE_SLEEP: to set the PMIC state to
+ sleep
+ - MAX77620_FPS_INACTIVE_STATE_LOW_POWER: to set the PMIC state to
+ low power
+
+ Absence of this property or other value will not change device state
+ when FPS event get cleared.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ maxim,power-ok-control:
+ description: |
+ Used to configure the map power OK bit.
+
+ - 1: Enables POK(Power OK) to control nRST_IO and GPIO1 POK
+ function.
+ - 0: Disables POK control.
+
+ If this property is missing, do not configure MPOK bit. If POK
+ mapping is enabled for GPIO1/nRST_IO then, GPIO1/nRST_IO pins are
+ HIGH only if all rails that have POK control enabled are HIGH.
+
+ If any of the rails goes down(which are enabled for POK control)
+ then, GPIO1/nRST_IO goes LOW. this property is valid for max20024
+ only.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+
+ regulators:
+ description: |
+ The MAX77620 has multiple DCDCs (sd[0-3]) and LDOs (ldo[0-8]). Details
+ about each of these regulators are defined using child nodes named after
+ the regulator under a top-level "regulators" node. Input supplies for
+ each of the regulators are defined in the "regulators" node.
+
+ Each subnode should contain the constraints and initialization details
+ for the corresponding regulator. The definition for each of these nodes
+ is defined using the standard bindings for regulators found in:
+
+ ../regulator/regulator.txt
+
+ Additional properties required to configure FPS parameters for SDs and
+ LDOs are defined below.
+ type: object
+ properties:
+ in-sd0-supply:
+ description: input supply for SD0, INA-SD0 or INB-SD0 pins
+
+ in-sd1-supply:
+ description: input supply for SD1
+
+ in-sd2-supply:
+ description: input supply for SD2
+
+ in-sd3-supply:
+ description: input supply for SD3
+
+ in-ld0-1-supply:
+ description: input supply for LDO0 and LDO1
+
+ in-ld2-supply:
+ description: input supply for LDO2
+
+ in-ld3-5-supply:
+ description: input supply for LDO3 and LDO5
+
+ in-ld4-6-supply:
+ description: input supply for LDO4 and LDO6
+
+ in-ld7-8-supply:
+ description: input supply for LDO7 and LDO8
+
+ patternProperties:
+ "^(sd[0-3]|ldo[0-8])$":
+ type: object
+ $ref: "/schemas/regulator/regulator.yaml"
+ properties:
+ maxim,active-fps-source:
+ description: |
+ FPS source for the regulators to get enabled/disabled when the
+ system is in active state. Valid values are:
+
+ - MAX77620_FPS_SRC_0: FPS source is FPS0.
+ - MAX77620_FPS_SRC_1: FPS source is FPS1.
+ - MAX77620_FPS_SRC_2: FPS source is FPS2.
+ - MAX77620_FPS_SRC_NONE: Regulator is not controlled by FPS
+ events and it gets enabled/disabled by register access.
+
+ Absence of this property will leave the FPS configuration
+ register for that regulator at the default value.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3 ]
+
+ maxim,active-fps-power-up-slot:
+ description: Sequencing event slot number on which the regulator
+ gets enabled when master FPS input event set to HIGH. Valid
+ values are 0 to 7. This is applicable if FPS source is selected
+ as FPS0, FPS1 or FPS2.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+ maxim,active-fps-power-down-slot:
+ description: Sequencing event slot number on which the regulator
+ gets disabled when master FPS input event set to LOW. Valid
+ values are 0 to 7. This is applicable if FPS source is selected
+ as FPS0, FPS1 or FPS2.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+ maxim,suspend-fps-source:
+ description: This is same as "maxim,active-fps-source" but the
+ value gets configured when the system enters suspend.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3 ]
+
+ maxim,suspend-fps-power-up-slot:
+ description: This is same as "maxim,active-fps-power-up-slot" but
+ the value gets configured when the system enters suspend. This
+ is applicable if the suspend state FPS source is selected as
+ FPS0, FPS1 or FPS2.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+ maxim,suspend-fps-power-down-slot:
+ description: This is same as "maxim,active-fps-power-down-slot"
+ but this value gets configured when the system enters suspend.
+ This is applicable if the suspend state FPS source is selected
+ as FPS0, FPS1 or FPS2.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+ maxim,ramp-rate-setting:
+ description: |
+ Ramp rate (uV/us) setting to be configured for the device. The
+ platform may have a ramp rate different from that advertised if
+ it has design variation from Maxim's recommended rate. In this
+ case, the platform specific ramp rate is used for ramp time
+ calculation and this property is used for device register
+ configurations. The measured ramp rate of platform is provided
+ by the "regulator-ramp-delay" property as described in
+ <../regulator/regulator.txt>.
+
+ The Maxim Max77620 PMIC supports the following ramp delays:
+
+ - SD: 13.75 mV/us, 27.5 mV/us, 55 mV/us
+ - LDOs: 5 mV/us, 100 mV/us
+
+ Note: If the measured ramp delay is same as advertised ramp
+ delay then it is not required to provide the ramp delay with
+ property "maxim,ramp-rate-setting". The ramp rate can be
+ provided by the regulator-ramp-delay which will be used for
+ ramp time calculation for voltage change as well as for
+ device configuration.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 5000, 13750, 27500, 55000, 100000 ]
+
+patternProperties:
+ "^gpio(@[0-9]+)?$":
+ type: object
+ properties:
+ gpio-hog:
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ output-high:
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ gpios:
+ $ref: "/schemas/types.yaml#/definitions/uint32-matrix"
+
+ "^pinmux(@[0-9]+)?$":
+ type: object
+ patternProperties:
+ "^gpio[0-7_]+$":
+ type: object
+ properties:
+ pins:
+ items:
+ pattern: "^gpio[0-7]$"
+ minItems: 1
+ maxItems: 8
+
+ function:
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum:
+ - gpio
+ - lpm-control-in
+ - fps-out
+ - 32k-out1
+ - sd0-dvs-in
+ - sd1-dvs-in
+ - reference-out
+
+ drive-push-pull:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1 ]
+
+ drive-open-drain:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1 ]
+
+ bias-pull-up:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1 ]
+
+ bias-pull-down:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1 ]
+
+ maxim,active-fps-source:
+ description: |
+ FPS source for the GPIOs to get enabled/disabled when the system
+ is in active state. Valid values are:
+
+ - MAX77620_FPS_SRC_0: FPS source is FPS0.
+ - MAX77620_FPS_SRC_1: FPS source is FPS1.
+ - MAX77620_FPS_SRC_2: FPS source is FPS2.
+ - MAX77620_FPS_SRC_NONE: GPIO is not controlled by FPS events
+ and it gets enabled/disabled by register access.
+
+ Absence of this property will leave the FPS configuration
+ register for that GPIO at the default value.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4 ]
+
+ maxim,active-fps-power-up-slot:
+ description: Sequencing event slot number on which the GPIO gets
+ enabled when master FPS input event set to HIGH. Valid values
+ are 0 to 7. This is applicable if FPS source is selected as
+ FPS0, FPS1 or FPS2.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+ maxim,active-fps-power-down-slot:
+ description: Sequencing event slot number on which the GPIO gets
+ disabled when master FPS input event set to LOW. Valid values
+ are 0 to 7. This is applicable if FPS source is selected as
+ FPS0, FPS1 or FPS2.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+ maxim,suspend-fps-source:
+ description: This is same as "maxim,active-fps-source" but the
+ value gets configured when the system enters suspend.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4 ]
+
+ maxim,suspend-fps-power-up-slot:
+ description: This is same as "maxim,active-fps-power-up-slot" but
+ the value gets configured when the system enters suspend. This
+ is applicable if the suspend state FPS source is selected as
+ FPS0, FPS1 or FPS2.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+ maxim,suspend-fps-power-down-slot:
+ description: This is same as "maxim,active-fps-power-down-slot"
+ but this value gets configured when the system enters suspend.
+ This is applicable if the suspend state FPS source is selected
+ as FPS0, FPS1 or FPS2.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 0, 1, 2, 3, 4, 5, 6, 7 ]
+
+ required:
+ - pins
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: maxim,max77620
+ then:
+ properties:
+ fps:
+ properties:
+ maxim,shutdown-fps-time-period-us:
+ enum: [ 40, 80, 160, 320, 640, 1280, 2560, 5120 ]
+
+ maxim,suspend-fps-time-period-us:
+ enum: [ 40, 80, 160, 320, 640, 1280, 2560, 5120 ]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: maxim,max20024
+ then:
+ properties:
+ fps:
+ properties:
+ maxim,shutdown-fps-time-period-us:
+ enum: [ 20, 40, 80, 160, 320, 640, 1280, 2540 ]
+
+ maxim,suspend-fps-time-period-us:
+ enum: [ 20, 40, 80, 160, 320, 640, 1280, 2540 ]
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: maxim,max77663
+ then:
+ properties:
+ fps:
+ properties:
+ maxim,shutdown-fps-time-period-us:
+ enum: [ 20, 40, 80, 160, 320, 640, 1280, 2540 ]
+
+ maxim,suspend-fps-time-period-us:
+ enum: [ 20, 40, 80, 160, 320, 640, 1280, 2540 ]
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/mfd/max77620.h>
+ #include <dt-bindings/thermal/thermal.h>
+
+ i2c@7000d000 {
+ reg = <0x7000d000 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic: pmic@3c {
+ compatible = "maxim,max77620";
+ reg = <0x3c>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+
+ #interrupt-cells = <2>;
+ interrupt-controller;
+
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ #thermal-sensor-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&default>;
+
+ fps {
+ fps0 {
+ maxim,shutdown-fps-time-period-us = <1280>;
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN1>;
+ };
+
+ fps1 {
+ maxim,shutdown-fps-time-period-us = <1280>;
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>;
+ };
+
+ fps2 {
+ maxim,shutdown-fps-time-period-us = <1280>;
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_SW>;
+ };
+ };
+
+ default: pinmux {
+ gpio0 {
+ pins = "gpio0";
+ function = "gpio";
+ };
+
+ gpio1 {
+ pins = "gpio1";
+ function = "fps-out";
+ maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
+ };
+
+ gpio2 {
+ pins = "gpio2";
+ function = "fps-out";
+ maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
+ };
+ };
+
+ regulators {
+ in-ldo0-1-supply = <&sd2>;
+ in-ldo7-8-supply = <&sd2>;
+
+ sd0 {
+ regulator-name = "vdd-core";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
+ };
+
+ sd1 {
+ regulator-name = "vddio-ddr";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+ maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
+ };
+
+ sd2 {
+ regulator-name = "vdd-pre-reg";
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
+ };
+
+ sd3 {
+ regulator-name = "vdd-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo0 {
+ regulator-name = "avdd-sys";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1 {
+ regulator-name = "vdd-pex";
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1050000>;
+ };
+
+ ldo2 {
+ regulator-name = "vddio-sdmmc3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo3 {
+ regulator-name = "vdd-cam-hv";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ ldo4 {
+ regulator-name = "vdd-rtc";
+ regulator-min-microvolt = <1250000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5 {
+ regulator-name = "avdd-ts-hv";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ };
+
+ ldo6 {
+ regulator-name = "vdd-ts";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo7 {
+ regulator-name = "vdd-gen-pll-edp";
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1050000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo8 {
+ regulator-name = "vdd-hdmi-dp";
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1050000>;
+ };
+ };
+ };
+ };
+
+ thermal-zones {
+ pmic-die {
+ polling-delay = <0>;
+ polling-delay-passive = <0>;
+ thermal-sensors = <&pmic>;
+
+ trips {
+ pmic_die_warn_temp_thresh: hot-die {
+ temperature = <120000>;
+ type = "hot";
+ hysteresis = <0>;
+ };
+
+ pmic_die_crit_temp_thresh: cirtical-die {
+ temperature = <140000>;
+ type = "critical";
+ hysteresis = <0>;
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&pmic_die_warn_temp_thresh>;
+ cooling-device = <&cool_dev THERMAL_NO_LIMIT
+ THERMAL_NO_LIMIT>;
+ contribution = <100>;
+ };
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
deleted file mode 100644
index 511fc234558b..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
+++ /dev/null
@@ -1,127 +0,0 @@
-Pincontrol driver for MAX77620 Power management IC from Maxim Semiconductor.
-
-Device has 8 GPIO pins which can be configured as GPIO as well as the
-special IO functions.
-
-Please refer file <devicetree/bindings/pinctrl/pinctrl-bindings.txt>
-for details of the common pinctrl bindings used by client devices,
-including the meaning of the phrase "pin configuration node".
-
-Optional Pinmux properties:
---------------------------
-Following properties are required if default setting of pins are required
-at boot.
-- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>.
-- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
- <pinctrl-bindings.txt>.
-
-The pin configurations are defined as child of the pinctrl states node. Each
-sub-node have following properties:
-
-Required properties:
-------------------
-- pins: List of pins. Valid values of pins properties are:
- gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7.
-
-Optional properties:
--------------------
-Following are optional properties defined as pinmux DT binding document
-<pinctrl-bindings.txt>. Absence of properties will leave the configuration
-on default.
- function,
- drive-push-pull,
- drive-open-drain,
- bias-pull-up,
- bias-pull-down.
-
-Valid values for function properties are:
- gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in,
- reference-out
-
-Theres is also customised properties for the GPIO1, GPIO2 and GPIO3. These
-customised properties are required to configure FPS configuration parameters
-of these GPIOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more
-detail of Flexible Power Sequence (FPS).
-
-- maxim,active-fps-source: FPS source for the GPIOs to get
- enabled/disabled when system is in
- active state. Valid values are:
- - MAX77620_FPS_SRC_0,
- FPS source is FPS0.
- - MAX77620_FPS_SRC_1,
- FPS source is FPS1
- - MAX77620_FPS_SRC_2 and
- FPS source is FPS2
- - MAX77620_FPS_SRC_NONE.
- GPIO is not controlled
- by FPS events and it gets
- enabled/disabled by register
- access.
- Absence of this property will leave
- the FPS configuration register for that
- GPIO to default configuration.
-
-- maxim,active-fps-power-up-slot: Sequencing event slot number on which
- the GPIO get enabled when
- master FPS input event set to HIGH.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,active-fps-power-down-slot: Sequencing event slot number on which
- the GPIO get disabled when master
- FPS input event set to LOW.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,suspend-fps-source: This is same as property
- "maxim,active-fps-source" but value
- get configured when system enters in
- to suspend state.
-
-- maxim,suspend-fps-power-up-slot: This is same as property
- "maxim,active-fps-power-up-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
-
-- maxim,suspend-fps-power-down-slot: This is same as property
- "maxim,active-fps-power-down-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
- FPS2.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-...
-max77620@3c {
-
- pinctrl-names = "default";
- pinctrl-0 = <&spmic_default>;
-
- spmic_default: pinmux@0 {
- pin_gpio0 {
- pins = "gpio0";
- function = "gpio";
- };
-
- pin_gpio1 {
- pins = "gpio1";
- function = "fps-out";
- maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
- };
-
- pin_gpio2 {
- pins = "gpio2";
- function = "fps-out";
- maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
deleted file mode 100644
index 1c4bfe786736..000000000000
--- a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
+++ /dev/null
@@ -1,222 +0,0 @@
-Regulator DT binding for MAX77620 Power management IC from Maxim Semiconductor.
-
-Device has multiple DCDC(sd[0-3] and LDOs(ldo[0-8]). The input supply
-of these regulators are defined under parent device node.
-Details of regulator properties are defined as child node under
-sub-node "regulators" which is child node of device node.
-
-Please refer file <Documentation/devicetree/bindings/regulator/regulator.txt>
-for common regulator bindings used by client.
-
-Following are properties of parent node related to regulators.
-
-Optional properties:
--------------------
-The input supply of regulators are the optional properties on the
-parent device node. The input supply of these regulators are provided
-through following properties:
-in-sd0-supply: Input supply for SD0, INA-SD0 or INB-SD0 pins.
-in-sd1-supply: Input supply for SD1.
-in-sd2-supply: Input supply for SD2.
-in-sd3-supply: Input supply for SD3.
-in-ldo0-1-supply: Input supply for LDO0 and LDO1.
-in-ldo2-supply: Input supply for LDO2.
-in-ldo3-5-supply: Input supply for LDO3 and LDO5
-in-ldo4-6-supply: Input supply for LDO4 and LDO6.
-in-ldo7-8-supply: Input supply for LDO7 and LDO8.
-
-Optional sub nodes for regulators under "regulators" subnode:
-------------------------------------------------------------
-The subnodes name is the name of regulator and it must be one of:
- sd[0-3], ldo[0-8]
-
-Each sub-node should contain the constraints and initialization
-information for that regulator. The definition for each of these
-nodes is defined using the standard binding for regulators found at
-<Documentation/devicetree/bindings/regulator/regulator.txt>.
-
-Theres are also additional properties for SD/LDOs. These additional properties
-are required to configure FPS configuration parameters for SDs and LDOs.
-Please refer <devicetree/bindings/mfd/max77620.txt> for more detail of Flexible
-Power Sequence (FPS).
-Following are additional properties:
-
-- maxim,active-fps-source: FPS source for the regulators to get
- enabled/disabled when system is in
- active state. Valid values are:
- - MAX77620_FPS_SRC_0,
- FPS source is FPS0.
- - MAX77620_FPS_SRC_1,
- FPS source is FPS1
- - MAX77620_FPS_SRC_2 and
- FPS source is FPS2
- - MAX77620_FPS_SRC_NONE.
- Regulator is not controlled
- by FPS events and it gets
- enabled/disabled by register
- access.
- Absence of this property will leave
- the FPS configuration register for that
- regulator to default configuration.
-
-- maxim,active-fps-power-up-slot: Sequencing event slot number on which
- the regulator get enabled when
- master FPS input event set to HIGH.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,active-fps-power-down-slot: Sequencing event slot number on which
- the regulator get disabled when master
- FPS input event set to LOW.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,suspend-fps-source: This is same as property
- "maxim,active-fps-source" but value
- get configured when system enters in
- to suspend state.
-
-- maxim,suspend-fps-power-up-slot: This is same as property
- "maxim,active-fps-power-up-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
-
-- maxim,suspend-fps-power-down-slot: This is same as property
- "maxim,active-fps-power-down-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
- FPS2.
-- maxim,ramp-rate-setting: integer, ramp rate(uV/us) setting to be
- configured to the device.
- The platform may have different ramp
- rate than advertised ramp rate if it has
- design variation from Maxim's
- recommended. On this case, platform
- specific ramp rate is used for ramp time
- calculation and this property is used
- for device register configurations.
- The measured ramp rate of platform is
- provided by the regulator-ramp-delay
- as described in <devicetree/bindings/
- regulator/regulator.txt>.
- Maxim Max77620 supports following ramp
- delay:
- SD: 13.75mV/us, 27.5mV/us, 55mV/us
- LDOs: 5mV/us, 100mV/us
-
-Note: If the measured ramp delay is same as advertised ramp delay then it is not
-required to provide the ramp delay with property "maxim,ramp-rate-setting". The
-ramp rate can be provided by the regulator-ramp-delay which will be used for
-ramp time calculation for voltage change as well as for device configuration.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-...
-max77620@3c {
- in-ldo0-1-supply = <&max77620_sd2>;
- in-ldo7-8-supply = <&max77620_sd2>;
- regulators {
- sd0 {
- regulator-name = "vdd-core";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1400000>;
- regulator-boot-on;
- regulator-always-on;
- maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
- };
-
- sd1 {
- regulator-name = "vddio-ddr";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-boot-on;
- maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
- };
-
- sd2 {
- regulator-name = "vdd-pre-reg";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <1350000>;
- };
-
- sd3 {
- regulator-name = "vdd-1v8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo0 {
- regulator-name = "avdd-sys";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo1 {
- regulator-name = "vdd-pex";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- };
-
- ldo2 {
- regulator-name = "vddio-sdmmc3";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo3 {
- regulator-name = "vdd-cam-hv";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo4 {
- regulator-name = "vdd-rtc";
- regulator-min-microvolt = <1250000>;
- regulator-max-microvolt = <1250000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo5 {
- regulator-name = "avdd-ts-hv";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
-
- ldo6 {
- regulator-name = "vdd-ts";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo7 {
- regulator-name = "vdd-gen-pll-edp";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo8 {
- regulator-name = "vdd-hdmi-dp";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt b/Documentation/devicetree/bindings/thermal/max77620_thermal.txt
deleted file mode 100644
index 323a3b3822aa..000000000000
--- a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Thermal driver for MAX77620 Power management IC from Maxim Semiconductor.
-
-Maxim Semiconductor MAX77620 supports alarm interrupts when its
-die temperature crosses 120C and 140C. These threshold temperatures
-are not configurable. Device does not provide the real temperature
-of die other than just indicating whether temperature is above or
-below threshold level.
-
-Required properties:
--------------------
-#thermal-sensor-cells: Please refer <devicetree/bindings/thermal/thermal.txt>
- for more details.
- The value must be 0.
-
-For more details, please refer generic thermal DT binding document
-<devicetree/bindings/thermal/thermal.txt>.
-
-Please refer <devicetree/bindings/mfd/max77620.txt> for mfd DT binding
-document for the MAX77620.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-#include <dt-bindings/thermal/thermal.h>
-...
-
-i2c@7000d000 {
- spmic: max77620@3c {
- compatible = "maxim,max77620";
- :::::
- #thermal-sensor-cells = <0>;
- :::
- };
-};
-
-cool_dev: cool-dev {
- compatible = "cooling-dev";
- #cooling-cells = <2>;
-};
-
-thermal-zones {
- PMIC-Die {
- polling-delay = <0>;
- polling-delay-passive = <0>;
- thermal-sensors = <&spmic>;
-
- trips {
- pmic_die_warn_temp_thresh: hot-die {
- temperature = <120000>;
- type = "hot";
- hysteresis = <0>;
- };
-
- pmic_die_cirt_temp_thresh: cirtical-die {
- temperature = <140000>;
- type = "critical";
- hysteresis = <0>;
- };
- };
-
- cooling-maps {
- map0 {
- trip = <&pmic_die_warn_temp_thresh>;
- cooling-device = <&cool_dev THERMAL_NO_LIMIT
- THERMAL_NO_LIMIT>;
- contribution = <100>;
- };
- };
- };
-};
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (23 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 24/38] dt-bindings: mfd: max77620: " Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-17 4:24 ` Dmitry Osipenko
2020-06-12 14:18 ` [PATCH 26/38] dt-bindings: pci: iommu: " Thierry Reding
` (12 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the NVIDIA Tegra GPIO controller device tree bindings from
free-form text format to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/gpio/nvidia,tegra20-gpio.txt | 40 -------
.../bindings/gpio/nvidia,tegra20-gpio.yaml | 111 ++++++++++++++++++
2 files changed, 111 insertions(+), 40 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt
create mode 100644 Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt
deleted file mode 100644
index 023c9526e5f8..000000000000
--- a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-NVIDIA Tegra GPIO controller
-
-Required properties:
-- compatible : "nvidia,tegra<chip>-gpio"
-- reg : Physical base address and length of the controller's registers.
-- interrupts : The interrupt outputs from the controller. For Tegra20,
- there should be 7 interrupts specified, and for Tegra30, there should
- be 8 interrupts specified.
-- #gpio-cells : Should be two. The first cell is the pin number and the
- second cell is used to specify optional parameters:
- - bit 0 specifies polarity (0 for normal, 1 for inverted)
-- gpio-controller : Marks the device node as a GPIO controller.
-- #interrupt-cells : Should be 2.
- The first cell is the GPIO number.
- The second cell is used to specify flags:
- bits[3:0] trigger type and level flags:
- 1 = low-to-high edge triggered.
- 2 = high-to-low edge triggered.
- 4 = active high level-sensitive.
- 8 = active low level-sensitive.
- Valid combinations are 1, 2, 3, 4, 8.
-- interrupt-controller : Marks the device node as an interrupt controller.
-
-Example:
-
-gpio: gpio@6000d000 {
- compatible = "nvidia,tegra20-gpio";
- reg = < 0x6000d000 0x1000 >;
- interrupts = < 0 32 0x04
- 0 33 0x04
- 0 34 0x04
- 0 35 0x04
- 0 55 0x04
- 0 87 0x04
- 0 89 0x04 >;
- #gpio-cells = <2>;
- gpio-controller;
- #interrupt-cells = <2>;
- interrupt-controller;
-};
diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
new file mode 100644
index 000000000000..b2debdb0caff
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/nvidia,tegra20-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra GPIO Controller (Tegra20 - Tegra210)
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+properties:
+ compatible:
+ oneOf:
+ - const: nvidia,tegra20-gpio
+ - const: nvidia,tegra30-gpio
+ - items:
+ - enum:
+ - nvidia,tegra114-gpio
+ - nvidia,tegra124-gpio
+ - nvidia,tegra210-gpio
+ - const: nvidia,tegra30-gpio
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: The interrupt outputs from the controller. For Tegra20,
+ there should be 7 interrupts specified, and for Tegra30, there should
+ be 8 interrupts specified.
+
+ "#gpio-cells":
+ description: The first cell is the pin number and the second cell is used
+ to specify the GPIO polarity (0 = active high, 1 = active low).
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ const: 2
+
+ gpio-controller:
+ description: Marks the device node as a GPIO controller.
+ type: boolean
+
+ "#interrupt-cells":
+ description: |
+ Should be 2. The first cell is the GPIO number. The second cell is
+ used to specify flags:
+
+ bits[3:0] trigger type and level flags:
+ 1 = low-to-high edge triggered.
+ 2 = high-to-low edge triggered.
+ 4 = active high level-sensitive.
+ 8 = active low level-sensitive.
+
+ Valid combinations are 1, 2, 3, 4, 8.
+ const: 2
+
+ interrupt-controller:
+ description: Marks the device node as an interrupt controller.
+
+patternProperties:
+ # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
+ "^gpios(-[a-zA-Z0-9-]+)?$":
+ type: object
+ required:
+ - gpio-hog
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra30-gpio
+ then:
+ properties:
+ interrupts:
+ minItems: 8
+ maxItems: 8
+ else:
+ properties:
+ interrupts:
+ minItems: 7
+ maxItems: 7
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#gpio-cells"
+ - gpio-controller
+ - "#interrupt-cells"
+ - interrupt-controller
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ gpio: gpio@6000d000 {
+ compatible = "nvidia,tegra20-gpio";
+ reg = <0x6000d000 0x1000>;
+ interrupts = <0 32 0x04>,
+ <0 33 0x04>,
+ <0 34 0x04>,
+ <0 35 0x04>,
+ <0 55 0x04>,
+ <0 87 0x04>,
+ <0 89 0x04>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
2020-06-12 14:18 ` [PATCH 25/38] dt-bindings: gpio: tegra: " Thierry Reding
@ 2020-06-17 4:24 ` Dmitry Osipenko
2020-06-17 14:17 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Dmitry Osipenko @ 2020-06-17 4:24 UTC (permalink / raw)
To: Thierry Reding, Rob Herring; +Cc: devicetree, linux-tegra
12.06.2020 17:18, Thierry Reding пишет:
...
> +patternProperties:
> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
> + "^gpios(-[a-zA-Z0-9-]+)?$":
> + type: object
> + required:
> + - gpio-hog
There are two problems here:
1. This naming limitation didn't exist before this patch, so it's not a
part of the conversion.
2. GPIO core uses the node's name for the hog's name. Hence by imposing
the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
which doesn't make much sense to me.
Please explain the rationale of this change.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
2020-06-17 4:24 ` Dmitry Osipenko
@ 2020-06-17 14:17 ` Thierry Reding
2020-06-17 14:24 ` Dmitry Osipenko
0 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-17 14:17 UTC (permalink / raw)
To: Dmitry Osipenko; +Cc: Rob Herring, devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]
On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
> 12.06.2020 17:18, Thierry Reding пишет:
> ...
> > +patternProperties:
> > + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
> > + "^gpios(-[a-zA-Z0-9-]+)?$":
> > + type: object
> > + required:
> > + - gpio-hog
>
> There are two problems here:
>
> 1. This naming limitation didn't exist before this patch, so it's not a
> part of the conversion.
>
> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
> which doesn't make much sense to me.
>
> Please explain the rationale of this change.
We could probably do without this if we didn't enforce additional or
unevaluated properties. Because if we don't match on a pattern here then
all of those GPIO hog nodes would show up as "extra" properties and they
are currently not allowed. If we do allow them, then we can drop this,
but we then have no way to fail validation for whatever else somebody
might want to put into these device tree nodes.
That said, I think additionalProperties can be a schema in itself, so
maybe there's a way to only allow additional properties if they are of
type object and have a gpio-hog property. I'll look into that.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
2020-06-17 14:17 ` Thierry Reding
@ 2020-06-17 14:24 ` Dmitry Osipenko
2020-06-17 14:33 ` Dmitry Osipenko
0 siblings, 1 reply; 76+ messages in thread
From: Dmitry Osipenko @ 2020-06-17 14:24 UTC (permalink / raw)
To: Thierry Reding, Rob Herring; +Cc: devicetree, linux-tegra
17.06.2020 17:17, Thierry Reding пишет:
> On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
>> 12.06.2020 17:18, Thierry Reding пишет:
>> ...
>>> +patternProperties:
>>> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
>>> + "^gpios(-[a-zA-Z0-9-]+)?$":
>>> + type: object
>>> + required:
>>> + - gpio-hog
>>
>> There are two problems here:
>>
>> 1. This naming limitation didn't exist before this patch, so it's not a
>> part of the conversion.
>>
>> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
>> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
>> which doesn't make much sense to me.
>>
>> Please explain the rationale of this change.
>
> We could probably do without this if we didn't enforce additional or
> unevaluated properties. Because if we don't match on a pattern here then
> all of those GPIO hog nodes would show up as "extra" properties and they
> are currently not allowed. If we do allow them, then we can drop this,
> but we then have no way to fail validation for whatever else somebody
> might want to put into these device tree nodes.
>
> That said, I think additionalProperties can be a schema in itself, so
> maybe there's a way to only allow additional properties if they are of
> type object and have a gpio-hog property. I'll look into that.
Isn't it possible to validate the additional properties by checking what
properties they have?
For example, if sub-node has a gpio-hog property then this sub-node is
okay, otherwise fail.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
2020-06-17 14:24 ` Dmitry Osipenko
@ 2020-06-17 14:33 ` Dmitry Osipenko
2020-06-17 16:50 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Dmitry Osipenko @ 2020-06-17 14:33 UTC (permalink / raw)
To: Thierry Reding, Rob Herring; +Cc: devicetree, linux-tegra
17.06.2020 17:24, Dmitry Osipenko пишет:
> 17.06.2020 17:17, Thierry Reding пишет:
>> On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
>>> 12.06.2020 17:18, Thierry Reding пишет:
>>> ...
>>>> +patternProperties:
>>>> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
>>>> + "^gpios(-[a-zA-Z0-9-]+)?$":
>>>> + type: object
>>>> + required:
>>>> + - gpio-hog
>>>
>>> There are two problems here:
>>>
>>> 1. This naming limitation didn't exist before this patch, so it's not a
>>> part of the conversion.
>>>
>>> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
>>> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
>>> which doesn't make much sense to me.
>>>
>>> Please explain the rationale of this change.
>>
>> We could probably do without this if we didn't enforce additional or
>> unevaluated properties. Because if we don't match on a pattern here then
>> all of those GPIO hog nodes would show up as "extra" properties and they
>> are currently not allowed. If we do allow them, then we can drop this,
>> but we then have no way to fail validation for whatever else somebody
>> might want to put into these device tree nodes.
>>
>> That said, I think additionalProperties can be a schema in itself, so
>> maybe there's a way to only allow additional properties if they are of
>> type object and have a gpio-hog property. I'll look into that.
>
> Isn't it possible to validate the additional properties by checking what
> properties they have?
>
> For example, if sub-node has a gpio-hog property then this sub-node is
> okay, otherwise fail.
>
Ah, I haven't finished reading yours last sentence before started to
type :) Yes, it will be nice if we could avoid the naming limitation, or
at least change it to something like xxx-hog.
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
2020-06-17 14:33 ` Dmitry Osipenko
@ 2020-06-17 16:50 ` Thierry Reding
2020-06-18 15:07 ` Dmitry Osipenko
0 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-17 16:50 UTC (permalink / raw)
To: Dmitry Osipenko; +Cc: Rob Herring, devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 4445 bytes --]
On Wed, Jun 17, 2020 at 05:33:00PM +0300, Dmitry Osipenko wrote:
> 17.06.2020 17:24, Dmitry Osipenko пишет:
> > 17.06.2020 17:17, Thierry Reding пишет:
> >> On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
> >>> 12.06.2020 17:18, Thierry Reding пишет:
> >>> ...
> >>>> +patternProperties:
> >>>> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
> >>>> + "^gpios(-[a-zA-Z0-9-]+)?$":
> >>>> + type: object
> >>>> + required:
> >>>> + - gpio-hog
> >>>
> >>> There are two problems here:
> >>>
> >>> 1. This naming limitation didn't exist before this patch, so it's not a
> >>> part of the conversion.
> >>>
> >>> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
> >>> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
> >>> which doesn't make much sense to me.
> >>>
> >>> Please explain the rationale of this change.
> >>
> >> We could probably do without this if we didn't enforce additional or
> >> unevaluated properties. Because if we don't match on a pattern here then
> >> all of those GPIO hog nodes would show up as "extra" properties and they
> >> are currently not allowed. If we do allow them, then we can drop this,
> >> but we then have no way to fail validation for whatever else somebody
> >> might want to put into these device tree nodes.
> >>
> >> That said, I think additionalProperties can be a schema in itself, so
> >> maybe there's a way to only allow additional properties if they are of
> >> type object and have a gpio-hog property. I'll look into that.
> >
> > Isn't it possible to validate the additional properties by checking what
> > properties they have?
> >
> > For example, if sub-node has a gpio-hog property then this sub-node is
> > okay, otherwise fail.
> >
>
> Ah, I haven't finished reading yours last sentence before started to
> type :) Yes, it will be nice if we could avoid the naming limitation, or
> at least change it to something like xxx-hog.
So according to the json-schema specification, both additionalProperties
and unevaluatedProperties must be a valid JSON schema, which means they
can be objects rather than just booleans. Unfortunately, dt-schema tools
don't allow these to be objects, so the below currently fails with these
tools at the moment.
I can make it work with the following patch against dt-schema.git:
--- >8 ---
diff --git a/meta-schemas/keywords.yaml b/meta-schemas/keywords.yaml
index ed543235d7e7..aa88f726ea3b 100644
--- a/meta-schemas/keywords.yaml
+++ b/meta-schemas/keywords.yaml
@@ -79,7 +79,11 @@ properties:
additionalItems:
type: boolean
additionalProperties:
- type: boolean
+ oneOf:
+ - type: object
+ allOf:
+ - $ref: "#/definitions/sub-schemas"
+ - type: boolean
allOf:
items:
$ref: "#/definitions/sub-schemas"
@@ -140,7 +144,11 @@ properties:
type: true
typeSize: true
unevaluatedProperties:
- type: boolean
+ oneOf:
+ - type: object
+ allOf:
+ - $ref: "#/definitions/sub-schemas"
+ - type: boolean
uniqueItems:
type: boolean
--- >8 ---
With that applied, I can make validation of gpio-hog nodes work without
requiring the names to change, which incidentally will allow me to drop
one of the fixup patches from the ARM/arm64 DTS series.
Here's a hunk that applies on top of this patch and makes this work.
I'll squash it in for the next version.
--- >8 ---
diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
index b2debdb0caff..3f8a9c988305 100644
--- a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
@@ -57,13 +57,6 @@ properties:
interrupt-controller:
description: Marks the device node as an interrupt controller.
-patternProperties:
- # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
- "^gpios(-[a-zA-Z0-9-]+)?$":
- type: object
- required:
- - gpio-hog
-
allOf:
- if:
properties:
@@ -90,7 +83,10 @@ required:
- "#interrupt-cells"
- interrupt-controller
-unevaluatedProperties: false
+unevaluatedProperties:
+ type: object
+ required:
+ - gpio-hog
examples:
- |
--- >8 ---
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 25/38] dt-bindings: gpio: tegra: Convert to json-schema
2020-06-17 16:50 ` Thierry Reding
@ 2020-06-18 15:07 ` Dmitry Osipenko
0 siblings, 0 replies; 76+ messages in thread
From: Dmitry Osipenko @ 2020-06-18 15:07 UTC (permalink / raw)
To: Thierry Reding; +Cc: Rob Herring, devicetree, linux-tegra
17.06.2020 19:50, Thierry Reding пишет:
> On Wed, Jun 17, 2020 at 05:33:00PM +0300, Dmitry Osipenko wrote:
>> 17.06.2020 17:24, Dmitry Osipenko пишет:
>>> 17.06.2020 17:17, Thierry Reding пишет:
>>>> On Wed, Jun 17, 2020 at 07:24:16AM +0300, Dmitry Osipenko wrote:
>>>>> 12.06.2020 17:18, Thierry Reding пишет:
>>>>> ...
>>>>>> +patternProperties:
>>>>>> + # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
>>>>>> + "^gpios(-[a-zA-Z0-9-]+)?$":
>>>>>> + type: object
>>>>>> + required:
>>>>>> + - gpio-hog
>>>>>
>>>>> There are two problems here:
>>>>>
>>>>> 1. This naming limitation didn't exist before this patch, so it's not a
>>>>> part of the conversion.
>>>>>
>>>>> 2. GPIO core uses the node's name for the hog's name. Hence by imposing
>>>>> the "gpios-" prefix, you're forcing all hogs to be named as gpios-xxx,
>>>>> which doesn't make much sense to me.
>>>>>
>>>>> Please explain the rationale of this change.
>>>>
>>>> We could probably do without this if we didn't enforce additional or
>>>> unevaluated properties. Because if we don't match on a pattern here then
>>>> all of those GPIO hog nodes would show up as "extra" properties and they
>>>> are currently not allowed. If we do allow them, then we can drop this,
>>>> but we then have no way to fail validation for whatever else somebody
>>>> might want to put into these device tree nodes.
>>>>
>>>> That said, I think additionalProperties can be a schema in itself, so
>>>> maybe there's a way to only allow additional properties if they are of
>>>> type object and have a gpio-hog property. I'll look into that.
>>>
>>> Isn't it possible to validate the additional properties by checking what
>>> properties they have?
>>>
>>> For example, if sub-node has a gpio-hog property then this sub-node is
>>> okay, otherwise fail.
>>>
>>
>> Ah, I haven't finished reading yours last sentence before started to
>> type :) Yes, it will be nice if we could avoid the naming limitation, or
>> at least change it to something like xxx-hog.
>
> So according to the json-schema specification, both additionalProperties
> and unevaluatedProperties must be a valid JSON schema, which means they
> can be objects rather than just booleans. Unfortunately, dt-schema tools
> don't allow these to be objects, so the below currently fails with these
> tools at the moment.
>
> I can make it work with the following patch against dt-schema.git:
>
> --- >8 ---
> diff --git a/meta-schemas/keywords.yaml b/meta-schemas/keywords.yaml
> index ed543235d7e7..aa88f726ea3b 100644
> --- a/meta-schemas/keywords.yaml
> +++ b/meta-schemas/keywords.yaml
> @@ -79,7 +79,11 @@ properties:
> additionalItems:
> type: boolean
> additionalProperties:
> - type: boolean
> + oneOf:
> + - type: object
> + allOf:
> + - $ref: "#/definitions/sub-schemas"
> + - type: boolean
> allOf:
> items:
> $ref: "#/definitions/sub-schemas"
> @@ -140,7 +144,11 @@ properties:
> type: true
> typeSize: true
> unevaluatedProperties:
> - type: boolean
> + oneOf:
> + - type: object
> + allOf:
> + - $ref: "#/definitions/sub-schemas"
> + - type: boolean
> uniqueItems:
> type: boolean
>
> --- >8 ---
>
> With that applied, I can make validation of gpio-hog nodes work without
> requiring the names to change, which incidentally will allow me to drop
> one of the fixup patches from the ARM/arm64 DTS series.
>
> Here's a hunk that applies on top of this patch and makes this work.
> I'll squash it in for the next version.
>
> --- >8 ---
> diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
> index b2debdb0caff..3f8a9c988305 100644
> --- a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml
> @@ -57,13 +57,6 @@ properties:
> interrupt-controller:
> description: Marks the device node as an interrupt controller.
>
> -patternProperties:
> - # GPIO hogs; /schemas/gpio/gpio-hog.yaml will match
> - "^gpios(-[a-zA-Z0-9-]+)?$":
> - type: object
> - required:
> - - gpio-hog
> -
> allOf:
> - if:
> properties:
> @@ -90,7 +83,10 @@ required:
> - "#interrupt-cells"
> - interrupt-controller
>
> -unevaluatedProperties: false
> +unevaluatedProperties:
> + type: object
> + required:
> + - gpio-hog
>
> examples:
> - |
> --- >8 ---
Thank you for figuring this out! I see that the dt-schema tool is
already updated in the git, very nice!
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 26/38] dt-bindings: pci: iommu: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (24 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 25/38] dt-bindings: gpio: tegra: " Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-18 2:34 ` Rob Herring
2020-06-12 14:18 ` [PATCH 27/38] dt-bindings: tegra: Add missing compatible strings Thierry Reding
` (11 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the PCI IOMMU device tree bindings from free-form text format to
json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/pci/pci-iommu.txt | 171 ------------------
.../devicetree/bindings/pci/pci-iommu.yaml | 168 +++++++++++++++++
2 files changed, 168 insertions(+), 171 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.yaml
diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt b/Documentation/devicetree/bindings/pci/pci-iommu.txt
deleted file mode 100644
index 0def586fdcdf..000000000000
--- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-This document describes the generic device tree binding for describing the
-relationship between PCI(e) devices and IOMMU(s).
-
-Each PCI(e) device under a root complex is uniquely identified by its Requester
-ID (AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
-Function number.
-
-For the purpose of this document, when treated as a numeric value, a RID is
-formatted such that:
-
-* Bits [15:8] are the Bus number.
-* Bits [7:3] are the Device number.
-* Bits [2:0] are the Function number.
-* Any other bits required for padding must be zero.
-
-IOMMUs may distinguish PCI devices through sideband data derived from the
-Requester ID. While a given PCI device can only master through one IOMMU, a
-root complex may split masters across a set of IOMMUs (e.g. with one IOMMU per
-bus).
-
-The generic 'iommus' property is insufficient to describe this relationship,
-and a mechanism is required to map from a PCI device to its IOMMU and sideband
-data.
-
-For generic IOMMU bindings, see
-Documentation/devicetree/bindings/iommu/iommu.txt.
-
-
-PCI root complex
-================
-
-Optional properties
--------------------
-
-- iommu-map: Maps a Requester ID to an IOMMU and associated IOMMU specifier
- data.
-
- The property is an arbitrary number of tuples of
- (rid-base,iommu,iommu-base,length).
-
- Any RID r in the interval [rid-base, rid-base + length) is associated with
- the listed IOMMU, with the IOMMU specifier (r - rid-base + iommu-base).
-
-- iommu-map-mask: A mask to be applied to each Requester ID prior to being
- mapped to an IOMMU specifier per the iommu-map property.
-
-
-Example (1)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- iommu: iommu@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the IOMMU is the RID,
- * identity-mapped.
- */
- iommu-map = <0x0 &iommu 0x0 0x10000>;
- };
-};
-
-
-Example (2)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- iommu: iommu@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the IOMMU is the RID with the
- * function bits masked out.
- */
- iommu-map = <0x0 &iommu 0x0 0x10000>;
- iommu-map-mask = <0xfff8>;
- };
-};
-
-
-Example (3)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- iommu: iommu@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * The sideband data provided to the IOMMU is the RID,
- * but the high bits of the bus number are flipped.
- */
- iommu-map = <0x0000 &iommu 0x8000 0x8000>,
- <0x8000 &iommu 0x0000 0x8000>;
- };
-};
-
-
-Example (4)
-===========
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
-
- iommu_a: iommu@a {
- reg = <0xa 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- iommu_b: iommu@b {
- reg = <0xb 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- iommu_c: iommu@c {
- reg = <0xc 0x1>;
- compatible = "vendor,some-iommu";
- #iommu-cells = <1>;
- };
-
- pci: pci@f {
- reg = <0xf 0x1>;
- compatible = "vendor,pcie-root-complex";
- device_type = "pci";
-
- /*
- * Devices with bus number 0-127 are mastered via IOMMU
- * a, with sideband data being RID[14:0].
- * Devices with bus number 128-255 are mastered via
- * IOMMU b, with sideband data being RID[14:0].
- * No devices master via IOMMU c.
- */
- iommu-map = <0x0000 &iommu_a 0x0000 0x8000>,
- <0x8000 &iommu_b 0x0000 0x8000>;
- };
-};
diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.yaml b/Documentation/devicetree/bindings/pci/pci-iommu.yaml
new file mode 100644
index 000000000000..8aaa8e657559
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-iommu.yaml
@@ -0,0 +1,168 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/pci-iommu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PCI IOMMU bindings
+
+maintainers:
+ - Rob Herring <robh+dt@kernel.org>
+
+description: |
+ This document describes the generic device tree binding for describing the
+ relationship between PCI(e) devices and IOMMU(s).
+
+ Each PCI(e) device under a root complex is uniquely identified by its
+ Requester ID (AKA RID). A Requester ID is a triplet of a Bus number, Device
+ number, and Function number.
+
+ For the purpose of this document, when treated as a numeric value, a RID is
+ formatted such that:
+
+ * Bits [15:8] are the Bus number.
+ * Bits [7:3] are the Device number.
+ * Bits [2:0] are the Function number.
+ * Any other bits required for padding must be zero.
+
+ IOMMUs may distinguish PCI devices through sideband data derived from the
+ Requester ID. While a given PCI device can only master through one IOMMU, a
+ root complex may split masters across a set of IOMMUs (e.g. with one IOMMU
+ per bus).
+
+ The generic 'iommus' property is insufficient to describe this relationship,
+ and a mechanism is required to map from a PCI device to its IOMMU and
+ sideband data.
+
+ For generic IOMMU bindings, see
+ Documentation/devicetree/bindings/iommu/iommu.txt.
+
+properties:
+ iommu-map:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+ description: |
+ Maps a Requester ID to an IOMMU and associated IOMMU specifier data.
+
+ The property is an arbitrary number of tuples of (rid-base, iommu,
+ iommu-base, length).
+
+ Any RID r in the interval [rid-base, rid-base + length) is associated
+ with the listed IOMMU, with the IOMMU specifier (r - rid-base +
+ iommu-base).
+
+ iommu-map-mask:
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ description:
+ A mask to be applied to each Requester ID prior to being mapped to an
+ IOMMU specifier per the iommu-map property.
+
+examples:
+ - |
+ iommu0: iommu@a {
+ reg = <0xa 0x1>;
+ compatible = "vendor,some-iommu";
+ #iommu-cells = <1>;
+ };
+
+ pci@f {
+ reg = <0xf 0x1>;
+ compatible = "vendor,pcie-root-complex";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
+
+ /*
+ * The sideband data provided to the IOMMU is the RID,
+ * identity-mapped.
+ */
+ iommu-map = <0x0 &iommu0 0x0 0x10000>;
+ };
+
+ - |
+ iommu1: iommu@a {
+ reg = <0xa 0x1>;
+ compatible = "vendor,some-iommu";
+ #iommu-cells = <1>;
+ };
+
+ pci@f {
+ reg = <0xf 0x1>;
+ compatible = "vendor,pcie-root-complex";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
+
+ /*
+ * The sideband data provided to the IOMMU is the RID with the
+ * function bits masked out.
+ */
+ iommu-map = <0x0 &iommu 0x0 0x10000>;
+ iommu-map-mask = <0xfff8>;
+ };
+
+ - |
+ iommu2: iommu@a {
+ reg = <0xa 0x1>;
+ compatible = "vendor,some-iommu";
+ #iommu-cells = <1>;
+ };
+
+ pci@f {
+ reg = <0xf 0x1>;
+ compatible = "vendor,pcie-root-complex";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
+
+ /*
+ * The sideband data provided to the IOMMU is the RID,
+ * but the high bits of the bus number are flipped.
+ */
+ iommu-map = <0x0000 &iommu2 0x8000 0x8000>,
+ <0x8000 &iommu2 0x0000 0x8000>;
+ };
+
+ - |
+ iommu_a: iommu@a {
+ reg = <0xa 0x1>;
+ compatible = "vendor,some-iommu";
+ #iommu-cells = <1>;
+ };
+
+ iommu_b: iommu@b {
+ reg = <0xb 0x1>;
+ compatible = "vendor,some-iommu";
+ #iommu-cells = <1>;
+ };
+
+ iommu_c: iommu@c {
+ reg = <0xc 0x1>;
+ compatible = "vendor,some-iommu";
+ #iommu-cells = <1>;
+ };
+
+ pci@f {
+ reg = <0xf 0x1>;
+ compatible = "vendor,pcie-root-complex";
+ device_type = "pci";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
+
+ /*
+ * Devices with bus number 0-127 are mastered via IOMMU
+ * a, with sideband data being RID[14:0].
+ * Devices with bus number 128-255 are mastered via
+ * IOMMU b, with sideband data being RID[14:0].
+ * No devices master via IOMMU c.
+ */
+ iommu-map = <0x0000 &iommu_a 0x0000 0x8000>,
+ <0x8000 &iommu_b 0x0000 0x8000>;
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 26/38] dt-bindings: pci: iommu: Convert to json-schema
2020-06-12 14:18 ` [PATCH 26/38] dt-bindings: pci: iommu: " Thierry Reding
@ 2020-06-18 2:34 ` Rob Herring
2020-06-18 14:18 ` Thierry Reding
2020-06-19 6:45 ` Thierry Reding
0 siblings, 2 replies; 76+ messages in thread
From: Rob Herring @ 2020-06-18 2:34 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:18:51PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the PCI IOMMU device tree bindings from free-form text format to
> json-schema.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../devicetree/bindings/pci/pci-iommu.txt | 171 ------------------
> .../devicetree/bindings/pci/pci-iommu.yaml | 168 +++++++++++++++++
> 2 files changed, 168 insertions(+), 171 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
> create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.yaml
This needs to come before you use it.
> diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.yaml b/Documentation/devicetree/bindings/pci/pci-iommu.yaml
> new file mode 100644
> index 000000000000..8aaa8e657559
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pci-iommu.yaml
> @@ -0,0 +1,168 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/pci-iommu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PCI IOMMU bindings
> +
> +maintainers:
> + - Rob Herring <robh+dt@kernel.org>
> +
> +description: |
> + This document describes the generic device tree binding for describing the
> + relationship between PCI(e) devices and IOMMU(s).
> +
> + Each PCI(e) device under a root complex is uniquely identified by its
> + Requester ID (AKA RID). A Requester ID is a triplet of a Bus number, Device
> + number, and Function number.
> +
> + For the purpose of this document, when treated as a numeric value, a RID is
> + formatted such that:
> +
> + * Bits [15:8] are the Bus number.
> + * Bits [7:3] are the Device number.
> + * Bits [2:0] are the Function number.
> + * Any other bits required for padding must be zero.
> +
> + IOMMUs may distinguish PCI devices through sideband data derived from the
> + Requester ID. While a given PCI device can only master through one IOMMU, a
> + root complex may split masters across a set of IOMMUs (e.g. with one IOMMU
> + per bus).
> +
> + The generic 'iommus' property is insufficient to describe this relationship,
> + and a mechanism is required to map from a PCI device to its IOMMU and
> + sideband data.
> +
> + For generic IOMMU bindings, see
> + Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +properties:
> + iommu-map:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> + description: |
> + Maps a Requester ID to an IOMMU and associated IOMMU specifier data.
> +
> + The property is an arbitrary number of tuples of (rid-base, iommu,
> + iommu-base, length).
> +
> + Any RID r in the interval [rid-base, rid-base + length) is associated
> + with the listed IOMMU, with the IOMMU specifier (r - rid-base +
> + iommu-base).
> +
> + iommu-map-mask:
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + description:
> + A mask to be applied to each Requester ID prior to being mapped to an
> + IOMMU specifier per the iommu-map property.
> +
> +examples:
> + - |
> + iommu0: iommu@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
> +
> + /*
> + * The sideband data provided to the IOMMU is the RID,
> + * identity-mapped.
> + */
> + iommu-map = <0x0 &iommu0 0x0 0x10000>;
> + };
> +
> + - |
> + iommu1: iommu@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
> +
> + /*
> + * The sideband data provided to the IOMMU is the RID with the
> + * function bits masked out.
> + */
> + iommu-map = <0x0 &iommu 0x0 0x10000>;
> + iommu-map-mask = <0xfff8>;
> + };
> +
> + - |
> + iommu2: iommu@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
> +
> + /*
> + * The sideband data provided to the IOMMU is the RID,
> + * but the high bits of the bus number are flipped.
> + */
> + iommu-map = <0x0000 &iommu2 0x8000 0x8000>,
> + <0x8000 &iommu2 0x0000 0x8000>;
> + };
> +
> + - |
> + iommu_a: iommu@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + iommu_b: iommu@b {
> + reg = <0xb 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + iommu_c: iommu@c {
> + reg = <0xc 0x1>;
> + compatible = "vendor,some-iommu";
> + #iommu-cells = <1>;
> + };
> +
> + pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x02000000 0 0x00000000 0x00000000 0 0x00000000>;
> +
> + /*
> + * Devices with bus number 0-127 are mastered via IOMMU
> + * a, with sideband data being RID[14:0].
> + * Devices with bus number 128-255 are mastered via
> + * IOMMU b, with sideband data being RID[14:0].
> + * No devices master via IOMMU c.
> + */
> + iommu-map = <0x0000 &iommu_a 0x0000 0x8000>,
> + <0x8000 &iommu_b 0x0000 0x8000>;
> + };
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread* Re: [PATCH 26/38] dt-bindings: pci: iommu: Convert to json-schema
2020-06-18 2:34 ` Rob Herring
@ 2020-06-18 14:18 ` Thierry Reding
2020-06-19 6:45 ` Thierry Reding
1 sibling, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-18 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
On Wed, Jun 17, 2020 at 08:34:57PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:18:51PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Convert the PCI IOMMU device tree bindings from free-form text format to
> > json-schema.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > .../devicetree/bindings/pci/pci-iommu.txt | 171 ------------------
> > .../devicetree/bindings/pci/pci-iommu.yaml | 168 +++++++++++++++++
> > 2 files changed, 168 insertions(+), 171 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
> > create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.yaml
>
> This needs to come before you use it.
Of course, will rearrange the patches.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 26/38] dt-bindings: pci: iommu: Convert to json-schema
2020-06-18 2:34 ` Rob Herring
2020-06-18 14:18 ` Thierry Reding
@ 2020-06-19 6:45 ` Thierry Reding
1 sibling, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-19 6:45 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
On Wed, Jun 17, 2020 at 08:34:57PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:18:51PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Convert the PCI IOMMU device tree bindings from free-form text format to
> > json-schema.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > .../devicetree/bindings/pci/pci-iommu.txt | 171 ------------------
> > .../devicetree/bindings/pci/pci-iommu.yaml | 168 +++++++++++++++++
> > 2 files changed, 168 insertions(+), 171 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt
> > create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.yaml
>
> This needs to come before you use it.
Good point, I'll reorder it.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 27/38] dt-bindings: tegra: Add missing compatible strings
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (25 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 26/38] dt-bindings: pci: iommu: " Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 28/38] dt-bindings: phy: tegra-xusb: Convert to json-schema Thierry Reding
` (10 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The Nyan Blaze and Nyan Big, as well as Jetson Nano (P3450-0000), Darcy
(P2894-0050-A08) and Pixel C (Smaug) were never mentioned. Add them.
While at it, also fix a typo in the compatible string for Apalis Tegra30
v1.1 evaluation board.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/arm/tegra.yaml | 46 ++++++++++++++++++-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
index 60b38eb5c61a..043ca543be8c 100644
--- a/Documentation/devicetree/bindings/arm/tegra.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra.yaml
@@ -49,7 +49,7 @@ properties:
- const: toradex,apalis_t30
- const: nvidia,tegra30
- items:
- - const: toradex,apalis_t30-eval-v1.1
+ - const: toradex,apalis_t30-v1.1-eval
- const: toradex,apalis_t30-eval
- const: toradex,apalis_t30-v1.1
- const: toradex,apalis_t30
@@ -80,6 +80,33 @@ properties:
- const: toradex,apalis-tk1-v1.2
- const: toradex,apalis-tk1
- const: nvidia,tegra124
+ - items:
+ - const: google,nyan-big-rev7
+ - const: google,nyan-big-rev6
+ - const: google,nyan-big-rev5
+ - const: google,nyan-big-rev4
+ - const: google,nyan-big-rev3
+ - const: google,nyan-big-rev2
+ - const: google,nyan-big-rev1
+ - const: google,nyan-big-rev0
+ - const: google,nyan-big
+ - const: google,nyan
+ - const: nvidia,tegra124
+ - items:
+ - const: google,nyan-blaze-rev10
+ - const: google,nyan-blaze-rev9
+ - const: google,nyan-blaze-rev8
+ - const: google,nyan-blaze-rev7
+ - const: google,nyan-blaze-rev6
+ - const: google,nyan-blaze-rev5
+ - const: google,nyan-blaze-rev4
+ - const: google,nyan-blaze-rev3
+ - const: google,nyan-blaze-rev2
+ - const: google,nyan-blaze-rev1
+ - const: google,nyan-blaze-rev0
+ - const: google,nyan-blaze
+ - const: google,nyan
+ - const: nvidia,tegra124
- items:
- enum:
- nvidia,norrin
@@ -91,7 +118,22 @@ properties:
- nvidia,p2371-0000
- nvidia,p2371-2180
- nvidia,p2571
- - nvidia,p2894-0050-a08
+ - nvidia,p3450-0000
+ - const: nvidia,tegra210
+ - items:
+ - const: nvidia,p2894-0050-a08
+ - const: nvidia,darcy
+ - const: nvidia,tegra210
+ - items:
+ - const: google,smaug-rev8
+ - const: google,smaug-rev7
+ - const: google,smaug-rev6
+ - const: google,smaug-rev5
+ - const: google,smaug-rev4
+ - const: google,smaug-rev3
+ - const: google,smaug-rev2
+ - const: google,smaug-rev1
+ - const: google,smaug
- const: nvidia,tegra210
- items:
- enum:
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 28/38] dt-bindings: phy: tegra-xusb: Convert to json-schema
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (26 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 27/38] dt-bindings: tegra: Add missing compatible strings Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-18 2:38 ` Rob Herring
2020-06-12 14:18 ` [PATCH 29/38] dt-bindings: tegra: pmc: Increase clock limit for power domains Thierry Reding
` (9 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Convert the Tegra XUSB pad controller bindings from free-form text
format to json-schema.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../phy/nvidia,tegra124-xusb-padctl.txt | 778 -----
.../phy/nvidia,tegra124-xusb-padctl.yaml | 2800 +++++++++++++++++
2 files changed, 2800 insertions(+), 778 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
deleted file mode 100644
index 38c5fa21f435..000000000000
--- a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
+++ /dev/null
@@ -1,778 +0,0 @@
-Device tree binding for NVIDIA Tegra XUSB pad controller
-========================================================
-
-The Tegra XUSB pad controller manages a set of I/O lanes (with differential
-signals) which connect directly to pins/pads on the SoC package. Each lane
-is controlled by a HW block referred to as a "pad" in the Tegra hardware
-documentation. Each such "pad" may control either one or multiple lanes,
-and thus contains any logic common to all its lanes. Each lane can be
-separately configured and powered up.
-
-Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
-super-speed USB. Other lanes are for various types of low-speed, full-speed
-or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
-contains a software-configurable mux that sits between the I/O controller
-ports (e.g. PCIe) and the lanes.
-
-In addition to per-lane configuration, USB 3.0 ports may require additional
-settings on a per-board basis.
-
-Pads will be represented as children of the top-level XUSB pad controller
-device tree node. Each lane exposed by the pad will be represented by its
-own subnode and can be referenced by users of the lane using the standard
-PHY bindings, as described by the phy-bindings.txt file in this directory.
-
-The Tegra hardware documentation refers to the connection between the XUSB
-pad controller and the XUSB controller as "ports". This is confusing since
-"port" is typically used to denote the physical USB receptacle. The device
-tree binding in this document uses the term "port" to refer to the logical
-abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
-for the USB signal, the VBUS power supply, the USB 2.0 companion port for
-USB 3.0 receptacles, ...).
-
-Required properties:
---------------------
-- compatible: Must be:
- - Tegra124: "nvidia,tegra124-xusb-padctl"
- - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
- - Tegra210: "nvidia,tegra210-xusb-padctl"
- - Tegra186: "nvidia,tegra186-xusb-padctl"
- - Tegra194: "nvidia,tegra194-xusb-padctl"
-- reg: Physical base address and length of the controller's registers.
-- resets: Must contain an entry for each entry in reset-names.
-- reset-names: Must include the following entries:
- - "padctl"
-
-For Tegra124:
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- avdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 3.3 V.
-
-For Tegra210:
-- avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8 V.
-- avdd-pll-uerefe-supply: PLLE reference PLL power supply. Must supply 1.05 V.
-- dvdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05 V.
-- hvdd-pex-pll-e-supply: High-voltage PLLE power supply. Must supply 1.8 V.
-
-For Tegra186:
-- avdd-pll-erefeut-supply: UPHY brick and reference clock as well as UTMI PHY
- power supply. Must supply 1.8 V.
-- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply
- 3.3 V.
-- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V.
-- vddio-hsic-supply: HSIC PHY power supply. Must supply 1.2 V.
-
-For Tegra194:
-- avdd-usb-supply: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must supply
- 3.3 V.
-- vclamp-usb-supply: Bias rail for USB pad. Must supply 1.8 V.
-
-Pad nodes:
-==========
-
-A required child node named "pads" contains a list of subnodes, one for each
-of the pads exposed by the XUSB pad controller. Each pad may need additional
-resources that can be referenced in its pad node.
-
-The "status" property is used to enable or disable the use of a pad. If set
-to "disabled", the pad will not be used on the given board. In order to use
-the pad and any of its lanes, this property must be set to "okay".
-
-For Tegra124 and Tegra132, the following pads exist: usb2, ulpi, hsic, pcie
-and sata. No extra resources are required for operation of these pads.
-
-For Tegra210, the following pads exist: usb2, hsic, pcie and sata. Below is
-a description of the properties of each pad.
-
-UTMI pad:
----------
-
-Required properties:
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must contain the following entries:
- - "trk": phandle and specifier referring to the USB2 tracking clock
-
-HSIC pad:
----------
-
-Required properties:
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must contain the following entries:
- - "trk": phandle and specifier referring to the HSIC tracking clock
-
-PCIe pad:
----------
-
-Required properties:
-- clocks: Must contain an entry for each entry in clock-names.
-- clock-names: Must contain the following entries:
- - "pll": phandle and specifier referring to the PLLE
-- resets: Must contain an entry for each entry in reset-names.
-- reset-names: Must contain the following entries:
- - "phy": reset for the PCIe UPHY block
-
-SATA pad:
----------
-
-Required properties:
-- resets: Must contain an entry for each entry in reset-names.
-- reset-names: Must contain the following entries:
- - "phy": reset for the SATA UPHY block
-
-
-PHY nodes:
-==========
-
-Each pad node has a child named "lanes" that contains one or more children of
-its own, each representing one of the lanes controlled by the pad.
-
-Required properties:
---------------------
-- status: Defines the operation status of the PHY. Valid values are:
- - "disabled": the PHY is disabled
- - "okay": the PHY is enabled
-- #phy-cells: Should be 0. Since each lane represents a single PHY, there is
- no need for an additional specifier.
-- nvidia,function: The output function of the PHY. See below for a list of
- valid functions per SoC generation.
-
-For Tegra124 and Tegra132, the list of valid PHY nodes is given below:
-- usb2: usb2-0, usb2-1, usb2-2
- - functions: "snps", "xusb", "uart"
-- ulpi: ulpi-0
- - functions: "snps", "xusb"
-- hsic: hsic-0, hsic-1
- - functions: "snps", "xusb"
-- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4
- - functions: "pcie", "usb3-ss"
-- sata: sata-0
- - functions: "usb3-ss", "sata"
-
-For Tegra210, the list of valid PHY nodes is given below:
-- usb2: usb2-0, usb2-1, usb2-2, usb2-3
- - functions: "snps", "xusb", "uart"
-- hsic: hsic-0, hsic-1
- - functions: "snps", "xusb"
-- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6
- - functions: "pcie-x1", "usb3-ss", "pcie-x4"
-- sata: sata-0
- - functions: "usb3-ss", "sata"
-
-For Tegra194, the list of valid PHY nodes is given below:
-- usb2: usb2-0, usb2-1, usb2-2, usb2-3
- - functions: "xusb"
-- usb3: usb3-0, usb3-1, usb3-2, usb3-3
- - functions: "xusb"
-
-Port nodes:
-===========
-
-A required child node named "ports" contains a list of all the ports exposed
-by the XUSB pad controller. Per-port configuration is only required for USB.
-
-USB2 ports:
------------
-
-Required properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-- mode: A string that determines the mode in which to run the port. Valid
- values are:
- - "host": for USB host mode
- - "device": for USB device mode
- - "otg": for USB OTG mode
-
-Required properties for OTG/Peripheral capable USB2 ports:
-- usb-role-switch: Boolean property to indicate that the port support OTG or
- peripheral mode. If present, the port supports switching between USB host
- and peripheral roles. Connector should be added as subnode.
- See usb/usb-conn-gpio.txt.
-
-Optional properties:
-- nvidia,internal: A boolean property whose presence determines that a port
- is internal. In the absence of this property the port is considered to be
- external.
-- vbus-supply: phandle to a regulator supplying the VBUS voltage.
-
-ULPI ports:
------------
-
-Optional properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-- nvidia,internal: A boolean property whose presence determines that a port
- is internal. In the absence of this property the port is considered to be
- external.
-- vbus-supply: phandle to a regulator supplying the VBUS voltage.
-
-HSIC ports:
------------
-
-Required properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-
-Optional properties:
-- vbus-supply: phandle to a regulator supplying the VBUS voltage.
-
-Super-speed USB ports:
-----------------------
-
-Required properties:
-- status: Defines the operation status of the port. Valid values are:
- - "disabled": the port is disabled
- - "okay": the port is enabled
-- nvidia,usb2-companion: A single cell that specifies the physical port number
- to map this super-speed USB port to. The range of valid port numbers varies
- with the SoC generation:
- - 0-2: for Tegra124 and Tegra132
- - 0-3: for Tegra210
-
-Optional properties:
-- nvidia,internal: A boolean property whose presence determines that a port
- is internal. In the absence of this property the port is considered to be
- external.
-
-- maximum-speed: Only for Tegra194. A string property that specifies maximum
- supported speed of a usb3 port. Valid values are:
- - "super-speed-plus": default, the usb3 port supports USB 3.1 Gen 2 speed.
- - "super-speed": the usb3 port supports USB 3.1 Gen 1 speed only.
-
-For Tegra124 and Tegra132, the XUSB pad controller exposes the following
-ports:
-- 3x USB2: usb2-0, usb2-1, usb2-2
-- 1x ULPI: ulpi-0
-- 2x HSIC: hsic-0, hsic-1
-- 2x super-speed USB: usb3-0, usb3-1
-
-For Tegra210, the XUSB pad controller exposes the following ports:
-- 4x USB2: usb2-0, usb2-1, usb2-2, usb2-3
-- 2x HSIC: hsic-0, hsic-1
-- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
-
-For Tegra194, the XUSB pad controller exposes the following ports:
-- 4x USB2: usb2-0, usb2-1, usb2-2, usb2-3
-- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3
-
-Examples:
-=========
-
-Tegra124 and Tegra132:
-----------------------
-
-SoC include:
-
- padctl@7009f000 {
- /* for Tegra124 */
- compatible = "nvidia,tegra124-xusb-padctl";
- /* for Tegra132 */
- compatible = "nvidia,tegra132-xusb-padctl",
- "nvidia,tegra124-xusb-padctl";
- reg = <0x0 0x7009f000 0x0 0x1000>;
- resets = <&tegra_car 142>;
- reset-names = "padctl";
-
- pads {
- usb2 {
- status = "disabled";
-
- lanes {
- usb2-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- ulpi {
- status = "disabled";
-
- lanes {
- ulpi-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- hsic {
- status = "disabled";
-
- lanes {
- hsic-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- hsic-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- pcie {
- status = "disabled";
-
- lanes {
- pcie-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-3 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-4 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- sata {
- status = "disabled";
-
- lanes {
- sata-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
- };
-
- ports {
- usb2-0 {
- status = "disabled";
- };
-
- usb2-1 {
- status = "disabled";
- };
-
- usb2-2 {
- status = "disabled";
- };
-
- ulpi-0 {
- status = "disabled";
- };
-
- hsic-0 {
- status = "disabled";
- };
-
- hsic-1 {
- status = "disabled";
- };
-
- usb3-0 {
- status = "disabled";
- };
-
- usb3-1 {
- status = "disabled";
- };
- };
- };
-
-Board file:
-
- padctl@7009f000 {
- status = "okay";
-
- pads {
- usb2 {
- status = "okay";
-
- lanes {
- usb2-0 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-1 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-2 {
- nvidia,function = "xusb";
- status = "okay";
- };
- };
- };
-
- pcie {
- status = "okay";
-
- lanes {
- pcie-0 {
- nvidia,function = "usb3-ss";
- status = "okay";
- };
-
- pcie-2 {
- nvidia,function = "pcie";
- status = "okay";
- };
-
- pcie-4 {
- nvidia,function = "pcie";
- status = "okay";
- };
- };
- };
-
- sata {
- status = "okay";
-
- lanes {
- sata-0 {
- nvidia,function = "sata";
- status = "okay";
- };
- };
- };
- };
-
- ports {
- /* Micro A/B */
- usb2-0 {
- status = "okay";
- mode = "otg";
- };
-
- /* Mini PCIe */
- usb2-1 {
- status = "okay";
- mode = "host";
- };
-
- /* USB3 */
- usb2-2 {
- status = "okay";
- mode = "host";
-
- vbus-supply = <&vdd_usb3_vbus>;
- };
-
- usb3-0 {
- nvidia,port = <2>;
- status = "okay";
- };
- };
- };
-
-Tegra210:
----------
-
-SoC include:
-
- padctl@7009f000 {
- compatible = "nvidia,tegra210-xusb-padctl";
- reg = <0x0 0x7009f000 0x0 0x1000>;
- resets = <&tegra_car 142>;
- reset-names = "padctl";
-
- status = "disabled";
-
- pads {
- usb2 {
- clocks = <&tegra_car TEGRA210_CLK_USB2_TRK>;
- clock-names = "trk";
- status = "disabled";
-
- lanes {
- usb2-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- usb2-3 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- hsic {
- clocks = <&tegra_car TEGRA210_CLK_HSIC_TRK>;
- clock-names = "trk";
- status = "disabled";
-
- lanes {
- hsic-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- hsic-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- pcie {
- clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
- clock-names = "pll";
- resets = <&tegra_car 205>;
- reset-names = "phy";
- status = "disabled";
-
- lanes {
- pcie-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-1 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-2 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-3 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-4 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-5 {
- status = "disabled";
- #phy-cells = <0>;
- };
-
- pcie-6 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
-
- sata {
- clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
- clock-names = "pll";
- resets = <&tegra_car 204>;
- reset-names = "phy";
- status = "disabled";
-
- lanes {
- sata-0 {
- status = "disabled";
- #phy-cells = <0>;
- };
- };
- };
- };
-
- ports {
- usb2-0 {
- status = "disabled";
- };
-
- usb2-1 {
- status = "disabled";
- };
-
- usb2-2 {
- status = "disabled";
- };
-
- usb2-3 {
- status = "disabled";
- };
-
- hsic-0 {
- status = "disabled";
- };
-
- hsic-1 {
- status = "disabled";
- };
-
- usb3-0 {
- status = "disabled";
- };
-
- usb3-1 {
- status = "disabled";
- };
-
- usb3-2 {
- status = "disabled";
- };
-
- usb3-3 {
- status = "disabled";
- };
- };
- };
-
-Board file:
-
- padctl@7009f000 {
- status = "okay";
-
- pads {
- usb2 {
- status = "okay";
-
- lanes {
- usb2-0 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-1 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-2 {
- nvidia,function = "xusb";
- status = "okay";
- };
-
- usb2-3 {
- nvidia,function = "xusb";
- status = "okay";
- };
- };
- };
-
- pcie {
- status = "okay";
-
- lanes {
- pcie-0 {
- nvidia,function = "pcie-x1";
- status = "okay";
- };
-
- pcie-1 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-2 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-3 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-4 {
- nvidia,function = "pcie-x4";
- status = "okay";
- };
-
- pcie-5 {
- nvidia,function = "usb3-ss";
- status = "okay";
- };
-
- pcie-6 {
- nvidia,function = "usb3-ss";
- status = "okay";
- };
- };
- };
-
- sata {
- status = "okay";
-
- lanes {
- sata-0 {
- nvidia,function = "sata";
- status = "okay";
- };
- };
- };
- };
-
- ports {
- usb2-0 {
- status = "okay";
- mode = "otg";
- };
-
- usb2-1 {
- status = "okay";
- vbus-supply = <&vdd_5v0_rtl>;
- mode = "host";
- };
-
- usb2-2 {
- status = "okay";
- vbus-supply = <&vdd_usb_vbus>;
- mode = "host";
- };
-
- usb2-3 {
- status = "okay";
- mode = "host";
- };
-
- usb3-0 {
- status = "okay";
- nvidia,lanes = "pcie-6";
- nvidia,port = <1>;
- };
-
- usb3-1 {
- status = "okay";
- nvidia,lanes = "pcie-5";
- nvidia,port = <2>;
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
new file mode 100644
index 000000000000..8c647fd4a340
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
@@ -0,0 +1,2800 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/nvidia,tegra124-xusb-padctl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra XUSB pad controller
+
+maintainers:
+ - Thierry Reding <thierry.reding@gmail.com>
+ - Jon Hunter <jonathanh@nvidia.com>
+
+description:
+ The Tegra XUSB pad controller manages a set of I/O lanes (with differential
+ signals) which connect directly to pins/pads on the SoC package. Each lane
+ is controlled by a HW block referred to as a "pad" in the Tegra hardware
+ documentation. Each such "pad" may control either one or multiple lanes,
+ and thus contains any logic common to all its lanes. Each lane can be
+ separately configured and powered up.
+
+ Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
+ super-speed USB. Other lanes are for various types of low-speed, full-speed
+ or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
+ contains a software-configurable mux that sits between the I/O controller
+ ports (e.g. PCIe) and the lanes.
+
+ In addition to per-lane configuration, USB 3.0 ports may require additional
+ settings on a per-board basis.
+
+ Pads will be represented as children of the top-level XUSB pad controller
+ device tree node. Each lane exposed by the pad will be represented by its
+ own subnode and can be referenced by users of the lane using the standard
+ PHY bindings, as described by the phy-bindings.txt file in this directory.
+
+ The Tegra hardware documentation refers to the connection between the XUSB
+ pad controller and the XUSB controller as "ports". This is confusing since
+ "port" is typically used to denote the physical USB receptacle. The device
+ tree binding in this document uses the term "port" to refer to the logical
+ abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
+ for the USB signal, the VBUS power supply, the USB 2.0 companion port for
+ USB 3.0 receptacles, ...).
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - const: nvidia,tegra124-xusb-padctl
+
+ - items:
+ - const: nvidia,tegra132-xusb-padctl
+ - const: nvidia,tegra124-xusb-padctl
+
+ - items:
+ - const: nvidia,tegra210-xusb-padctl
+
+ - items:
+ - const: nvidia,tegra186-xusb-padctl
+
+ - items:
+ - const: nvidia,tegra194-xusb-padctl
+
+ resets:
+ items:
+ - description: pad controller reset
+
+ reset-names:
+ items:
+ - const: padctl
+
+ pads:
+ description: A required child node named "pads" contains a list of
+ subnodes, one for each of the pads exposed by the XUSB pad controller.
+ Each pad may need additional resources that can be referenced in its
+ pad node.
+
+ The "status" property is used to enable or disable the use of a pad.
+ If set to "disabled", the pad will not be used on the given board. In
+ order to use the pad and any of its lanes, this property must be set
+ to "okay".
+ type: object
+
+ ports:
+ type: object
+
+required:
+ - compatible
+ - reg
+ - resets
+ - reset-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra124-xusb-padctl
+ then:
+ properties:
+ reg:
+ maxItems: 1
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-erefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ avdd-pex-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-pex-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 3.3 V.
+
+ pads:
+ properties:
+ usb2:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ properties:
+ usb2-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb, uart ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb2-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb, uart ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb2-2:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb, uart ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ ulpi:
+ type: object
+ properties:
+ lanes:
+ type: object
+ properties:
+ ulpi-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ hsic:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: HSIC tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ properties:
+ hsic-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ hsic-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: PLLE clock
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: reset for the PCIe UPHY block
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ properties:
+ pcie-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie, usb3-ss ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie, usb3-ss ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-2:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie, usb3-ss ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-3:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie, usb3-ss ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-4:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie, usb3-ss ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ sata:
+ type: object
+ properties:
+ resets:
+ items:
+ - description: reset for the SATA UPHY block
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ properties:
+ sata-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ sata, usb3-ss ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ ports:
+ properties:
+ usb2-0:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-1:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-2:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ ulpi-0:
+ type: object
+ properties:
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ hsic-0:
+ type: object
+ properties:
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ hsic-1:
+ type: object
+ properties:
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ usb3-0:
+ type: object
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ usb3-1:
+ type: object
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ required:
+ - avdd-pll-utmip-supply
+ - avdd-pll-erefe-supply
+ - avdd-pex-pll-supply
+ - hvdd-pex-pll-e-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra210-xusb-padctl
+ then:
+ properties:
+ reg:
+ maxItems: 1
+
+ avdd-pll-utmip-supply:
+ description: UTMI PLL power supply. Must supply 1.8 V.
+
+ avdd-pll-uerefe-supply:
+ description: PLLE reference PLL power supply. Must supply 1.05 V.
+
+ dvdd-pex-pll-supply:
+ description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
+
+ hvdd-pex-pll-e-supply:
+ description: High-voltage PLLE power supply. Must supply 1.8 V.
+
+ pads:
+ properties:
+ usb2:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ properties:
+ usb2-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb, uart ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb2-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb, uart ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb2-2:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb, uart ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb2-3:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb, uart ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ hsic:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: HSIC tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ properties:
+ hsic-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ hsic-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ snps, xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: PCIe PLL clock source
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: PCIe PHY reset
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ properties:
+ pcie-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-2:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-3:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-4:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-5:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ pcie-6:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ pcie-x1, usb3-ss, pcie-x4 ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ sata:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: SATA PLL clock source
+
+ clock-names:
+ items:
+ - const: pll
+
+ resets:
+ items:
+ - description: SATA PHY reset
+
+ reset-names:
+ items:
+ - const: phy
+
+ lanes:
+ type: object
+ properties:
+ sata-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ usb3-ss, sata ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ ports:
+ properties:
+ usb2-0:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-1:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-2:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-3:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ hsic-0:
+ type: object
+ properties:
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ hsic-1:
+ type: object
+ properties:
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ usb3-0:
+ type: object
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ usb3-1:
+ type: object
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ usb3-2:
+ type: object
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ usb3-3:
+ type: object
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ required:
+ - avdd-pll-utmip-supply
+ - avdd-pll-uerefe-supply
+ - dvdd-pex-pll-supply
+ - hvdd-pex-pll-e-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra186-xusb-padctl
+ then:
+ properties:
+ reg:
+ items:
+ - description: pad controller registers
+ - description: AO registers
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: padctl
+ - const: ao
+
+ avdd-pll-erefeut-supply:
+ description: UPHY brick and reference clock as well as UTMI PHY
+ power supply. Must supply 1.8 V.
+
+ avdd-usb-supply:
+ description: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must
+ supply 3.3 V.
+
+ vclamp-usb-supply:
+ description: Bias rail for USB pad. Must supply 1.8 V.
+
+ vddio-hsic-supply:
+ description: HSIC PHY power supply. Must supply 1.2 V.
+
+ pads:
+ properties:
+ usb2:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ properties:
+ usb2-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb2-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb2-2:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ hsic:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: HSIC tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ properties:
+ hsic-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb3:
+ type: object
+ properties:
+ lanes:
+ type: object
+ properties:
+ usb3-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb3-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb3-2:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ ports:
+ type: object
+ properties:
+ usb2-0:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-1:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-2:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ hsic-0:
+ type: object
+ properties:
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb3-0:
+ type: object
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-1:
+ type: object
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ usb3-2:
+ type: object
+ properties:
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ required:
+ - avdd-pll-erefeut-supply
+ - avdd-usb-supply
+ - vclamp-usb-supply
+ - vddio-hsic-supply
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nvidia,tegra194-xusb-padctl
+ then:
+ properties:
+ reg:
+ items:
+ - description: pad controller registers
+ - description: AO registers
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: padctl
+ - const: ao
+
+ avdd-usb-supply:
+ description: USB I/Os, VBUS, ID, REXT, D+/D- power supply. Must
+ supply 3.3 V.
+
+ vclamp-usb-supply:
+ description: Bias rail for USB pad. Must supply 1.8 V.
+
+ pads:
+ properties:
+ usb2:
+ type: object
+ properties:
+ clocks:
+ items:
+ - description: USB2 tracking clock
+
+ clock-names:
+ items:
+ - const: trk
+
+ lanes:
+ type: object
+ properties:
+ usb2-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb2-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+
+ usb2-2:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb2-3:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb3:
+ type: object
+ properties:
+ lanes:
+ type: object
+ properties:
+ usb3-0:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb3-1:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb3-2:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ usb3-3:
+ type: object
+ properties:
+ "#phy-cells":
+ const: 0
+
+ nvidia,function:
+ enum: [ xusb ]
+
+ phandle:
+ $ref: "/schemas/dt-core.yaml#/properties/phandle"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ ports:
+ properties:
+ usb2-0:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-1:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-2:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb2-3:
+ type: object
+ properties:
+ # no need to further describe this because the connector will
+ # match on gpio-usb-b-connector or usb-b-connector and cause
+ # that binding to be selected for the subnode
+ connector:
+ type: object
+
+ mode:
+ description: A string that determines the mode in which to
+ run the port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ enum: [ host, peripheral, otg ]
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ usb-role-switch:
+ description: |
+ A boolean property whole presence indicates that the port
+ supports OTG or peripheral mode. If present, the port
+ supports switching between USB host and peripheral roles.
+ A connector must be added as a subnode in that case.
+
+ See ../connector/usb-connector.yaml.
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ dependencies:
+ usb-role-switch: [ connector ]
+
+ additionalProperties: false
+
+ usb3-0:
+ type: object
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ usb3-1:
+ type: object
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ usb3-2:
+ type: object
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ usb3-3:
+ type: object
+ properties:
+ maximum-speed:
+ description: A string property that specifies the maximum
+ supported speed of a USB3 port.
+ $ref: "/schemas/types.yaml#/definitions/string"
+ oneOf:
+ - description: The USB3 port supports USB 3.1 Gen 2 speed.
+ This is the default.
+ const: super-speed-plus
+ - description: The USB3 port supports USB 3.1 Gen 1 speed
+ only.
+ const: super-speed
+
+ nvidia,internal:
+ description: A boolean property whose presence determines
+ that a port is internal. In the absence of this property
+ the port is considered to be external.
+ $ref: "/schemas/types.yaml#/definitions/flag"
+
+ nvidia,usb2-companion:
+ description: A single cell that specifies the physical port
+ number to map this super-speed USB port to. The range of
+ valid port numbers varies with the SoC generation.
+ enum: [ 0, 1, 2, 3 ]
+
+ status:
+ $ref: "/schemas/dt-core.yaml#/properties/status"
+
+ vbus-supply:
+ description: A phandle to the regulator supplying the VBUS
+ voltage.
+
+ additionalProperties: false
+
+ additionalProperties: false
+
+ required:
+ - avdd-usb-supply
+ - vclamp-usb-supply
+
+unevaluatedProperties: false
+
+examples:
+ # Tegra124 and Tegra132
+ - |
+ padctl@7009f000 {
+ compatible = "nvidia,tegra124-xusb-padctl";
+ reg = <0x7009f000 0x1000>;
+ resets = <&tegra_car 142>;
+ reset-names = "padctl";
+
+ avdd-pll-utmip-supply = <&vddio_1v8>;
+ avdd-pll-erefe-supply = <&avdd_1v05_run>;
+ avdd-pex-pll-supply = <&vdd_1v05_run>;
+ hvdd-pex-pll-e-supply = <&vdd_3v3_lp0>;
+
+ pads {
+ usb2 {
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ ulpi {
+ lanes {
+ ulpi-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ hsic-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ pcie {
+ lanes {
+ pcie-0 {
+ nvidia,function = "usb3-ss";
+ #phy-cells = <0>;
+ };
+
+ pcie-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ pcie-2 {
+ nvidia,function = "pcie";
+ #phy-cells = <0>;
+ };
+
+ pcie-3 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ pcie-4 {
+ nvidia,function = "pcie";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ sata {
+ lanes {
+ sata-0 {
+ nvidia,function = "sata";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ /* Micro A/B */
+ usb2-0 {
+ mode = "otg";
+ };
+
+ /* Mini PCIe */
+ usb2-1 {
+ mode = "host";
+ };
+
+ /* USB3 */
+ usb2-2 {
+ vbus-supply = <&vdd_usb3_vbus>;
+ mode = "host";
+ };
+
+ ulpi-0 {
+ status = "disabled";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ hsic-1 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <2>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+ };
+ };
+
+ # Tegra210
+ - |
+ #include <dt-bindings/clock/tegra210-car.h>
+ #include <dt-bindings/gpio/tegra-gpio.h>
+
+ padctl@7009f000 {
+ compatible = "nvidia,tegra210-xusb-padctl";
+ reg = <0x7009f000 0x1000>;
+ resets = <&tegra_car 142>;
+ reset-names = "padctl";
+
+ avdd-pll-utmip-supply = <&vdd_1v8>;
+ avdd-pll-uerefe-supply = <&vdd_pex_1v05>;
+ dvdd-pex-pll-supply = <&vdd_pex_1v05>;
+ hvdd-pex-pll-e-supply = <&vdd_1v8>;
+
+ pads {
+ usb2 {
+ clocks = <&tegra_car TEGRA210_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-3 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ clocks = <&tegra_car TEGRA210_CLK_HSIC_TRK>;
+ clock-names = "trk";
+ status = "disabled";
+
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ hsic-1 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ pcie {
+ clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
+ clock-names = "pll";
+ resets = <&tegra_car 205>;
+ reset-names = "phy";
+
+ lanes {
+ pcie-0 {
+ nvidia,function = "pcie-x1";
+ #phy-cells = <0>;
+ };
+
+ pcie-1 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-2 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-3 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-4 {
+ nvidia,function = "pcie-x4";
+ #phy-cells = <0>;
+ };
+
+ pcie-5 {
+ nvidia,function = "usb3-ss";
+ #phy-cells = <0>;
+ };
+
+ pcie-6 {
+ nvidia,function = "usb3-ss";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ sata {
+ clocks = <&tegra_car TEGRA210_CLK_PLL_E>;
+ clock-names = "pll";
+ resets = <&tegra_car 204>;
+ reset-names = "phy";
+
+ lanes {
+ sata-0 {
+ nvidia,function = "sata";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ mode = "peripheral";
+ usb-role-switch;
+
+ connector {
+ compatible = "gpio-usb-b-connector",
+ "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ vbus-gpios = <&gpio TEGRA_GPIO(CC, 4) GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ usb2-1 {
+ vbus-supply = <&vdd_5v0_rtl>;
+ mode = "host";
+ };
+
+ usb2-2 {
+ vbus-supply = <&vdd_usb_vbus>;
+ mode = "host";
+ };
+
+ usb2-3 {
+ mode = "host";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ hsic-1 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <1>;
+ };
+
+ usb3-1 {
+ nvidia,usb2-companion = <2>;
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+
+ usb3-3 {
+ status = "disabled";
+ };
+ };
+ };
+
+ # Tegra186
+ - |
+ #include <dt-bindings/clock/tegra186-clock.h>
+ #include <dt-bindings/gpio/tegra186-gpio.h>
+ #include <dt-bindings/reset/tegra186-reset.h>
+
+ padctl@3520000 {
+ compatible = "nvidia,tegra186-xusb-padctl";
+ reg = <0x03520000 0x1000>,
+ <0x03540000 0x1000>;
+ reg-names = "padctl", "ao";
+
+ resets = <&bpmp TEGRA186_RESET_XUSB_PADCTL>;
+ reset-names = "padctl";
+
+ avdd-pll-erefeut-supply = <&vdd_1v8_pll>;
+ avdd-usb-supply = <&vdd_3v3_sys>;
+ vclamp-usb-supply = <&vdd_1v8>;
+ vddio-hsic-supply = <&gnd>;
+
+ pads {
+ usb2 {
+ clocks = <&bpmp TEGRA186_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ hsic {
+ clocks = <&bpmp TEGRA186_CLK_HSIC_TRK>;
+ clock-names = "trk";
+ status = "disabled";
+
+ lanes {
+ hsic-0 {
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb3-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb3-2 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ mode = "otg";
+ vbus-supply = <&vdd_usb0>;
+ usb-role-switch;
+
+ connector {
+ compatible = "gpio-usb-b-connector",
+ "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ vbus-gpios = <&gpio TEGRA186_MAIN_GPIO(X, 7) GPIO_ACTIVE_LOW>;
+ id-gpios = <&pmic 0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ usb2-1 {
+ vbus-supply = <&vdd_usb1>;
+ mode = "host";
+ };
+
+ usb2-2 {
+ status = "disabled";
+ };
+
+ hsic-0 {
+ status = "disabled";
+ };
+
+ usb3-0 {
+ nvidia,usb2-companion = <1>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+ };
+ };
+
+ # Tegra194
+ - |
+ #include <dt-bindings/clock/tegra194-clock.h>
+ #include <dt-bindings/gpio/tegra194-gpio.h>
+ #include <dt-bindings/reset/tegra194-reset.h>
+
+ padctl@3520000 {
+ compatible = "nvidia,tegra194-xusb-padctl";
+ reg = <0x03520000 0x1000>,
+ <0x03540000 0x1000>;
+ reg-names = "padctl", "ao";
+
+ resets = <&bpmp TEGRA194_RESET_XUSB_PADCTL>;
+ reset-names = "padctl";
+
+ avdd-usb-supply = <&vdd_usb_3v3>;
+ vclamp-usb-supply = <&vdd_1v8ao>;
+
+ pads {
+ usb2 {
+ clocks = <&bpmp TEGRA194_CLK_USB2_TRK>;
+ clock-names = "trk";
+
+ lanes {
+ usb2-0 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-1 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb2-2 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb2-3 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+
+ usb3 {
+ lanes {
+ usb3-0 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+
+ usb3-1 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-2 {
+ nvidia,function = "xusb";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
+ usb3-3 {
+ nvidia,function = "xusb";
+ #phy-cells = <0>;
+ };
+ };
+ };
+ };
+
+ ports {
+ usb2-0 {
+ status = "disabled";
+ };
+
+ usb2-1 {
+ vbus-supply = <&vdd_5v0_sys>;
+ mode = "host";
+ };
+
+ usb2-2 {
+ status = "disabled";
+ };
+
+ usb2-3 {
+ vbus-supply = <&vdd_5v_sata>;
+ mode = "host";
+ };
+
+ usb3-0 {
+ vbus-supply = <&vdd_5v0_sys>;
+ nvidia,usb2-companion = <1>;
+ };
+
+ usb3-1 {
+ status = "disabled";
+ };
+
+ usb3-2 {
+ status = "disabled";
+ };
+
+ usb3-3 {
+ maximum-speed = "super-speed";
+ vbus-supply = <&vdd_5v0_sys>;
+ nvidia,usb2-companion = <3>;
+ };
+ };
+ };
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 28/38] dt-bindings: phy: tegra-xusb: Convert to json-schema
2020-06-12 14:18 ` [PATCH 28/38] dt-bindings: phy: tegra-xusb: Convert to json-schema Thierry Reding
@ 2020-06-18 2:38 ` Rob Herring
2020-06-19 6:47 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Rob Herring @ 2020-06-18 2:38 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:18:53PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the Tegra XUSB pad controller bindings from free-form text
> format to json-schema.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../phy/nvidia,tegra124-xusb-padctl.txt | 778 -----
> .../phy/nvidia,tegra124-xusb-padctl.yaml | 2800 +++++++++++++++++
> 2 files changed, 2800 insertions(+), 778 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
> create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
This one I definitely think should be split up into multiple schema
files. There's very little shared.
Rob
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 28/38] dt-bindings: phy: tegra-xusb: Convert to json-schema
2020-06-18 2:38 ` Rob Herring
@ 2020-06-19 6:47 ` Thierry Reding
0 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-19 6:47 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
On Wed, Jun 17, 2020 at 08:38:26PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:18:53PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Convert the Tegra XUSB pad controller bindings from free-form text
> > format to json-schema.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > .../phy/nvidia,tegra124-xusb-padctl.txt | 778 -----
> > .../phy/nvidia,tegra124-xusb-padctl.yaml | 2800 +++++++++++++++++
> > 2 files changed, 2800 insertions(+), 778 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
> > create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
>
> This one I definitely think should be split up into multiple schema
> files. There's very little shared.
Okay, I think I can do that. It's going to be a little annoying because
then there's going to be at least four bindings to check, but I don't
think it'll be all that bad. Once the bindings are merged I think I'll
end up mostly running dtbs_check anyway, in which case the number of
files doesn't really matter.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 29/38] dt-bindings: tegra: pmc: Increase clock limit for power domains
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (27 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 28/38] dt-bindings: phy: tegra-xusb: Convert to json-schema Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 30/38] dt-bindings: panel: Allow reg property for DSI panels Thierry Reding
` (8 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Power domains (such as the SOR domain) can have more than 8 clocks. Bump
the limit to 10 which is enough as of now.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml
index 81534d04094b..881bfc6154e2 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml
@@ -213,7 +213,7 @@ properties:
patternProperties:
clocks:
minItems: 1
- maxItems: 8
+ maxItems: 10
description:
Must contain an entry for each clock required by the PMC
for controlling a power-gate.
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 30/38] dt-bindings: panel: Allow reg property for DSI panels
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (28 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 29/38] dt-bindings: tegra: pmc: Increase clock limit for power domains Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:29 ` Rob Herring
2020-06-12 14:18 ` [PATCH 31/38] dt-bindings: panel: simple: Use unevaluatedProperties Thierry Reding
` (7 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
For DSI panels the "reg" property is needed to represent the virtual
channel of the given panel.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index d6cca1479633..34fe3d42b829 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -267,6 +267,9 @@ properties:
# Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
- winstar,wf35ltiacd
+ reg:
+ description: virtual channel for DSI panels
+
backlight: true
enable-gpios: true
port: true
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 30/38] dt-bindings: panel: Allow reg property for DSI panels
2020-06-12 14:18 ` [PATCH 30/38] dt-bindings: panel: Allow reg property for DSI panels Thierry Reding
@ 2020-06-12 14:29 ` Rob Herring
2020-06-16 14:35 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Rob Herring @ 2020-06-12 14:29 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 8:20 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> From: Thierry Reding <treding@nvidia.com>
>
> For DSI panels the "reg" property is needed to represent the virtual
> channel of the given panel.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index d6cca1479633..34fe3d42b829 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -267,6 +267,9 @@ properties:
> # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
> - winstar,wf35ltiacd
>
> + reg:
> + description: virtual channel for DSI panels
> +
panel-simple-dsi.yaml?
> backlight: true
> enable-gpios: true
> port: true
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 30/38] dt-bindings: panel: Allow reg property for DSI panels
2020-06-12 14:29 ` Rob Herring
@ 2020-06-16 14:35 ` Thierry Reding
0 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-16 14:35 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]
On Fri, Jun 12, 2020 at 08:29:35AM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 8:20 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > From: Thierry Reding <treding@nvidia.com>
> >
> > For DSI panels the "reg" property is needed to represent the virtual
> > channel of the given panel.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > .../devicetree/bindings/display/panel/panel-simple.yaml | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > index d6cca1479633..34fe3d42b829 100644
> > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > @@ -267,6 +267,9 @@ properties:
> > # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
> > - winstar,wf35ltiacd
> >
> > + reg:
> > + description: virtual channel for DSI panels
> > +
>
> panel-simple-dsi.yaml?
Heh... I had completely missed that. I've now replaced this patch with
one that moves the lg,lh500wx1-sd03 compatible string to the DSI schema.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 31/38] dt-bindings: panel: simple: Use unevaluatedProperties
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (29 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 30/38] dt-bindings: panel: Allow reg property for DSI panels Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:28 ` Rob Herring
2020-06-12 14:18 ` [PATCH 32/38] dt-bindings: leds: Document rfkill* trigger Thierry Reding
` (6 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Using "additionalProperties: false" results in rejecting any of the
properties defined in panel-common.yaml, whereas the intent is to
inherit the common properties defined in that file.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 34fe3d42b829..c58bc90ffd43 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -275,7 +275,7 @@ properties:
port: true
power-supply: true
-additionalProperties: false
+unevaluatedProperties: false
required:
- compatible
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 31/38] dt-bindings: panel: simple: Use unevaluatedProperties
2020-06-12 14:18 ` [PATCH 31/38] dt-bindings: panel: simple: Use unevaluatedProperties Thierry Reding
@ 2020-06-12 14:28 ` Rob Herring
2020-06-16 14:33 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Rob Herring @ 2020-06-12 14:28 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 8:20 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> From: Thierry Reding <treding@nvidia.com>
>
> Using "additionalProperties: false" results in rejecting any of the
> properties defined in panel-common.yaml, whereas the intent is to
> inherit the common properties defined in that file.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index 34fe3d42b829..c58bc90ffd43 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -275,7 +275,7 @@ properties:
> port: true
> power-supply: true
>
> -additionalProperties: false
> +unevaluatedProperties: false
But we've listed the properties we use here. Some of the common ones
may not be applicable. Maybe they are and if so, then you should drop
all the ones listed with 'true' with this change.
Rob
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 31/38] dt-bindings: panel: simple: Use unevaluatedProperties
2020-06-12 14:28 ` Rob Herring
@ 2020-06-16 14:33 ` Thierry Reding
0 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-16 14:33 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
On Fri, Jun 12, 2020 at 08:28:13AM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 8:20 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Using "additionalProperties: false" results in rejecting any of the
> > properties defined in panel-common.yaml, whereas the intent is to
> > inherit the common properties defined in that file.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > index 34fe3d42b829..c58bc90ffd43 100644
> > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> > @@ -275,7 +275,7 @@ properties:
> > port: true
> > power-supply: true
> >
> > -additionalProperties: false
> > +unevaluatedProperties: false
>
> But we've listed the properties we use here. Some of the common ones
> may not be applicable. Maybe they are and if so, then you should drop
> all the ones listed with 'true' with this change.
Looks like the only one I need this for is ddc-i2c-bus, which is already
contained in panel-common.yaml. unevaluatedProperties: false is able to
look into that and hence doesn't flag this as extra.
However, I can also work around that by adding a "ddc-i2c-bus: true" to
panel-simple.yaml, which seems like it's the currently preferred way to
do this. Is it expected that once jsonschema/dt-schema support the
unevaluatedProperties keyword that we'd move towards using that instead?
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 32/38] dt-bindings: leds: Document rfkill* trigger
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (30 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 31/38] dt-bindings: panel: simple: Use unevaluatedProperties Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 33/38] dt-bindings: memory-controller: Document Tegra132 EMC Thierry Reding
` (5 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
LEDs can use rfkill events as a trigger source, so document these in the
device tree bindings.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/leds/common.yaml | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index a2a541bca73c..6619d1ff1031 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -79,24 +79,25 @@ properties:
the LED.
$ref: /schemas/types.yaml#definitions/string
- enum:
+ oneOf:
# LED will act as a back-light, controlled by the framebuffer system
- - backlight
+ - const: backlight
# LED will turn on (but for leds-gpio see "default-state" property in
# Documentation/devicetree/bindings/leds/leds-gpio.yaml)
- - default-on
+ - const: default-on
# LED "double" flashes at a load average based rate
- - heartbeat
+ - const: heartbeat
# LED indicates disk activity
- - disk-activity
+ - const: disk-activity
# LED indicates IDE disk activity (deprecated), in new implementations
# use "disk-activity"
- - ide-disk
+ - const: ide-disk
# LED flashes at a fixed, configurable rate
- - timer
+ - const: timer
# LED alters the brightness for the specified duration with one software
# timer (requires "led-pattern" property)
- - pattern
+ - const: pattern
+ - pattern: "^rfkill[0-9]+$"
led-pattern:
description: |
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 33/38] dt-bindings: memory-controller: Document Tegra132 EMC
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (31 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 32/38] dt-bindings: leds: Document rfkill* trigger Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:18 ` [PATCH 34/38] dt-bindings: memory-controller: Fix "reg" entries on Tegra194 Thierry Reding
` (4 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
Document the compatible string for the Tegra132 variant of the external
memory controller.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/memory-controllers/nvidia,tegra124-emc.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
index 278549f9e051..122134f0a08b 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
@@ -16,7 +16,9 @@ description: |
properties:
compatible:
- const: nvidia,tegra124-emc
+ enum:
+ - nvidia,tegra124-emc
+ - nvidia,tegra132-emc
reg:
maxItems: 1
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 34/38] dt-bindings: memory-controller: Fix "reg" entries on Tegra194
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (32 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 33/38] dt-bindings: memory-controller: Document Tegra132 EMC Thierry Reding
@ 2020-06-12 14:18 ` Thierry Reding
2020-06-12 14:19 ` [PATCH 35/38] dt-bindings: memory: Update Tegra210 EMC bindings Thierry Reding
` (3 subsequent siblings)
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:18 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The Tegra194 memory controller needs a couple more "reg" entries.
Document this properly so that device trees can be validated.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../nvidia,tegra186-mc.yaml | 39 ++++++++++++++-----
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
index 774b04d0da0d..b04485c5cf5f 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml
@@ -27,13 +27,15 @@ properties:
pattern: "^memory-controller@[0-9a-f]+$"
compatible:
- items:
- - enum:
- - nvidia,tegra186-mc
- - nvidia,tegra194-mc
+ oneOf:
+ - description: NVIDIA Tegra186 memory controller
+ const: nvidia,tegra186-mc
+ - description: NVIDIA Tegra194 memory controller
+ const: nvidia,tegra194-mc
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 3
interrupts:
maxItems: 1
@@ -74,12 +76,13 @@ patternProperties:
- nvidia,tegra186-emc
- nvidia,tegra194-emc
- reg:
- maxItems: 1
-
interrupts:
maxItems: 1
+ reg:
+ minItems: 1
+ maxItems: 2
+
clocks:
items:
- description: external memory clock
@@ -107,11 +110,18 @@ allOf:
properties:
compatible:
contains:
- const: nvidia,tegra194-mc
+ anyOf:
+ - const: nvidia,tegra194-mc
then:
properties:
reg:
+ minItems: 3
maxItems: 3
+ else:
+ properties:
+ reg:
+ minItems: 1
+ maxItems: 1
- if:
patternProperties:
@@ -119,13 +129,22 @@ allOf:
properties:
compatible:
contains:
- const: nvidia,tegra194-emc
+ anyOf:
+ - const: nvidia,tegra194-emc
then:
patternProperties:
"^external-memory-controller@[0-9a-f]+$":
properties:
reg:
+ minItems: 2
maxItems: 2
+ else:
+ patternProperties:
+ "^external-memory-controller@[0-9a-f]+$":
+ properties:
+ reg:
+ minItems: 1
+ maxItems: 1
examples:
- |
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 35/38] dt-bindings: memory: Update Tegra210 EMC bindings
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (33 preceding siblings ...)
2020-06-12 14:18 ` [PATCH 34/38] dt-bindings: memory-controller: Fix "reg" entries on Tegra194 Thierry Reding
@ 2020-06-12 14:19 ` Thierry Reding
2020-06-18 15:36 ` Rob Herring
2020-06-12 14:19 ` [PATCH 36/38] dt-bindings: power: supply: sbs-battery: Document TI BQ20Z45 compatible Thierry Reding
` (2 subsequent siblings)
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:19 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The Tegra210 EMC is a cooling device because it can throttle the EMC
frequency if the chip gets too hot. The device tree node therefore needs
to contain the "#cooling-cells" property. Furthermore, multiple reserved
memory regions can now be attached to the EMC device tree node, and the
new memory-region-names property can be used to differentiate between
them.
While at it, update the example to make it more fully-featured.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../nvidia,tegra210-emc.yaml | 34 ++++++++++++++-----
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
index 49ab09252e52..4e8f659f1a7c 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
@@ -34,16 +34,25 @@ properties:
- description: EMC general interrupt
memory-region:
- $ref: /schemas/types.yaml#/definitions/phandle
- description:
- phandle to a reserved memory region describing the table of EMC
- frequencies trained by the firmware
+ description: List of phandles to reserved memory regions describing the
+ nominal and derated tables of EMC frequencies trained by the firmware.
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ memory-region-names:
+ $ref: "/schemas/types.yaml#/definitions/string-array"
+ items:
+ - const: nominal
+ - const: derated
nvidia,memory-controller:
- $ref: /schemas/types.yaml#/definitions/phandle
+ $ref: "/schemas/types.yaml#/definitions/phandle"
description:
phandle of the memory controller node
+ "#cooling-cells":
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ const: 2
+
required:
- compatible
- reg
@@ -51,7 +60,10 @@ required:
- clock-names
- nvidia,memory-controller
-additionalProperties: false
+dependencies:
+ memory-region-names: [ memory-region ]
+
+unevaluatedProperties: false
examples:
- |
@@ -63,10 +75,15 @@ examples:
#size-cells = <1>;
ranges;
- emc_table: emc-table@83400000 {
+ nominal: emc-table@83400000 {
compatible = "nvidia,tegra210-emc-table";
reg = <0x83400000 0x10000>;
};
+
+ derated: emc-table@83410000 {
+ compatible = "nvidia,tegar210-emc-table";
+ reg = <0x83410000 0x10000>;
+ };
};
external-memory-controller@7001b000 {
@@ -77,6 +94,7 @@ examples:
clocks = <&tegra_car TEGRA210_CLK_EMC>;
clock-names = "emc";
interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
- memory-region = <&emc_table>;
+ memory-region-names = "nominal", "derated";
+ memory-region = <&nominal>, <&derated>;
nvidia,memory-controller = <&mc>;
};
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 35/38] dt-bindings: memory: Update Tegra210 EMC bindings
2020-06-12 14:19 ` [PATCH 35/38] dt-bindings: memory: Update Tegra210 EMC bindings Thierry Reding
@ 2020-06-18 15:36 ` Rob Herring
0 siblings, 0 replies; 76+ messages in thread
From: Rob Herring @ 2020-06-18 15:36 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:19:00PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The Tegra210 EMC is a cooling device because it can throttle the EMC
> frequency if the chip gets too hot. The device tree node therefore needs
> to contain the "#cooling-cells" property. Furthermore, multiple reserved
> memory regions can now be attached to the EMC device tree node, and the
> new memory-region-names property can be used to differentiate between
> them.
>
> While at it, update the example to make it more fully-featured.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../nvidia,tegra210-emc.yaml | 34 ++++++++++++++-----
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
> index 49ab09252e52..4e8f659f1a7c 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
> +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.yaml
> @@ -34,16 +34,25 @@ properties:
> - description: EMC general interrupt
>
> memory-region:
> - $ref: /schemas/types.yaml#/definitions/phandle
> - description:
> - phandle to a reserved memory region describing the table of EMC
> - frequencies trained by the firmware
> + description: List of phandles to reserved memory regions describing the
> + nominal and derated tables of EMC frequencies trained by the firmware.
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> +
> + memory-region-names:
> + $ref: "/schemas/types.yaml#/definitions/string-array"
*-names has a type, so can be dropped.
> + items:
> + - const: nominal
> + - const: derated
>
> nvidia,memory-controller:
> - $ref: /schemas/types.yaml#/definitions/phandle
> + $ref: "/schemas/types.yaml#/definitions/phandle"
Quotes aren't needed here. (We haven't been consistent on this).
> description:
> phandle of the memory controller node
>
> + "#cooling-cells":
> + $ref: "/schemas/types.yaml#/definitions/uint32"
> + const: 2
> +
> required:
> - compatible
> - reg
> @@ -51,7 +60,10 @@ required:
> - clock-names
> - nvidia,memory-controller
>
> -additionalProperties: false
> +dependencies:
> + memory-region-names: [ memory-region ]
The core schema should handle this (probably needs to be added).
> +
> +unevaluatedProperties: false
>
> examples:
> - |
> @@ -63,10 +75,15 @@ examples:
> #size-cells = <1>;
> ranges;
>
> - emc_table: emc-table@83400000 {
> + nominal: emc-table@83400000 {
> compatible = "nvidia,tegra210-emc-table";
> reg = <0x83400000 0x10000>;
> };
> +
> + derated: emc-table@83410000 {
> + compatible = "nvidia,tegar210-emc-table";
> + reg = <0x83410000 0x10000>;
> + };
> };
>
> external-memory-controller@7001b000 {
> @@ -77,6 +94,7 @@ examples:
> clocks = <&tegra_car TEGRA210_CLK_EMC>;
> clock-names = "emc";
> interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
> - memory-region = <&emc_table>;
> + memory-region-names = "nominal", "derated";
> + memory-region = <&nominal>, <&derated>;
> nvidia,memory-controller = <&mc>;
> };
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 36/38] dt-bindings: power: supply: sbs-battery: Document TI BQ20Z45 compatible
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (34 preceding siblings ...)
2020-06-12 14:19 ` [PATCH 35/38] dt-bindings: memory: Update Tegra210 EMC bindings Thierry Reding
@ 2020-06-12 14:19 ` Thierry Reding
2020-06-12 14:19 ` [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml Thierry Reding
2020-06-12 14:19 ` [PATCH 38/38] dt-bindings: serial: Document Tegra-specific properties Thierry Reding
37 siblings, 0 replies; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:19 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
The TI BQ20Z45 battery is used for example on Tegra114 Dalmore but was
never documented. Add the missing compatible string.
While at it, also pull in the power-supply.yaml core bindings so that
the standard power-supplies property is properly validated. Also switch
to unevaluatedProperties to make sure the power-supply.yaml snippet is
properly validated against (additionalProperties doesn't have visibility
across a $ref).
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/power/supply/sbs,sbs-battery.yaml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml b/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml
index 205bc826bd20..bb2803850ea6 100644
--- a/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml
+++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml
@@ -18,6 +18,7 @@ properties:
oneOf:
- items:
- enum:
+ - ti,bq20z45
- ti,bq20z65
- ti,bq20z75
- enum:
@@ -62,7 +63,10 @@ required:
- compatible
- reg
-additionalProperties: false
+allOf:
+ - $ref: power-supply.yaml#
+
+unevaluatedProperties: false
examples:
- |
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (35 preceding siblings ...)
2020-06-12 14:19 ` [PATCH 36/38] dt-bindings: power: supply: sbs-battery: Document TI BQ20Z45 compatible Thierry Reding
@ 2020-06-12 14:19 ` Thierry Reding
2020-06-18 2:51 ` Rob Herring
2020-06-12 14:19 ` [PATCH 38/38] dt-bindings: serial: Document Tegra-specific properties Thierry Reding
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:19 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
For PWM controller device tree bindings, make sure that they include the
pwm.yaml controller core bindings explicitly. This prevents the tooling
from matching on the $nodename pattern, which can falsely match things
like pinmux nodes, etc.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/pwm/allwinner,sun4i-a10-pwm.yaml | 51 ++++++++++---------
.../bindings/pwm/google,cros-ec-pwm.yaml | 4 +-
.../devicetree/bindings/pwm/iqs620a-pwm.yaml | 4 +-
.../devicetree/bindings/pwm/pwm-samsung.yaml | 1 -
.../devicetree/bindings/pwm/pwm.yaml | 2 +
.../bindings/pwm/renesas,pwm-rcar.yaml | 4 +-
.../bindings/pwm/renesas,tpu-pwm.yaml | 4 +-
7 files changed, 40 insertions(+), 30 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
index 7dcab2bf8128..0a7e70114af0 100644
--- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
@@ -50,33 +50,34 @@ properties:
resets:
maxItems: 1
-if:
- properties:
- compatible:
- contains:
- const: allwinner,sun50i-h6-pwm
-
-then:
- properties:
- clocks:
- maxItems: 2
-
- clock-names:
- items:
- - const: mod
- - const: bus
-
- required:
- - clock-names
- - resets
-
-else:
- properties:
- clocks:
- maxItems: 1
+allOf:
+ - $ref: pwm.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: allwinner,sun50i-h6-pwm
+
+ then:
+ properties:
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: mod
+ - const: bus
+
+ required:
+ - clock-names
+ - resets
+
+ else:
+ properties:
+ clocks:
+ maxItems: 1
required:
- - "#pwm-cells"
- compatible
- reg
- clocks
diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml
index 41ece1d85315..a5a1e4f3df48 100644
--- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml
@@ -25,7 +25,9 @@ properties:
required:
- compatible
- - '#pwm-cells'
+
+allOf:
+ - $ref: pwm.yaml#
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml b/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml
index 1d7c27be50da..a375cc9e8fd0 100644
--- a/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml
@@ -25,7 +25,9 @@ properties:
required:
- compatible
- - "#pwm-cells"
+
+allOf:
+ - $ref: pwm.yaml#
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
index fc799b0577d4..e1487194d9a7 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
@@ -89,7 +89,6 @@ required:
- clock-names
- compatible
- interrupts
- - "#pwm-cells"
- reg
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml
index fa4f9de92090..b0ebd2881a91 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm.yaml
@@ -9,6 +9,8 @@ title: PWM controllers (providers)
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
+select: false
+
properties:
$nodename:
pattern: "^pwm(@.*|-[0-9a-f])*$"
diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
index daadde9ff9c4..d2cc1226f309 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
+++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml
@@ -57,9 +57,11 @@ properties:
required:
- compatible
- reg
- - '#pwm-cells'
- clocks
+allOf:
+ - $ref: pwm.yaml#
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml
index 4bf62a3d5bba..0db96f38ab0a 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml
@@ -56,7 +56,9 @@ properties:
required:
- compatible
- reg
- - '#pwm-cells'
+
+allOf:
+ - $ref: pwm.yaml#
additionalProperties: false
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml
2020-06-12 14:19 ` [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml Thierry Reding
@ 2020-06-18 2:51 ` Rob Herring
2020-06-19 7:46 ` Thierry Reding
0 siblings, 1 reply; 76+ messages in thread
From: Rob Herring @ 2020-06-18 2:51 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:19:02PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> For PWM controller device tree bindings, make sure that they include the
> pwm.yaml controller core bindings explicitly. This prevents the tooling
> from matching on the $nodename pattern, which can falsely match things
> like pinmux nodes, etc.
My preference here is to clean-up the mess that is pinmux nodes.
This has the side effect of no longer checking pwm nodes that didn't
have explicit schema. Perhaps that's of somewhat limited value.
Rob
^ permalink raw reply [flat|nested] 76+ messages in thread
* Re: [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml
2020-06-18 2:51 ` Rob Herring
@ 2020-06-19 7:46 ` Thierry Reding
2020-06-19 18:05 ` Rob Herring
0 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-19 7:46 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
[-- Attachment #1: Type: text/plain, Size: 5747 bytes --]
On Wed, Jun 17, 2020 at 08:51:40PM -0600, Rob Herring wrote:
> On Fri, Jun 12, 2020 at 04:19:02PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > For PWM controller device tree bindings, make sure that they include the
> > pwm.yaml controller core bindings explicitly. This prevents the tooling
> > from matching on the $nodename pattern, which can falsely match things
> > like pinmux nodes, etc.
>
> My preference here is to clean-up the mess that is pinmux nodes.
Any suggestions on how to do that? Do you just want to rename the
problematic nodes? Or do you want to introduce a standard naming scheme?
As an example, I was running into the issue with this node:
pinmux@70000014 {
pinctrl-names = "default";
pinctrl-0 = <&state_default>;
state_default: pinmux {
...
pwm-a-b {
nvidia,pins = "sdc";
nvidia,function = "pwm";
nvidia,tristate = <TEGRA_PIN_ENABLE>;
};
...
};
};
My first instinct was to just add some sort of prefix to this, but then
I realized that might not be the best option because there could be
countless other nodes whose names might start with "pwm-" but that had
nothing to do with PWM controllers whatsoever.
You could for example have some node named "pwm-fan" and then these
standard bindings will require that to be have a #pwm-cells property.
So I think the solution of only explicitly "activating" PWM controller
bindings would work well in this particular case because it would only
apply the bindings where explicitly requested. That way it doesn't
matter what nodes are named.
> This has the side effect of no longer checking pwm nodes that didn't
> have explicit schema. Perhaps that's of somewhat limited value.
There are two easy solutions to this: 1) convert all PWM bindings to
YAML so that they have an explicit schema or 2) consider the presence of
the #pwm-cells property as a marker that the node represents a PWM
controller/provider, irrespective of the name. The latter would be much
like gpio-controller or interrupt-controller, though less redundant.
We could even go as far as using #pwm-cells as the definitive marker and
then require that it has a certain name, like we do for other types of
nodes. I did a quick audit and came up with the following results. These
are all the PWM controller nodes that I could find that don't follow the
"^pwm(@.*)?$" pattern. The files are only one example of where I found
them and there were often others that used the same pattern.
- arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
- ec-pwm
It should be trivial to rename these to just "pwm" since I don't
see the cros-ec driver relying on the exact name.
- arch/arm/boot/dts/am5729-beagleboneai.dts
- stmpe_pwm
The stmpe MFD driver actually relies on this name, so not sure if
there's a lot we can do about that.
- arch/arm/boot/dts/armada-38x.dtsi
- gpio@...
This is both a GPIO and PWM controller, so can't really do much
about the name.
- arch/arm/boot/dts/at91-kizbox.dts
- pwm
Actually also matches the pattern because the '@.*' part is
optional.
- arch/arm/boot/dts/at91sam9n12.dtsi
- hlcdc-pwm
The MFD driver matches on the compatible string, so we should be
able to just rename this to "pwm".
- arch/arm/boot/dts/da850.dtsi
- ecap@...
No matching on the name as far as I can tell, so we should be able
to rename this 'pwm@...'.
- arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi
- dmtimer-pwm
Could probably be renamed 'pwm'.
- arch/arm/boot/dts/lpc32xx.dtsi
- mpwm@...
Could probably be renamed 'pwm'.
- arch/arm/boot/dts/motorola-mapphone-common.dtsi
- dmtimer-pwm-*
Maybe these should be renamed 'pwm@*' instead?
- arch/arm/boot/dts/s3c24xx.dtsi
- timer@...
This is a variant similar to dmtimer-pwm above and is driven by a
timer that can run in PWM mode. I think this is the same category
as the GPIO/PWM controller hybrid above.
Not much we can do about the name.
- arch/arm/boot/dts/stm32f429.dtsi
- pwm
Matches the pattern.
- arch/arm/boot/dts/twl4030.dtsi
- pwm
Matches the pattern.
- pwmled
Perhaps both of the above should be named 'pwm@*'? There doesn't
seem to be any matching on the name.
For many of the above it should be possible to rename them. But then we
will always have exceptions where we can't do that because then it might
conflict with other bindings.
Two interesting things I gathered from the above are that:
1) nothing in the above actually matches the pwm-* variant that's part
of the current pattern defined in pwm.yaml and which is causing the
problem for the pinmux nodes, so an easy solution would be to
simply drop that part of the pattern since it is useless anyway.
2) There are actually quite a few PWM controllers that currently are
not checked because of the name matching. Now I haven't actually
checked the reverse, i.e. to see if all nodes matching the pattern
actually have a #pwm-cells property, but given that we miss a
number of controller because they don't match the pattern makes me
think that that aspect isn't actually very helpful.
All of the above makes me think even more that we should just abandon
the idea of matching on the names for PWM controller because in some
instances we can't change the name for backwards-compatibility or
because the names would then conflict with other bindings.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 76+ messages in thread* Re: [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml
2020-06-19 7:46 ` Thierry Reding
@ 2020-06-19 18:05 ` Rob Herring
0 siblings, 0 replies; 76+ messages in thread
From: Rob Herring @ 2020-06-19 18:05 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 19, 2020 at 1:47 AM Thierry Reding <thierry.reding@gmail.com> wrote:
>
> On Wed, Jun 17, 2020 at 08:51:40PM -0600, Rob Herring wrote:
> > On Fri, Jun 12, 2020 at 04:19:02PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > >
> > > For PWM controller device tree bindings, make sure that they include the
> > > pwm.yaml controller core bindings explicitly. This prevents the tooling
> > > from matching on the $nodename pattern, which can falsely match things
> > > like pinmux nodes, etc.
> >
> > My preference here is to clean-up the mess that is pinmux nodes.
>
> Any suggestions on how to do that? Do you just want to rename the
> problematic nodes? Or do you want to introduce a standard naming scheme?
.*-pins$ is what I've been using/proposing. Doing that also helps
writing pinctrl schemas.
> As an example, I was running into the issue with this node:
>
> pinmux@70000014 {
> pinctrl-names = "default";
> pinctrl-0 = <&state_default>;
>
> state_default: pinmux {
> ...
>
> pwm-a-b {
> nvidia,pins = "sdc";
> nvidia,function = "pwm";
> nvidia,tristate = <TEGRA_PIN_ENABLE>;
> };
>
> ...
> };
> };
>
> My first instinct was to just add some sort of prefix to this, but then
> I realized that might not be the best option because there could be
> countless other nodes whose names might start with "pwm-" but that had
> nothing to do with PWM controllers whatsoever.
>
> You could for example have some node named "pwm-fan" and then these
> standard bindings will require that to be have a #pwm-cells property.
Pretty sure we only allow pwm@.* or pwm-[0-9a-f]+, so this would not match.
Plus shouldn't it be just 'fan' to be what the class is, not how it is
implemented/controlled.
> So I think the solution of only explicitly "activating" PWM controller
> bindings would work well in this particular case because it would only
> apply the bindings where explicitly requested. That way it doesn't
> matter what nodes are named.
>
> > This has the side effect of no longer checking pwm nodes that didn't
> > have explicit schema. Perhaps that's of somewhat limited value.
>
> There are two easy solutions to this: 1) convert all PWM bindings to
> YAML so that they have an explicit schema or 2) consider the presence of
> the #pwm-cells property as a marker that the node represents a PWM
> controller/provider, irrespective of the name. The latter would be much
> like gpio-controller or interrupt-controller, though less redundant.
There's only 2 things we can generically check, #pwm-cells and the
node name. If we match on one, then we're really only checking the
other one. We could match on #pwm-cells presence and then check its
value is 2 or 3, but then we can do that without a select (i.e. always
apply the schema).
So I guess I'm convinced there's not much value here and we should
just do 1). Patches welcome. :) (BTW, I do think we should do some
mass conversions by class. That I think would be a bit more efficient
in both converting and reviewing. My calculation is something like 6
years to finish (3K bindings left and doing 100-150 a cycle).)
> We could even go as far as using #pwm-cells as the definitive marker and
> then require that it has a certain name, like we do for other types of
> nodes. I did a quick audit and came up with the following results. These
> are all the PWM controller nodes that I could find that don't follow the
> "^pwm(@.*)?$" pattern. The files are only one example of where I found
> them and there were often others that used the same pattern.
>
> - arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi
> - ec-pwm
>
> It should be trivial to rename these to just "pwm" since I don't
> see the cros-ec driver relying on the exact name.
>
> - arch/arm/boot/dts/am5729-beagleboneai.dts
> - stmpe_pwm
>
> The stmpe MFD driver actually relies on this name, so not sure if
> there's a lot we can do about that.
That's unfortunate...
The question is how do we allow this, but at the same time prevent more cases.
> - arch/arm/boot/dts/armada-38x.dtsi
> - gpio@...
>
> This is both a GPIO and PWM controller, so can't really do much
> about the name.
In general, we need some solution for the more than 1 function nodes.
Combo clock and reset controllers are a common one.
> - arch/arm/boot/dts/at91-kizbox.dts
> - pwm
>
> Actually also matches the pattern because the '@.*' part is
> optional.
>
> - arch/arm/boot/dts/at91sam9n12.dtsi
> - hlcdc-pwm
>
> The MFD driver matches on the compatible string, so we should be
> able to just rename this to "pwm".
>
> - arch/arm/boot/dts/da850.dtsi
> - ecap@...
>
> No matching on the name as far as I can tell, so we should be able
> to rename this 'pwm@...'.
>
> - arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi
> - dmtimer-pwm
>
> Could probably be renamed 'pwm'.
>
> - arch/arm/boot/dts/lpc32xx.dtsi
> - mpwm@...
>
> Could probably be renamed 'pwm'.
>
> - arch/arm/boot/dts/motorola-mapphone-common.dtsi
> - dmtimer-pwm-*
>
> Maybe these should be renamed 'pwm@*' instead?
>
> - arch/arm/boot/dts/s3c24xx.dtsi
> - timer@...
>
> This is a variant similar to dmtimer-pwm above and is driven by a
> timer that can run in PWM mode. I think this is the same category
> as the GPIO/PWM controller hybrid above.
>
> Not much we can do about the name.
>
> - arch/arm/boot/dts/stm32f429.dtsi
> - pwm
>
> Matches the pattern.
>
> - arch/arm/boot/dts/twl4030.dtsi
> - pwm
>
> Matches the pattern.
>
> - pwmled
>
> Perhaps both of the above should be named 'pwm@*'? There doesn't
> seem to be any matching on the name.
>
> For many of the above it should be possible to rename them. But then we
> will always have exceptions where we can't do that because then it might
> conflict with other bindings.
>
> Two interesting things I gathered from the above are that:
>
> 1) nothing in the above actually matches the pwm-* variant that's part
> of the current pattern defined in pwm.yaml and which is causing the
> problem for the pinmux nodes, so an easy solution would be to
> simply drop that part of the pattern since it is useless anyway.
>
> 2) There are actually quite a few PWM controllers that currently are
> not checked because of the name matching. Now I haven't actually
> checked the reverse, i.e. to see if all nodes matching the pattern
> actually have a #pwm-cells property, but given that we miss a
> number of controller because they don't match the pattern makes me
> think that that aspect isn't actually very helpful.
>
> All of the above makes me think even more that we should just abandon
> the idea of matching on the names for PWM controller because in some
> instances we can't change the name for backwards-compatibility or
> because the names would then conflict with other bindings.
Yes. :(
Maybe node name checks can be an optional thing to enable until we
come up with a more general way to opt-in/out of specific checks.
Rob
^ permalink raw reply [flat|nested] 76+ messages in thread
* [PATCH 38/38] dt-bindings: serial: Document Tegra-specific properties
2020-06-12 14:18 [PATCH 00/38] dt-bindings: json-schema conversions and cleanups Thierry Reding
` (36 preceding siblings ...)
2020-06-12 14:19 ` [PATCH 37/38] dt-bindings: pwm: Explicitly include pwm.yaml Thierry Reding
@ 2020-06-12 14:19 ` Thierry Reding
2020-06-18 2:47 ` Rob Herring
37 siblings, 1 reply; 76+ messages in thread
From: Thierry Reding @ 2020-06-12 14:19 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree, linux-tegra
From: Thierry Reding <treding@nvidia.com>
On Tegra the UART is described using additional properties, such as
clock-names, reset-names, dmas and dma-names. Document them in the
bindings so that Tegra device trees are properly validated.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../devicetree/bindings/serial/8250.yaml | 26 +++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index c1d4c196f005..9c8fad27c3f3 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -28,6 +28,32 @@ allOf:
const: 2
required:
- reg-shift
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra20-uart
+ then:
+ properties:
+ clock-names:
+ $ref: "/schemas/types.yaml#/definitions/string-array"
+ items:
+ - const: serial
+
+ dmas:
+ $ref: "/schemas/types.yaml#/definitions/phandle-array"
+
+ dma-names:
+ $ref: "/schemas/types.yaml#/definitions/string-array"
+ items:
+ - const: rx
+ - const: tx
+
+ reset-names:
+ $ref: "/schemas/types.yaml#/definitions/string-array"
+ items:
+ - const: serial
- if:
not:
properties:
--
2.24.1
^ permalink raw reply related [flat|nested] 76+ messages in thread* Re: [PATCH 38/38] dt-bindings: serial: Document Tegra-specific properties
2020-06-12 14:19 ` [PATCH 38/38] dt-bindings: serial: Document Tegra-specific properties Thierry Reding
@ 2020-06-18 2:47 ` Rob Herring
0 siblings, 0 replies; 76+ messages in thread
From: Rob Herring @ 2020-06-18 2:47 UTC (permalink / raw)
To: Thierry Reding; +Cc: devicetree, linux-tegra
On Fri, Jun 12, 2020 at 04:19:03PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> On Tegra the UART is described using additional properties, such as
> clock-names, reset-names, dmas and dma-names. Document them in the
> bindings so that Tegra device trees are properly validated.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../devicetree/bindings/serial/8250.yaml | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
> index c1d4c196f005..9c8fad27c3f3 100644
> --- a/Documentation/devicetree/bindings/serial/8250.yaml
> +++ b/Documentation/devicetree/bindings/serial/8250.yaml
> @@ -28,6 +28,32 @@ allOf:
> const: 2
> required:
> - reg-shift
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra20-uart
Can use 'const' here instead.
> + then:
> + properties:
> + clock-names:
> + $ref: "/schemas/types.yaml#/definitions/string-array"
Don't need type.
> + items:
> + - const: serial
> +
> + dmas:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
How many?
> +
> + dma-names:
> + $ref: "/schemas/types.yaml#/definitions/string-array"
> + items:
> + - const: rx
> + - const: tx
> +
> + reset-names:
> + $ref: "/schemas/types.yaml#/definitions/string-array"
> + items:
> + - const: serial
> - if:
> not:
> properties:
> --
> 2.24.1
>
^ permalink raw reply [flat|nested] 76+ messages in thread