* [PATCH v3 0/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-02 20:36 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-02 20:36 UTC (permalink / raw)
To: devicetree, Sameer Pujar, Laurent Pinchart
Cc: dri-devel, linux-kernel, Thierry Reding, Sam Ravnborg,
Philipp Zabel, kuninori.morimoto.gx, Jacopo Mondi
Sameer, I wanted to experiment with what the interface for graph users
looks like, so I've tweaked your patch a bit and converted 2 users.
This series converts the DT graph binding to a schema. Users of the graph
binding should reference the schema from 'ports' or 'port' node. Users
will still need to define what each port node is and any additional
properties that appear in port or endpoint nodes.
I'm still considering whether to apply graph.yaml to the dtschema repo
instead. Then I can sync adding it with a meta-schema update to check
for a reference.
Rob
Rob Herring (2):
dt-bindings: usb-connector: Add reference to graph schema
dt-bindings: panel: common: Add reference to graph schema
Sameer Pujar (1):
dt-bindings: Convert graph bindings to json-schema
.../bindings/connector/usb-connector.yaml | 10 +-
.../bindings/display/panel/panel-common.yaml | 7 +-
Documentation/devicetree/bindings/graph.txt | 129 +-----------
Documentation/devicetree/bindings/graph.yaml | 199 ++++++++++++++++++
4 files changed, 209 insertions(+), 136 deletions(-)
create mode 100644 Documentation/devicetree/bindings/graph.yaml
--
2.25.1
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3 0/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-02 20:36 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-02 20:36 UTC (permalink / raw)
To: devicetree, Sameer Pujar, Laurent Pinchart
Cc: kuninori.morimoto.gx, linux-kernel, dri-devel, Thierry Reding,
Jacopo Mondi, Sam Ravnborg
Sameer, I wanted to experiment with what the interface for graph users
looks like, so I've tweaked your patch a bit and converted 2 users.
This series converts the DT graph binding to a schema. Users of the graph
binding should reference the schema from 'ports' or 'port' node. Users
will still need to define what each port node is and any additional
properties that appear in port or endpoint nodes.
I'm still considering whether to apply graph.yaml to the dtschema repo
instead. Then I can sync adding it with a meta-schema update to check
for a reference.
Rob
Rob Herring (2):
dt-bindings: usb-connector: Add reference to graph schema
dt-bindings: panel: common: Add reference to graph schema
Sameer Pujar (1):
dt-bindings: Convert graph bindings to json-schema
.../bindings/connector/usb-connector.yaml | 10 +-
.../bindings/display/panel/panel-common.yaml | 7 +-
Documentation/devicetree/bindings/graph.txt | 129 +-----------
Documentation/devicetree/bindings/graph.yaml | 199 ++++++++++++++++++
4 files changed, 209 insertions(+), 136 deletions(-)
create mode 100644 Documentation/devicetree/bindings/graph.yaml
--
2.25.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-02 20:36 ` Rob Herring
-1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-02 20:36 UTC (permalink / raw)
To: devicetree, Sameer Pujar, Laurent Pinchart
Cc: dri-devel, linux-kernel, Thierry Reding, Sam Ravnborg,
Philipp Zabel, kuninori.morimoto.gx, Jacopo Mondi
From: Sameer Pujar <spujar@nvidia.com>
Convert device tree bindings of graph to YAML format. Currently graph.txt
doc is referenced in multiple files and all of these need to use schema
references. For now graph.txt is updated to refer to graph.yaml.
For users of the graph binding, they should reference to the graph
schema from either 'ports' or 'port' property:
properties:
ports:
type: object
$ref: graph.yaml#/properties/ports
properties:
port@0:
description: What data this port has
...
Or:
properties:
port:
description: What data this port has
type: object
$ref: graph.yaml#/properties/port
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Rob Herring <robh@kernel.org>
---
v3:
- Move port 'reg' to port@* and make required
- Make remote-endpoint required
- Add 'additionalProperties: true' now required
- Fix yamllint warnings
Documentation/devicetree/bindings/graph.txt | 129 +-----------
Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
2 files changed, 200 insertions(+), 128 deletions(-)
create mode 100644 Documentation/devicetree/bindings/graph.yaml
diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/graph.txt
index 0415e2c53ba0..b7818d61cef7 100644
--- a/Documentation/devicetree/bindings/graph.txt
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -1,128 +1 @@
-Common bindings for device graphs
-
-General concept
----------------
-
-The hierarchical organisation of the device tree is well suited to describe
-control flow to devices, but there can be more complex connections between
-devices that work together to form a logical compound device, following an
-arbitrarily complex graph.
-There already is a simple directed graph between devices tree nodes using
-phandle properties pointing to other nodes to describe connections that
-can not be inferred from device tree parent-child relationships. The device
-tree graph bindings described herein abstract more complex devices that can
-have multiple specifiable ports, each of which can be linked to one or more
-ports of other devices.
-
-These common bindings do not contain any information about the direction or
-type of the connections, they just map their existence. Specific properties
-may be described by specialized bindings depending on the type of connection.
-
-To see how this binding applies to video pipelines, for example, see
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-Here the ports describe data interfaces, and the links between them are
-the connecting data buses. A single port with multiple connections can
-correspond to multiple devices being connected to the same physical bus.
-
-Organisation of ports and endpoints
------------------------------------
-
-Ports are described by child 'port' nodes contained in the device node.
-Each port node contains an 'endpoint' subnode for each remote device port
-connected to this port. If a single port is connected to more than one
-remote device, an 'endpoint' child node must be provided for each link.
-If more than one port is present in a device node or there is more than one
-endpoint at a port, or a port node needs to be associated with a selected
-hardware interface, a common scheme using '#address-cells', '#size-cells'
-and 'reg' properties is used to number the nodes.
-
-device {
- ...
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
-
- endpoint@0 {
- reg = <0>;
- ...
- };
- endpoint@1 {
- reg = <1>;
- ...
- };
- };
-
- port@1 {
- reg = <1>;
-
- endpoint { ... };
- };
-};
-
-All 'port' nodes can be grouped under an optional 'ports' node, which
-allows to specify #address-cells, #size-cells properties for the 'port'
-nodes independently from any other child device nodes a device might
-have.
-
-device {
- ...
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- ...
- endpoint@0 { ... };
- endpoint@1 { ... };
- };
-
- port@1 { ... };
- };
-};
-
-Links between endpoints
------------------------
-
-Each endpoint should contain a 'remote-endpoint' phandle property that points
-to the corresponding endpoint in the port of the remote device. In turn, the
-remote endpoint should contain a 'remote-endpoint' property. If it has one, it
-must not point to anything other than the local endpoint. Two endpoints with
-their 'remote-endpoint' phandles pointing at each other form a link between the
-containing ports.
-
-device-1 {
- port {
- device_1_output: endpoint {
- remote-endpoint = <&device_2_input>;
- };
- };
-};
-
-device-2 {
- port {
- device_2_input: endpoint {
- remote-endpoint = <&device_1_output>;
- };
- };
-};
-
-Required properties
--------------------
-
-If there is more than one 'port' or more than one 'endpoint' node or 'reg'
-property present in the port and/or endpoint nodes then the following
-properties are required in a relevant parent node:
-
- - #address-cells : number of cells required to define port/endpoint
- identifier, should be 1.
- - #size-cells : should be zero.
-
-Optional endpoint properties
-----------------------------
-
-- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
-
+This file has moved to graph.yaml
diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
new file mode 100644
index 000000000000..b56720c5a13e
--- /dev/null
+++ b/Documentation/devicetree/bindings/graph.yaml
@@ -0,0 +1,199 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/graph.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common bindings for device graphs
+
+description: |
+ The hierarchical organisation of the device tree is well suited to describe
+ control flow to devices, but there can be more complex connections between
+ devices that work together to form a logical compound device, following an
+ arbitrarily complex graph.
+ There already is a simple directed graph between devices tree nodes using
+ phandle properties pointing to other nodes to describe connections that
+ can not be inferred from device tree parent-child relationships. The device
+ tree graph bindings described herein abstract more complex devices that can
+ have multiple specifiable ports, each of which can be linked to one or more
+ ports of other devices.
+
+ These common bindings do not contain any information about the direction or
+ type of the connections, they just map their existence. Specific properties
+ may be described by specialized bindings depending on the type of connection.
+
+ To see how this binding applies to video pipelines, for example, see
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ Here the ports describe data interfaces, and the links between them are
+ the connecting data buses. A single port with multiple connections can
+ correspond to multiple devices being connected to the same physical bus.
+
+maintainers:
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+select: false
+
+properties:
+ port:
+ type: object
+ description:
+ If there is more than one endpoint node or 'reg' property present in
+ endpoint nodes then '#address-cells' and '#size-cells' properties are
+ required.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^endpoint(@[0-9a-f]+)?$":
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ remote-endpoint:
+ description: |
+ phandle to an 'endpoint' subnode of a remote device node.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ required:
+ - remote-endpoint
+
+ ports:
+ type: object
+ description: |
+ If there is more than one port node or 'reg' property present in port
+ nodes then '#address-cells' and '#size-cells' properties are required.
+ In such cases all port nodes can be grouped under 'ports' independently
+ from any other child device nodes a device might have.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^port(@[0-9a-f]+)?$":
+ $ref: "#/properties/port"
+ type: object
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+
+ additionalProperties: false
+
+additionalProperties: true
+
+examples:
+ # Organisation of ports and endpoints:
+ #
+ # Ports are described by child 'port' nodes contained in the device node.
+ # Each port node contains an 'endpoint' subnode for each remote device port
+ # connected to this port. If a single port is connected to more than one
+ # remote device, an 'endpoint' child node must be provided for each link.
+ # If more than one port is present in a device node or there is more than
+ # one endpoint at a port, or a port node needs to be associated with a
+ # selected hardware interface, a common scheme using '#address-cells',
+ # '#size-cells' and 'reg' properties is used to number the nodes.
+ - |
+ device {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ // ...
+ };
+ endpoint@1 {
+ reg = <1>;
+ // ...
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ // ...
+ };
+ };
+ };
+
+ # All 'port' nodes can be grouped under an optional 'ports' node, which
+ # allows to specify #address-cells, #size-cells properties for the 'port'
+ # nodes independently from any other child device nodes a device might
+ # have.
+ - |
+ device {
+ // ...
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ // ...
+
+ endpoint@0 {
+ reg = <0>;
+ // ...
+ };
+ endpoint@1 {
+ reg = <1>;
+ // ...
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ // ...
+ };
+ };
+ };
+
+ # Links between endpoints:
+ #
+ # Each endpoint should contain a 'remote-endpoint' phandle property that
+ # points to the corresponding endpoint in the port of the remote device.
+ # In turn, the remote endpoint should contain a 'remote-endpoint' property.
+ # If it has one, it must not point to anything other than the local endpoint.
+ # Two endpoints with their 'remote-endpoint' phandles pointing at each other
+ # form a link between the containing ports.
+ - |
+ device-1 {
+ port {
+ device_1_output: endpoint {
+ remote-endpoint = <&device_2_input>;
+ };
+ };
+ };
+
+ device-2 {
+ port {
+ device_2_input: endpoint {
+ remote-endpoint = <&device_1_output>;
+ };
+ };
+ };
+
+...
--
2.25.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-02 20:36 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-02 20:36 UTC (permalink / raw)
To: devicetree, Sameer Pujar, Laurent Pinchart
Cc: kuninori.morimoto.gx, linux-kernel, dri-devel, Thierry Reding,
Jacopo Mondi, Sam Ravnborg
From: Sameer Pujar <spujar@nvidia.com>
Convert device tree bindings of graph to YAML format. Currently graph.txt
doc is referenced in multiple files and all of these need to use schema
references. For now graph.txt is updated to refer to graph.yaml.
For users of the graph binding, they should reference to the graph
schema from either 'ports' or 'port' property:
properties:
ports:
type: object
$ref: graph.yaml#/properties/ports
properties:
port@0:
description: What data this port has
...
Or:
properties:
port:
description: What data this port has
type: object
$ref: graph.yaml#/properties/port
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Rob Herring <robh@kernel.org>
---
v3:
- Move port 'reg' to port@* and make required
- Make remote-endpoint required
- Add 'additionalProperties: true' now required
- Fix yamllint warnings
Documentation/devicetree/bindings/graph.txt | 129 +-----------
Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
2 files changed, 200 insertions(+), 128 deletions(-)
create mode 100644 Documentation/devicetree/bindings/graph.yaml
diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/graph.txt
index 0415e2c53ba0..b7818d61cef7 100644
--- a/Documentation/devicetree/bindings/graph.txt
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -1,128 +1 @@
-Common bindings for device graphs
-
-General concept
----------------
-
-The hierarchical organisation of the device tree is well suited to describe
-control flow to devices, but there can be more complex connections between
-devices that work together to form a logical compound device, following an
-arbitrarily complex graph.
-There already is a simple directed graph between devices tree nodes using
-phandle properties pointing to other nodes to describe connections that
-can not be inferred from device tree parent-child relationships. The device
-tree graph bindings described herein abstract more complex devices that can
-have multiple specifiable ports, each of which can be linked to one or more
-ports of other devices.
-
-These common bindings do not contain any information about the direction or
-type of the connections, they just map their existence. Specific properties
-may be described by specialized bindings depending on the type of connection.
-
-To see how this binding applies to video pipelines, for example, see
-Documentation/devicetree/bindings/media/video-interfaces.txt.
-Here the ports describe data interfaces, and the links between them are
-the connecting data buses. A single port with multiple connections can
-correspond to multiple devices being connected to the same physical bus.
-
-Organisation of ports and endpoints
------------------------------------
-
-Ports are described by child 'port' nodes contained in the device node.
-Each port node contains an 'endpoint' subnode for each remote device port
-connected to this port. If a single port is connected to more than one
-remote device, an 'endpoint' child node must be provided for each link.
-If more than one port is present in a device node or there is more than one
-endpoint at a port, or a port node needs to be associated with a selected
-hardware interface, a common scheme using '#address-cells', '#size-cells'
-and 'reg' properties is used to number the nodes.
-
-device {
- ...
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0>;
-
- endpoint@0 {
- reg = <0>;
- ...
- };
- endpoint@1 {
- reg = <1>;
- ...
- };
- };
-
- port@1 {
- reg = <1>;
-
- endpoint { ... };
- };
-};
-
-All 'port' nodes can be grouped under an optional 'ports' node, which
-allows to specify #address-cells, #size-cells properties for the 'port'
-nodes independently from any other child device nodes a device might
-have.
-
-device {
- ...
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- ...
- endpoint@0 { ... };
- endpoint@1 { ... };
- };
-
- port@1 { ... };
- };
-};
-
-Links between endpoints
------------------------
-
-Each endpoint should contain a 'remote-endpoint' phandle property that points
-to the corresponding endpoint in the port of the remote device. In turn, the
-remote endpoint should contain a 'remote-endpoint' property. If it has one, it
-must not point to anything other than the local endpoint. Two endpoints with
-their 'remote-endpoint' phandles pointing at each other form a link between the
-containing ports.
-
-device-1 {
- port {
- device_1_output: endpoint {
- remote-endpoint = <&device_2_input>;
- };
- };
-};
-
-device-2 {
- port {
- device_2_input: endpoint {
- remote-endpoint = <&device_1_output>;
- };
- };
-};
-
-Required properties
--------------------
-
-If there is more than one 'port' or more than one 'endpoint' node or 'reg'
-property present in the port and/or endpoint nodes then the following
-properties are required in a relevant parent node:
-
- - #address-cells : number of cells required to define port/endpoint
- identifier, should be 1.
- - #size-cells : should be zero.
-
-Optional endpoint properties
-----------------------------
-
-- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
-
+This file has moved to graph.yaml
diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
new file mode 100644
index 000000000000..b56720c5a13e
--- /dev/null
+++ b/Documentation/devicetree/bindings/graph.yaml
@@ -0,0 +1,199 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/graph.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common bindings for device graphs
+
+description: |
+ The hierarchical organisation of the device tree is well suited to describe
+ control flow to devices, but there can be more complex connections between
+ devices that work together to form a logical compound device, following an
+ arbitrarily complex graph.
+ There already is a simple directed graph between devices tree nodes using
+ phandle properties pointing to other nodes to describe connections that
+ can not be inferred from device tree parent-child relationships. The device
+ tree graph bindings described herein abstract more complex devices that can
+ have multiple specifiable ports, each of which can be linked to one or more
+ ports of other devices.
+
+ These common bindings do not contain any information about the direction or
+ type of the connections, they just map their existence. Specific properties
+ may be described by specialized bindings depending on the type of connection.
+
+ To see how this binding applies to video pipelines, for example, see
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+ Here the ports describe data interfaces, and the links between them are
+ the connecting data buses. A single port with multiple connections can
+ correspond to multiple devices being connected to the same physical bus.
+
+maintainers:
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+select: false
+
+properties:
+ port:
+ type: object
+ description:
+ If there is more than one endpoint node or 'reg' property present in
+ endpoint nodes then '#address-cells' and '#size-cells' properties are
+ required.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^endpoint(@[0-9a-f]+)?$":
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+
+ remote-endpoint:
+ description: |
+ phandle to an 'endpoint' subnode of a remote device node.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ required:
+ - remote-endpoint
+
+ ports:
+ type: object
+ description: |
+ If there is more than one port node or 'reg' property present in port
+ nodes then '#address-cells' and '#size-cells' properties are required.
+ In such cases all port nodes can be grouped under 'ports' independently
+ from any other child device nodes a device might have.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^port(@[0-9a-f]+)?$":
+ $ref: "#/properties/port"
+ type: object
+
+ properties:
+ reg:
+ maxItems: 1
+
+ required:
+ - reg
+
+
+ additionalProperties: false
+
+additionalProperties: true
+
+examples:
+ # Organisation of ports and endpoints:
+ #
+ # Ports are described by child 'port' nodes contained in the device node.
+ # Each port node contains an 'endpoint' subnode for each remote device port
+ # connected to this port. If a single port is connected to more than one
+ # remote device, an 'endpoint' child node must be provided for each link.
+ # If more than one port is present in a device node or there is more than
+ # one endpoint at a port, or a port node needs to be associated with a
+ # selected hardware interface, a common scheme using '#address-cells',
+ # '#size-cells' and 'reg' properties is used to number the nodes.
+ - |
+ device {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ endpoint@0 {
+ reg = <0>;
+ // ...
+ };
+ endpoint@1 {
+ reg = <1>;
+ // ...
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ // ...
+ };
+ };
+ };
+
+ # All 'port' nodes can be grouped under an optional 'ports' node, which
+ # allows to specify #address-cells, #size-cells properties for the 'port'
+ # nodes independently from any other child device nodes a device might
+ # have.
+ - |
+ device {
+ // ...
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ // ...
+
+ endpoint@0 {
+ reg = <0>;
+ // ...
+ };
+ endpoint@1 {
+ reg = <1>;
+ // ...
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ // ...
+ };
+ };
+ };
+
+ # Links between endpoints:
+ #
+ # Each endpoint should contain a 'remote-endpoint' phandle property that
+ # points to the corresponding endpoint in the port of the remote device.
+ # In turn, the remote endpoint should contain a 'remote-endpoint' property.
+ # If it has one, it must not point to anything other than the local endpoint.
+ # Two endpoints with their 'remote-endpoint' phandles pointing at each other
+ # form a link between the containing ports.
+ - |
+ device-1 {
+ port {
+ device_1_output: endpoint {
+ remote-endpoint = <&device_2_input>;
+ };
+ };
+ };
+
+ device-2 {
+ port {
+ device_2_input: endpoint {
+ remote-endpoint = <&device_1_output>;
+ };
+ };
+ };
+
+...
--
2.25.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3 2/3] dt-bindings: usb-connector: Add reference to graph schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-02 20:36 ` Rob Herring
-1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-02 20:36 UTC (permalink / raw)
To: devicetree, Sameer Pujar, Laurent Pinchart
Cc: dri-devel, linux-kernel, Thierry Reding, Sam Ravnborg,
Philipp Zabel, kuninori.morimoto.gx, Jacopo Mondi
Now that we have a graph schema, reference it from the usb-connector
schema.
Signed-off-by: Rob Herring <robh@kernel.org>
---
v3: new patch
.../devicetree/bindings/connector/usb-connector.yaml | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index 728f82db073d..64f2e1246ddb 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -125,11 +125,13 @@ properties:
power dual role.
ports:
- description: OF graph bindings (specified in bindings/graph.txt) that model
- any data bus to the connector unless the bus is between parent node and
- the connector. Since a single connector can have multiple data buses every
- bus has an assigned OF graph port number as described below.
+ $ref: /schemas/graph.yaml#/properties/ports
type: object
+ description: OF graph bindings modeling any data bus to the connector
+ unless the bus is between parent node and the connector. Since a single
+ connector can have multiple data buses every bus has an assigned OF graph
+ port number as described below.
+
properties:
port@0:
type: object
--
2.25.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3 2/3] dt-bindings: usb-connector: Add reference to graph schema
@ 2020-11-02 20:36 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-02 20:36 UTC (permalink / raw)
To: devicetree, Sameer Pujar, Laurent Pinchart
Cc: kuninori.morimoto.gx, linux-kernel, dri-devel, Thierry Reding,
Jacopo Mondi, Sam Ravnborg
Now that we have a graph schema, reference it from the usb-connector
schema.
Signed-off-by: Rob Herring <robh@kernel.org>
---
v3: new patch
.../devicetree/bindings/connector/usb-connector.yaml | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index 728f82db073d..64f2e1246ddb 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -125,11 +125,13 @@ properties:
power dual role.
ports:
- description: OF graph bindings (specified in bindings/graph.txt) that model
- any data bus to the connector unless the bus is between parent node and
- the connector. Since a single connector can have multiple data buses every
- bus has an assigned OF graph port number as described below.
+ $ref: /schemas/graph.yaml#/properties/ports
type: object
+ description: OF graph bindings modeling any data bus to the connector
+ unless the bus is between parent node and the connector. Since a single
+ connector can have multiple data buses every bus has an assigned OF graph
+ port number as described below.
+
properties:
port@0:
type: object
--
2.25.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3 3/3] dt-bindings: panel: common: Add reference to graph schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-02 20:36 ` Rob Herring
-1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-02 20:36 UTC (permalink / raw)
To: devicetree, Sameer Pujar, Laurent Pinchart
Cc: dri-devel, linux-kernel, Thierry Reding, Sam Ravnborg,
Philipp Zabel, kuninori.morimoto.gx, Jacopo Mondi
Now that we have a graph schema, reference it from the common panel
schema.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
v3: new patch
.../devicetree/bindings/display/panel/panel-common.yaml | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
index cd6dc5461721..a3a72c574213 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -68,16 +68,15 @@ properties:
# Connectivity
port:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
ports:
- type: object
+ $ref: /schemas/graph.yaml#/properties/ports
description:
Panels receive video data through one or multiple connections. While
the nature of those connections is specific to the panel type, the
connectivity is expressed in a standard fashion using ports as specified
- in the device graph bindings defined in
- Documentation/devicetree/bindings/graph.txt.
+ in the device graph bindings.
ddc-i2c-bus:
$ref: /schemas/types.yaml#/definitions/phandle
--
2.25.1
^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3 3/3] dt-bindings: panel: common: Add reference to graph schema
@ 2020-11-02 20:36 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-02 20:36 UTC (permalink / raw)
To: devicetree, Sameer Pujar, Laurent Pinchart
Cc: kuninori.morimoto.gx, linux-kernel, dri-devel, Thierry Reding,
Jacopo Mondi, Sam Ravnborg
Now that we have a graph schema, reference it from the common panel
schema.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
v3: new patch
.../devicetree/bindings/display/panel/panel-common.yaml | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
index cd6dc5461721..a3a72c574213 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -68,16 +68,15 @@ properties:
# Connectivity
port:
- type: object
+ $ref: /schemas/graph.yaml#/properties/port
ports:
- type: object
+ $ref: /schemas/graph.yaml#/properties/ports
description:
Panels receive video data through one or multiple connections. While
the nature of those connections is specific to the panel type, the
connectivity is expressed in a standard fashion using ports as specified
- in the device graph bindings defined in
- Documentation/devicetree/bindings/graph.txt.
+ in the device graph bindings.
ddc-i2c-bus:
$ref: /schemas/types.yaml#/definitions/phandle
--
2.25.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v3 0/3] dt-bindings: Convert graph bindings to json-schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-03 6:05 ` Sameer Pujar
-1 siblings, 0 replies; 34+ messages in thread
From: Sameer Pujar @ 2020-11-03 6:05 UTC (permalink / raw)
To: Rob Herring, devicetree, Laurent Pinchart
Cc: dri-devel, linux-kernel, Thierry Reding, Sam Ravnborg,
Philipp Zabel, kuninori.morimoto.gx, Jacopo Mondi
Hi Rob,
> Sameer, I wanted to experiment with what the interface for graph users
> looks like, so I've tweaked your patch a bit and converted 2 users.
Thanks for the update and help.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 0/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-03 6:05 ` Sameer Pujar
0 siblings, 0 replies; 34+ messages in thread
From: Sameer Pujar @ 2020-11-03 6:05 UTC (permalink / raw)
To: Rob Herring, devicetree, Laurent Pinchart
Cc: kuninori.morimoto.gx, linux-kernel, dri-devel, Thierry Reding,
Jacopo Mondi, Sam Ravnborg
Hi Rob,
> Sameer, I wanted to experiment with what the interface for graph users
> looks like, so I've tweaked your patch a bit and converted 2 users.
Thanks for the update and help.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-05 21:43 ` Sam Ravnborg
-1 siblings, 0 replies; 34+ messages in thread
From: Sam Ravnborg @ 2020-11-05 21:43 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Sameer Pujar, Laurent Pinchart, kuninori.morimoto.gx,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi
Hi Rob/Sameer
On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> From: Sameer Pujar <spujar@nvidia.com>
>
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to refer to graph.yaml.
>
> For users of the graph binding, they should reference to the graph
> schema from either 'ports' or 'port' property:
>
> properties:
> ports:
> type: object
> $ref: graph.yaml#/properties/ports
Please fix so this example is correct - append /schemas/
>
> properties:
> port@0:
> description: What data this port has
>
> ...
>
> Or:
>
> properties:
> port:
> description: What data this port has
> type: object
> $ref: graph.yaml#/properties/port
Likewise.
Otherwise I could be confused when looking it up later.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
With the changelog fixed:
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-05 21:43 ` Sam Ravnborg
0 siblings, 0 replies; 34+ messages in thread
From: Sam Ravnborg @ 2020-11-05 21:43 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Laurent Pinchart, kuninori.morimoto.gx, Sameer Pujar,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi
Hi Rob/Sameer
On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> From: Sameer Pujar <spujar@nvidia.com>
>
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to refer to graph.yaml.
>
> For users of the graph binding, they should reference to the graph
> schema from either 'ports' or 'port' property:
>
> properties:
> ports:
> type: object
> $ref: graph.yaml#/properties/ports
Please fix so this example is correct - append /schemas/
>
> properties:
> port@0:
> description: What data this port has
>
> ...
>
> Or:
>
> properties:
> port:
> description: What data this port has
> type: object
> $ref: graph.yaml#/properties/port
Likewise.
Otherwise I could be confused when looking it up later.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
With the changelog fixed:
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 3/3] dt-bindings: panel: common: Add reference to graph schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-05 21:46 ` Sam Ravnborg
-1 siblings, 0 replies; 34+ messages in thread
From: Sam Ravnborg @ 2020-11-05 21:46 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Sameer Pujar, Laurent Pinchart, kuninori.morimoto.gx,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi
On Mon, Nov 02, 2020 at 02:36:56PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the common panel
> schema.
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
I expect you to apply the patch due to the dependencies.
We can start using graph.yaml in drm-misc-next after the merge
window and a backmerge.
Sam
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 3/3] dt-bindings: panel: common: Add reference to graph schema
@ 2020-11-05 21:46 ` Sam Ravnborg
0 siblings, 0 replies; 34+ messages in thread
From: Sam Ravnborg @ 2020-11-05 21:46 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Laurent Pinchart, kuninori.morimoto.gx, Sameer Pujar,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi
On Mon, Nov 02, 2020 at 02:36:56PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the common panel
> schema.
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
I expect you to apply the patch due to the dependencies.
We can start using graph.yaml in drm-misc-next after the merge
window and a backmerge.
Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-11 9:51 ` Sameer Pujar
-1 siblings, 0 replies; 34+ messages in thread
From: Sameer Pujar @ 2020-11-11 9:51 UTC (permalink / raw)
To: Rob Herring, devicetree, Laurent Pinchart
Cc: dri-devel, linux-kernel, Thierry Reding, Sam Ravnborg,
Philipp Zabel, kuninori.morimoto.gx, Jacopo Mondi
Hi Rob,
> From: Sameer Pujar <spujar@nvidia.com>
>
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to refer to graph.yaml.
>
> For users of the graph binding, they should reference to the graph
> schema from either 'ports' or 'port' property:
>
> properties:
> ports:
> type: object
> $ref: graph.yaml#/properties/ports
>
> properties:
> port@0:
> description: What data this port has
>
> ...
>
> Or:
>
> properties:
> port:
> description: What data this port has
> type: object
> $ref: graph.yaml#/properties/port
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> v3:
> - Move port 'reg' to port@* and make required
> - Make remote-endpoint required
> - Add 'additionalProperties: true' now required
> - Fix yamllint warnings
>
> Documentation/devicetree/bindings/graph.txt | 129 +-----------
> Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> 2 files changed, 200 insertions(+), 128 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/graph.yaml
>
...
> diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> new file mode 100644
> index 000000000000..b56720c5a13e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/graph.yaml
> @@ -0,0 +1,199 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/graph.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common bindings for device graphs
> +
> +description: |
> + The hierarchical organisation of the device tree is well suited to describe
> + control flow to devices, but there can be more complex connections between
> + devices that work together to form a logical compound device, following an
> + arbitrarily complex graph.
> + There already is a simple directed graph between devices tree nodes using
> + phandle properties pointing to other nodes to describe connections that
> + can not be inferred from device tree parent-child relationships. The device
> + tree graph bindings described herein abstract more complex devices that can
> + have multiple specifiable ports, each of which can be linked to one or more
> + ports of other devices.
> +
> + These common bindings do not contain any information about the direction or
> + type of the connections, they just map their existence. Specific properties
> + may be described by specialized bindings depending on the type of connection.
> +
> + To see how this binding applies to video pipelines, for example, see
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + Here the ports describe data interfaces, and the links between them are
> + the connecting data buses. A single port with multiple connections can
> + correspond to multiple devices being connected to the same physical bus.
> +
> +maintainers:
> + - Philipp Zabel <p.zabel@pengutronix.de>
> +
> +select: false
> +
> +properties:
> + port:
> + type: object
> + description:
> + If there is more than one endpoint node or 'reg' property present in
> + endpoint nodes then '#address-cells' and '#size-cells' properties are
> + required.
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + remote-endpoint:
> + description: |
> + phandle to an 'endpoint' subnode of a remote device node.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> + required:
> + - remote-endpoint
Does 'remote-endpoint' have to be a required property?
In case of pluggable modules, the remote-endpoint may not be available
unless the module is plugged in. In other words, device-2 in below
example may not always be available, but still device-1 endpoint
configuration and usage may be required?
...
> + # Links between endpoints:
> + #
> + # Each endpoint should contain a 'remote-endpoint' phandle property that
> + # points to the corresponding endpoint in the port of the remote device.
> + # In turn, the remote endpoint should contain a 'remote-endpoint' property.
> + # If it has one, it must not point to anything other than the local endpoint.
> + # Two endpoints with their 'remote-endpoint' phandles pointing at each other
> + # form a link between the containing ports.
> + - |
> + device-1 {
> + port {
> + device_1_output: endpoint {
> + remote-endpoint = <&device_2_input>;
> + };
> + };
> + };
> +
> + device-2 {
> + port {
> + device_2_input: endpoint {
> + remote-endpoint = <&device_1_output>;
> + };
> + };
> + };
> +
> +...
> --
> 2.25.1
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-11 9:51 ` Sameer Pujar
0 siblings, 0 replies; 34+ messages in thread
From: Sameer Pujar @ 2020-11-11 9:51 UTC (permalink / raw)
To: Rob Herring, devicetree, Laurent Pinchart
Cc: kuninori.morimoto.gx, linux-kernel, dri-devel, Thierry Reding,
Jacopo Mondi, Sam Ravnborg
Hi Rob,
> From: Sameer Pujar <spujar@nvidia.com>
>
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to refer to graph.yaml.
>
> For users of the graph binding, they should reference to the graph
> schema from either 'ports' or 'port' property:
>
> properties:
> ports:
> type: object
> $ref: graph.yaml#/properties/ports
>
> properties:
> port@0:
> description: What data this port has
>
> ...
>
> Or:
>
> properties:
> port:
> description: What data this port has
> type: object
> $ref: graph.yaml#/properties/port
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> v3:
> - Move port 'reg' to port@* and make required
> - Make remote-endpoint required
> - Add 'additionalProperties: true' now required
> - Fix yamllint warnings
>
> Documentation/devicetree/bindings/graph.txt | 129 +-----------
> Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> 2 files changed, 200 insertions(+), 128 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/graph.yaml
>
...
> diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> new file mode 100644
> index 000000000000..b56720c5a13e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/graph.yaml
> @@ -0,0 +1,199 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/graph.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common bindings for device graphs
> +
> +description: |
> + The hierarchical organisation of the device tree is well suited to describe
> + control flow to devices, but there can be more complex connections between
> + devices that work together to form a logical compound device, following an
> + arbitrarily complex graph.
> + There already is a simple directed graph between devices tree nodes using
> + phandle properties pointing to other nodes to describe connections that
> + can not be inferred from device tree parent-child relationships. The device
> + tree graph bindings described herein abstract more complex devices that can
> + have multiple specifiable ports, each of which can be linked to one or more
> + ports of other devices.
> +
> + These common bindings do not contain any information about the direction or
> + type of the connections, they just map their existence. Specific properties
> + may be described by specialized bindings depending on the type of connection.
> +
> + To see how this binding applies to video pipelines, for example, see
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + Here the ports describe data interfaces, and the links between them are
> + the connecting data buses. A single port with multiple connections can
> + correspond to multiple devices being connected to the same physical bus.
> +
> +maintainers:
> + - Philipp Zabel <p.zabel@pengutronix.de>
> +
> +select: false
> +
> +properties:
> + port:
> + type: object
> + description:
> + If there is more than one endpoint node or 'reg' property present in
> + endpoint nodes then '#address-cells' and '#size-cells' properties are
> + required.
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + remote-endpoint:
> + description: |
> + phandle to an 'endpoint' subnode of a remote device node.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> + required:
> + - remote-endpoint
Does 'remote-endpoint' have to be a required property?
In case of pluggable modules, the remote-endpoint may not be available
unless the module is plugged in. In other words, device-2 in below
example may not always be available, but still device-1 endpoint
configuration and usage may be required?
...
> + # Links between endpoints:
> + #
> + # Each endpoint should contain a 'remote-endpoint' phandle property that
> + # points to the corresponding endpoint in the port of the remote device.
> + # In turn, the remote endpoint should contain a 'remote-endpoint' property.
> + # If it has one, it must not point to anything other than the local endpoint.
> + # Two endpoints with their 'remote-endpoint' phandles pointing at each other
> + # form a link between the containing ports.
> + - |
> + device-1 {
> + port {
> + device_1_output: endpoint {
> + remote-endpoint = <&device_2_input>;
> + };
> + };
> + };
> +
> + device-2 {
> + port {
> + device_2_input: endpoint {
> + remote-endpoint = <&device_1_output>;
> + };
> + };
> + };
> +
> +...
> --
> 2.25.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-11 9:51 ` Sameer Pujar
@ 2020-11-11 13:35 ` Rob Herring
-1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-11 13:35 UTC (permalink / raw)
To: Sameer Pujar
Cc: devicetree, Laurent Pinchart, dri-devel, linux-kernel,
Thierry Reding, Sam Ravnborg, Philipp Zabel, Kuninori Morimoto,
Jacopo Mondi
On Wed, Nov 11, 2020 at 3:52 AM Sameer Pujar <spujar@nvidia.com> wrote:
>
> Hi Rob,
>
> > From: Sameer Pujar <spujar@nvidia.com>
> >
> > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > doc is referenced in multiple files and all of these need to use schema
> > references. For now graph.txt is updated to refer to graph.yaml.
> >
> > For users of the graph binding, they should reference to the graph
> > schema from either 'ports' or 'port' property:
> >
> > properties:
> > ports:
> > type: object
> > $ref: graph.yaml#/properties/ports
> >
> > properties:
> > port@0:
> > description: What data this port has
> >
> > ...
> >
> > Or:
> >
> > properties:
> > port:
> > description: What data this port has
> > type: object
> > $ref: graph.yaml#/properties/port
> >
> > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > v3:
> > - Move port 'reg' to port@* and make required
> > - Make remote-endpoint required
> > - Add 'additionalProperties: true' now required
> > - Fix yamllint warnings
> >
> > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > 2 files changed, 200 insertions(+), 128 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/graph.yaml
> >
> ...
> > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > new file mode 100644
> > index 000000000000..b56720c5a13e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/graph.yaml
> > @@ -0,0 +1,199 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/graph.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common bindings for device graphs
> > +
> > +description: |
> > + The hierarchical organisation of the device tree is well suited to describe
> > + control flow to devices, but there can be more complex connections between
> > + devices that work together to form a logical compound device, following an
> > + arbitrarily complex graph.
> > + There already is a simple directed graph between devices tree nodes using
> > + phandle properties pointing to other nodes to describe connections that
> > + can not be inferred from device tree parent-child relationships. The device
> > + tree graph bindings described herein abstract more complex devices that can
> > + have multiple specifiable ports, each of which can be linked to one or more
> > + ports of other devices.
> > +
> > + These common bindings do not contain any information about the direction or
> > + type of the connections, they just map their existence. Specific properties
> > + may be described by specialized bindings depending on the type of connection.
> > +
> > + To see how this binding applies to video pipelines, for example, see
> > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > + Here the ports describe data interfaces, and the links between them are
> > + the connecting data buses. A single port with multiple connections can
> > + correspond to multiple devices being connected to the same physical bus.
> > +
> > +maintainers:
> > + - Philipp Zabel <p.zabel@pengutronix.de>
> > +
> > +select: false
> > +
> > +properties:
> > + port:
> > + type: object
> > + description:
> > + If there is more than one endpoint node or 'reg' property present in
> > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > + required.
> > +
> > + properties:
> > + "#address-cells":
> > + const: 1
> > +
> > + "#size-cells":
> > + const: 0
> > +
> > + patternProperties:
> > + "^endpoint(@[0-9a-f]+)?$":
> > + type: object
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + remote-endpoint:
> > + description: |
> > + phandle to an 'endpoint' subnode of a remote device node.
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > +
> > + required:
> > + - remote-endpoint
>
> Does 'remote-endpoint' have to be a required property?
> In case of pluggable modules, the remote-endpoint may not be available
> unless the module is plugged in. In other words, device-2 in below
> example may not always be available, but still device-1 endpoint
> configuration and usage may be required?
No, I've dropped it. I noticed the same thing converting some of the
schema over to use this.
Rob
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-11 13:35 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-11 13:35 UTC (permalink / raw)
To: Sameer Pujar
Cc: devicetree, Laurent Pinchart, Kuninori Morimoto, linux-kernel,
dri-devel, Thierry Reding, Jacopo Mondi, Sam Ravnborg
On Wed, Nov 11, 2020 at 3:52 AM Sameer Pujar <spujar@nvidia.com> wrote:
>
> Hi Rob,
>
> > From: Sameer Pujar <spujar@nvidia.com>
> >
> > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > doc is referenced in multiple files and all of these need to use schema
> > references. For now graph.txt is updated to refer to graph.yaml.
> >
> > For users of the graph binding, they should reference to the graph
> > schema from either 'ports' or 'port' property:
> >
> > properties:
> > ports:
> > type: object
> > $ref: graph.yaml#/properties/ports
> >
> > properties:
> > port@0:
> > description: What data this port has
> >
> > ...
> >
> > Or:
> >
> > properties:
> > port:
> > description: What data this port has
> > type: object
> > $ref: graph.yaml#/properties/port
> >
> > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > v3:
> > - Move port 'reg' to port@* and make required
> > - Make remote-endpoint required
> > - Add 'additionalProperties: true' now required
> > - Fix yamllint warnings
> >
> > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > 2 files changed, 200 insertions(+), 128 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/graph.yaml
> >
> ...
> > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > new file mode 100644
> > index 000000000000..b56720c5a13e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/graph.yaml
> > @@ -0,0 +1,199 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/graph.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common bindings for device graphs
> > +
> > +description: |
> > + The hierarchical organisation of the device tree is well suited to describe
> > + control flow to devices, but there can be more complex connections between
> > + devices that work together to form a logical compound device, following an
> > + arbitrarily complex graph.
> > + There already is a simple directed graph between devices tree nodes using
> > + phandle properties pointing to other nodes to describe connections that
> > + can not be inferred from device tree parent-child relationships. The device
> > + tree graph bindings described herein abstract more complex devices that can
> > + have multiple specifiable ports, each of which can be linked to one or more
> > + ports of other devices.
> > +
> > + These common bindings do not contain any information about the direction or
> > + type of the connections, they just map their existence. Specific properties
> > + may be described by specialized bindings depending on the type of connection.
> > +
> > + To see how this binding applies to video pipelines, for example, see
> > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > + Here the ports describe data interfaces, and the links between them are
> > + the connecting data buses. A single port with multiple connections can
> > + correspond to multiple devices being connected to the same physical bus.
> > +
> > +maintainers:
> > + - Philipp Zabel <p.zabel@pengutronix.de>
> > +
> > +select: false
> > +
> > +properties:
> > + port:
> > + type: object
> > + description:
> > + If there is more than one endpoint node or 'reg' property present in
> > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > + required.
> > +
> > + properties:
> > + "#address-cells":
> > + const: 1
> > +
> > + "#size-cells":
> > + const: 0
> > +
> > + patternProperties:
> > + "^endpoint(@[0-9a-f]+)?$":
> > + type: object
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + remote-endpoint:
> > + description: |
> > + phandle to an 'endpoint' subnode of a remote device node.
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > +
> > + required:
> > + - remote-endpoint
>
> Does 'remote-endpoint' have to be a required property?
> In case of pluggable modules, the remote-endpoint may not be available
> unless the module is plugged in. In other words, device-2 in below
> example may not always be available, but still device-1 endpoint
> configuration and usage may be required?
No, I've dropped it. I noticed the same thing converting some of the
schema over to use this.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-11 14:00 ` Laurent Pinchart
-1 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-11 14:00 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Sameer Pujar, Laurent Pinchart, dri-devel,
linux-kernel, Thierry Reding, Sam Ravnborg, Philipp Zabel,
kuninori.morimoto.gx, Jacopo Mondi
Hi Rob and Sameer,
Thank you for the patch.
On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> From: Sameer Pujar <spujar@nvidia.com>
>
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to refer to graph.yaml.
>
> For users of the graph binding, they should reference to the graph
> schema from either 'ports' or 'port' property:
>
> properties:
> ports:
> type: object
> $ref: graph.yaml#/properties/ports
>
> properties:
> port@0:
> description: What data this port has
>
> ...
>
> Or:
>
> properties:
> port:
> description: What data this port has
> type: object
> $ref: graph.yaml#/properties/port
Sounds like a good approach.
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> v3:
> - Move port 'reg' to port@* and make required
> - Make remote-endpoint required
> - Add 'additionalProperties: true' now required
> - Fix yamllint warnings
>
> Documentation/devicetree/bindings/graph.txt | 129 +-----------
> Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> 2 files changed, 200 insertions(+), 128 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/graph.yaml
>
> diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/graph.txt
> index 0415e2c53ba0..b7818d61cef7 100644
> --- a/Documentation/devicetree/bindings/graph.txt
> +++ b/Documentation/devicetree/bindings/graph.txt
> @@ -1,128 +1 @@
> -Common bindings for device graphs
> -
> -General concept
> ----------------
> -
> -The hierarchical organisation of the device tree is well suited to describe
> -control flow to devices, but there can be more complex connections between
> -devices that work together to form a logical compound device, following an
> -arbitrarily complex graph.
> -There already is a simple directed graph between devices tree nodes using
> -phandle properties pointing to other nodes to describe connections that
> -can not be inferred from device tree parent-child relationships. The device
> -tree graph bindings described herein abstract more complex devices that can
> -have multiple specifiable ports, each of which can be linked to one or more
> -ports of other devices.
> -
> -These common bindings do not contain any information about the direction or
> -type of the connections, they just map their existence. Specific properties
> -may be described by specialized bindings depending on the type of connection.
> -
> -To see how this binding applies to video pipelines, for example, see
> -Documentation/devicetree/bindings/media/video-interfaces.txt.
> -Here the ports describe data interfaces, and the links between them are
> -the connecting data buses. A single port with multiple connections can
> -correspond to multiple devices being connected to the same physical bus.
> -
> -Organisation of ports and endpoints
> ------------------------------------
> -
> -Ports are described by child 'port' nodes contained in the device node.
> -Each port node contains an 'endpoint' subnode for each remote device port
> -connected to this port. If a single port is connected to more than one
> -remote device, an 'endpoint' child node must be provided for each link.
> -If more than one port is present in a device node or there is more than one
> -endpoint at a port, or a port node needs to be associated with a selected
> -hardware interface, a common scheme using '#address-cells', '#size-cells'
> -and 'reg' properties is used to number the nodes.
> -
> -device {
> - ...
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0>;
> -
> - endpoint@0 {
> - reg = <0>;
> - ...
> - };
> - endpoint@1 {
> - reg = <1>;
> - ...
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> -
> - endpoint { ... };
> - };
> -};
> -
> -All 'port' nodes can be grouped under an optional 'ports' node, which
> -allows to specify #address-cells, #size-cells properties for the 'port'
> -nodes independently from any other child device nodes a device might
> -have.
> -
> -device {
> - ...
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - ...
> - endpoint@0 { ... };
> - endpoint@1 { ... };
> - };
> -
> - port@1 { ... };
> - };
> -};
> -
> -Links between endpoints
> ------------------------
> -
> -Each endpoint should contain a 'remote-endpoint' phandle property that points
> -to the corresponding endpoint in the port of the remote device. In turn, the
> -remote endpoint should contain a 'remote-endpoint' property. If it has one, it
> -must not point to anything other than the local endpoint. Two endpoints with
> -their 'remote-endpoint' phandles pointing at each other form a link between the
> -containing ports.
> -
> -device-1 {
> - port {
> - device_1_output: endpoint {
> - remote-endpoint = <&device_2_input>;
> - };
> - };
> -};
> -
> -device-2 {
> - port {
> - device_2_input: endpoint {
> - remote-endpoint = <&device_1_output>;
> - };
> - };
> -};
> -
> -Required properties
> --------------------
> -
> -If there is more than one 'port' or more than one 'endpoint' node or 'reg'
> -property present in the port and/or endpoint nodes then the following
> -properties are required in a relevant parent node:
> -
> - - #address-cells : number of cells required to define port/endpoint
> - identifier, should be 1.
> - - #size-cells : should be zero.
> -
> -Optional endpoint properties
> -----------------------------
> -
> -- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
> -
> +This file has moved to graph.yaml
> diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> new file mode 100644
> index 000000000000..b56720c5a13e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/graph.yaml
> @@ -0,0 +1,199 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/graph.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common bindings for device graphs
> +
> +description: |
> + The hierarchical organisation of the device tree is well suited to describe
> + control flow to devices, but there can be more complex connections between
> + devices that work together to form a logical compound device, following an
> + arbitrarily complex graph.
> + There already is a simple directed graph between devices tree nodes using
> + phandle properties pointing to other nodes to describe connections that
> + can not be inferred from device tree parent-child relationships. The device
> + tree graph bindings described herein abstract more complex devices that can
> + have multiple specifiable ports, each of which can be linked to one or more
> + ports of other devices.
> +
> + These common bindings do not contain any information about the direction or
> + type of the connections, they just map their existence. Specific properties
> + may be described by specialized bindings depending on the type of connection.
> +
> + To see how this binding applies to video pipelines, for example, see
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + Here the ports describe data interfaces, and the links between them are
> + the connecting data buses. A single port with multiple connections can
> + correspond to multiple devices being connected to the same physical bus.
> +
> +maintainers:
> + - Philipp Zabel <p.zabel@pengutronix.de>
> +
> +select: false
> +
> +properties:
> + port:
> + type: object
> + description:
> + If there is more than one endpoint node or 'reg' property present in
> + endpoint nodes then '#address-cells' and '#size-cells' properties are
> + required.
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + remote-endpoint:
> + description: |
> + phandle to an 'endpoint' subnode of a remote device node.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> + required:
> + - remote-endpoint
As noted elsewhere, this shouldn't be required.
Should we set additionalProperties: false here ?
> +
> + ports:
> + type: object
> + description: |
> + If there is more than one port node or 'reg' property present in port
> + nodes then '#address-cells' and '#size-cells' properties are required.
> + In such cases all port nodes can be grouped under 'ports' independently
> + from any other child device nodes a device might have.
Allowing multiple port nodes not grouped in a ports node has created
complexity, with very little gain. Should we forbid that going forward ?
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^port(@[0-9a-f]+)?$":
> + $ref: "#/properties/port"
> + type: object
> +
> + properties:
> + reg:
> + maxItems: 1
> +
> + required:
> + - reg
> +
> +
Maybe a single blank line ?
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + additionalProperties: false
> +
> +additionalProperties: true
> +
> +examples:
> + # Organisation of ports and endpoints:
> + #
> + # Ports are described by child 'port' nodes contained in the device node.
> + # Each port node contains an 'endpoint' subnode for each remote device port
> + # connected to this port. If a single port is connected to more than one
> + # remote device, an 'endpoint' child node must be provided for each link.
> + # If more than one port is present in a device node or there is more than
> + # one endpoint at a port, or a port node needs to be associated with a
> + # selected hardware interface, a common scheme using '#address-cells',
> + # '#size-cells' and 'reg' properties is used to number the nodes.
> + - |
> + device {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + endpoint@0 {
> + reg = <0>;
> + // ...
> + };
> + endpoint@1 {
> + reg = <1>;
> + // ...
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + endpoint {
> + // ...
> + };
> + };
> + };
> +
> + # All 'port' nodes can be grouped under an optional 'ports' node, which
> + # allows to specify #address-cells, #size-cells properties for the 'port'
> + # nodes independently from any other child device nodes a device might
> + # have.
> + - |
> + device {
> + // ...
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + // ...
> +
> + endpoint@0 {
> + reg = <0>;
> + // ...
> + };
> + endpoint@1 {
> + reg = <1>;
> + // ...
> + };
> + };
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + // ...
> + };
> + };
> + };
> +
> + # Links between endpoints:
> + #
> + # Each endpoint should contain a 'remote-endpoint' phandle property that
> + # points to the corresponding endpoint in the port of the remote device.
> + # In turn, the remote endpoint should contain a 'remote-endpoint' property.
> + # If it has one, it must not point to anything other than the local endpoint.
> + # Two endpoints with their 'remote-endpoint' phandles pointing at each other
> + # form a link between the containing ports.
> + - |
> + device-1 {
> + port {
> + device_1_output: endpoint {
> + remote-endpoint = <&device_2_input>;
> + };
> + };
> + };
> +
> + device-2 {
> + port {
> + device_2_input: endpoint {
> + remote-endpoint = <&device_1_output>;
> + };
> + };
> + };
> +
> +...
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-11 14:00 ` Laurent Pinchart
0 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-11 14:00 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Laurent Pinchart, kuninori.morimoto.gx, Sameer Pujar,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi,
Sam Ravnborg
Hi Rob and Sameer,
Thank you for the patch.
On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> From: Sameer Pujar <spujar@nvidia.com>
>
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to refer to graph.yaml.
>
> For users of the graph binding, they should reference to the graph
> schema from either 'ports' or 'port' property:
>
> properties:
> ports:
> type: object
> $ref: graph.yaml#/properties/ports
>
> properties:
> port@0:
> description: What data this port has
>
> ...
>
> Or:
>
> properties:
> port:
> description: What data this port has
> type: object
> $ref: graph.yaml#/properties/port
Sounds like a good approach.
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> v3:
> - Move port 'reg' to port@* and make required
> - Make remote-endpoint required
> - Add 'additionalProperties: true' now required
> - Fix yamllint warnings
>
> Documentation/devicetree/bindings/graph.txt | 129 +-----------
> Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> 2 files changed, 200 insertions(+), 128 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/graph.yaml
>
> diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/graph.txt
> index 0415e2c53ba0..b7818d61cef7 100644
> --- a/Documentation/devicetree/bindings/graph.txt
> +++ b/Documentation/devicetree/bindings/graph.txt
> @@ -1,128 +1 @@
> -Common bindings for device graphs
> -
> -General concept
> ----------------
> -
> -The hierarchical organisation of the device tree is well suited to describe
> -control flow to devices, but there can be more complex connections between
> -devices that work together to form a logical compound device, following an
> -arbitrarily complex graph.
> -There already is a simple directed graph between devices tree nodes using
> -phandle properties pointing to other nodes to describe connections that
> -can not be inferred from device tree parent-child relationships. The device
> -tree graph bindings described herein abstract more complex devices that can
> -have multiple specifiable ports, each of which can be linked to one or more
> -ports of other devices.
> -
> -These common bindings do not contain any information about the direction or
> -type of the connections, they just map their existence. Specific properties
> -may be described by specialized bindings depending on the type of connection.
> -
> -To see how this binding applies to video pipelines, for example, see
> -Documentation/devicetree/bindings/media/video-interfaces.txt.
> -Here the ports describe data interfaces, and the links between them are
> -the connecting data buses. A single port with multiple connections can
> -correspond to multiple devices being connected to the same physical bus.
> -
> -Organisation of ports and endpoints
> ------------------------------------
> -
> -Ports are described by child 'port' nodes contained in the device node.
> -Each port node contains an 'endpoint' subnode for each remote device port
> -connected to this port. If a single port is connected to more than one
> -remote device, an 'endpoint' child node must be provided for each link.
> -If more than one port is present in a device node or there is more than one
> -endpoint at a port, or a port node needs to be associated with a selected
> -hardware interface, a common scheme using '#address-cells', '#size-cells'
> -and 'reg' properties is used to number the nodes.
> -
> -device {
> - ...
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0>;
> -
> - endpoint@0 {
> - reg = <0>;
> - ...
> - };
> - endpoint@1 {
> - reg = <1>;
> - ...
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> -
> - endpoint { ... };
> - };
> -};
> -
> -All 'port' nodes can be grouped under an optional 'ports' node, which
> -allows to specify #address-cells, #size-cells properties for the 'port'
> -nodes independently from any other child device nodes a device might
> -have.
> -
> -device {
> - ...
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - ...
> - endpoint@0 { ... };
> - endpoint@1 { ... };
> - };
> -
> - port@1 { ... };
> - };
> -};
> -
> -Links between endpoints
> ------------------------
> -
> -Each endpoint should contain a 'remote-endpoint' phandle property that points
> -to the corresponding endpoint in the port of the remote device. In turn, the
> -remote endpoint should contain a 'remote-endpoint' property. If it has one, it
> -must not point to anything other than the local endpoint. Two endpoints with
> -their 'remote-endpoint' phandles pointing at each other form a link between the
> -containing ports.
> -
> -device-1 {
> - port {
> - device_1_output: endpoint {
> - remote-endpoint = <&device_2_input>;
> - };
> - };
> -};
> -
> -device-2 {
> - port {
> - device_2_input: endpoint {
> - remote-endpoint = <&device_1_output>;
> - };
> - };
> -};
> -
> -Required properties
> --------------------
> -
> -If there is more than one 'port' or more than one 'endpoint' node or 'reg'
> -property present in the port and/or endpoint nodes then the following
> -properties are required in a relevant parent node:
> -
> - - #address-cells : number of cells required to define port/endpoint
> - identifier, should be 1.
> - - #size-cells : should be zero.
> -
> -Optional endpoint properties
> -----------------------------
> -
> -- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
> -
> +This file has moved to graph.yaml
> diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> new file mode 100644
> index 000000000000..b56720c5a13e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/graph.yaml
> @@ -0,0 +1,199 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/graph.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common bindings for device graphs
> +
> +description: |
> + The hierarchical organisation of the device tree is well suited to describe
> + control flow to devices, but there can be more complex connections between
> + devices that work together to form a logical compound device, following an
> + arbitrarily complex graph.
> + There already is a simple directed graph between devices tree nodes using
> + phandle properties pointing to other nodes to describe connections that
> + can not be inferred from device tree parent-child relationships. The device
> + tree graph bindings described herein abstract more complex devices that can
> + have multiple specifiable ports, each of which can be linked to one or more
> + ports of other devices.
> +
> + These common bindings do not contain any information about the direction or
> + type of the connections, they just map their existence. Specific properties
> + may be described by specialized bindings depending on the type of connection.
> +
> + To see how this binding applies to video pipelines, for example, see
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + Here the ports describe data interfaces, and the links between them are
> + the connecting data buses. A single port with multiple connections can
> + correspond to multiple devices being connected to the same physical bus.
> +
> +maintainers:
> + - Philipp Zabel <p.zabel@pengutronix.de>
> +
> +select: false
> +
> +properties:
> + port:
> + type: object
> + description:
> + If there is more than one endpoint node or 'reg' property present in
> + endpoint nodes then '#address-cells' and '#size-cells' properties are
> + required.
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^endpoint(@[0-9a-f]+)?$":
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> +
> + remote-endpoint:
> + description: |
> + phandle to an 'endpoint' subnode of a remote device node.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> + required:
> + - remote-endpoint
As noted elsewhere, this shouldn't be required.
Should we set additionalProperties: false here ?
> +
> + ports:
> + type: object
> + description: |
> + If there is more than one port node or 'reg' property present in port
> + nodes then '#address-cells' and '#size-cells' properties are required.
> + In such cases all port nodes can be grouped under 'ports' independently
> + from any other child device nodes a device might have.
Allowing multiple port nodes not grouped in a ports node has created
complexity, with very little gain. Should we forbid that going forward ?
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^port(@[0-9a-f]+)?$":
> + $ref: "#/properties/port"
> + type: object
> +
> + properties:
> + reg:
> + maxItems: 1
> +
> + required:
> + - reg
> +
> +
Maybe a single blank line ?
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> + additionalProperties: false
> +
> +additionalProperties: true
> +
> +examples:
> + # Organisation of ports and endpoints:
> + #
> + # Ports are described by child 'port' nodes contained in the device node.
> + # Each port node contains an 'endpoint' subnode for each remote device port
> + # connected to this port. If a single port is connected to more than one
> + # remote device, an 'endpoint' child node must be provided for each link.
> + # If more than one port is present in a device node or there is more than
> + # one endpoint at a port, or a port node needs to be associated with a
> + # selected hardware interface, a common scheme using '#address-cells',
> + # '#size-cells' and 'reg' properties is used to number the nodes.
> + - |
> + device {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + endpoint@0 {
> + reg = <0>;
> + // ...
> + };
> + endpoint@1 {
> + reg = <1>;
> + // ...
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + endpoint {
> + // ...
> + };
> + };
> + };
> +
> + # All 'port' nodes can be grouped under an optional 'ports' node, which
> + # allows to specify #address-cells, #size-cells properties for the 'port'
> + # nodes independently from any other child device nodes a device might
> + # have.
> + - |
> + device {
> + // ...
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + // ...
> +
> + endpoint@0 {
> + reg = <0>;
> + // ...
> + };
> + endpoint@1 {
> + reg = <1>;
> + // ...
> + };
> + };
> +
> + port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + // ...
> + };
> + };
> + };
> +
> + # Links between endpoints:
> + #
> + # Each endpoint should contain a 'remote-endpoint' phandle property that
> + # points to the corresponding endpoint in the port of the remote device.
> + # In turn, the remote endpoint should contain a 'remote-endpoint' property.
> + # If it has one, it must not point to anything other than the local endpoint.
> + # Two endpoints with their 'remote-endpoint' phandles pointing at each other
> + # form a link between the containing ports.
> + - |
> + device-1 {
> + port {
> + device_1_output: endpoint {
> + remote-endpoint = <&device_2_input>;
> + };
> + };
> + };
> +
> + device-2 {
> + port {
> + device_2_input: endpoint {
> + remote-endpoint = <&device_1_output>;
> + };
> + };
> + };
> +
> +...
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 2/3] dt-bindings: usb-connector: Add reference to graph schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-11 14:01 ` Laurent Pinchart
-1 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-11 14:01 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Sameer Pujar, Laurent Pinchart, dri-devel,
linux-kernel, Thierry Reding, Sam Ravnborg, Philipp Zabel,
kuninori.morimoto.gx, Jacopo Mondi
Hi Rob,
Thank you for the patch.
On Mon, Nov 02, 2020 at 02:36:55PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the usb-connector
> schema.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v3: new patch
>
> .../devicetree/bindings/connector/usb-connector.yaml | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index 728f82db073d..64f2e1246ddb 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -125,11 +125,13 @@ properties:
> power dual role.
>
> ports:
> - description: OF graph bindings (specified in bindings/graph.txt) that model
> - any data bus to the connector unless the bus is between parent node and
> - the connector. Since a single connector can have multiple data buses every
> - bus has an assigned OF graph port number as described below.
> + $ref: /schemas/graph.yaml#/properties/ports
> type: object
> + description: OF graph bindings modeling any data bus to the connector
> + unless the bus is between parent node and the connector. Since a single
> + connector can have multiple data buses every bus has an assigned OF graph
> + port number as described below.
> +
> properties:
> port@0:
> type: object
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 2/3] dt-bindings: usb-connector: Add reference to graph schema
@ 2020-11-11 14:01 ` Laurent Pinchart
0 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-11 14:01 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Laurent Pinchart, kuninori.morimoto.gx, Sameer Pujar,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi,
Sam Ravnborg
Hi Rob,
Thank you for the patch.
On Mon, Nov 02, 2020 at 02:36:55PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the usb-connector
> schema.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v3: new patch
>
> .../devicetree/bindings/connector/usb-connector.yaml | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index 728f82db073d..64f2e1246ddb 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -125,11 +125,13 @@ properties:
> power dual role.
>
> ports:
> - description: OF graph bindings (specified in bindings/graph.txt) that model
> - any data bus to the connector unless the bus is between parent node and
> - the connector. Since a single connector can have multiple data buses every
> - bus has an assigned OF graph port number as described below.
> + $ref: /schemas/graph.yaml#/properties/ports
> type: object
> + description: OF graph bindings modeling any data bus to the connector
> + unless the bus is between parent node and the connector. Since a single
> + connector can have multiple data buses every bus has an assigned OF graph
> + port number as described below.
> +
> properties:
> port@0:
> type: object
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 3/3] dt-bindings: panel: common: Add reference to graph schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-11 14:02 ` Laurent Pinchart
-1 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-11 14:02 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Sameer Pujar, Laurent Pinchart, dri-devel,
linux-kernel, Thierry Reding, Sam Ravnborg, Philipp Zabel,
kuninori.morimoto.gx, Jacopo Mondi
Hi Rob,
Thank you for the patch.
On Mon, Nov 02, 2020 at 02:36:56PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the common panel
> schema.
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v3: new patch
>
> .../devicetree/bindings/display/panel/panel-common.yaml | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> index cd6dc5461721..a3a72c574213 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> @@ -68,16 +68,15 @@ properties:
>
> # Connectivity
> port:
> - type: object
> + $ref: /schemas/graph.yaml#/properties/port
>
> ports:
> - type: object
> + $ref: /schemas/graph.yaml#/properties/ports
> description:
> Panels receive video data through one or multiple connections. While
> the nature of those connections is specific to the panel type, the
> connectivity is expressed in a standard fashion using ports as specified
> - in the device graph bindings defined in
> - Documentation/devicetree/bindings/graph.txt.
> + in the device graph bindings.
>
> ddc-i2c-bus:
> $ref: /schemas/types.yaml#/definitions/phandle
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 3/3] dt-bindings: panel: common: Add reference to graph schema
@ 2020-11-11 14:02 ` Laurent Pinchart
0 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-11 14:02 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Laurent Pinchart, kuninori.morimoto.gx, Sameer Pujar,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi,
Sam Ravnborg
Hi Rob,
Thank you for the patch.
On Mon, Nov 02, 2020 at 02:36:56PM -0600, Rob Herring wrote:
> Now that we have a graph schema, reference it from the common panel
> schema.
>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v3: new patch
>
> .../devicetree/bindings/display/panel/panel-common.yaml | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> index cd6dc5461721..a3a72c574213 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
> @@ -68,16 +68,15 @@ properties:
>
> # Connectivity
> port:
> - type: object
> + $ref: /schemas/graph.yaml#/properties/port
>
> ports:
> - type: object
> + $ref: /schemas/graph.yaml#/properties/ports
> description:
> Panels receive video data through one or multiple connections. While
> the nature of those connections is specific to the panel type, the
> connectivity is expressed in a standard fashion using ports as specified
> - in the device graph bindings defined in
> - Documentation/devicetree/bindings/graph.txt.
> + in the device graph bindings.
>
> ddc-i2c-bus:
> $ref: /schemas/types.yaml#/definitions/phandle
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-11 14:00 ` Laurent Pinchart
@ 2020-11-11 14:25 ` Rob Herring
-1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-11 14:25 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, Sameer Pujar, Laurent Pinchart, dri-devel,
linux-kernel, Thierry Reding, Sam Ravnborg, Philipp Zabel,
Kuninori Morimoto, Jacopo Mondi
On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Rob and Sameer,
>
> Thank you for the patch.
>
> On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > From: Sameer Pujar <spujar@nvidia.com>
> >
> > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > doc is referenced in multiple files and all of these need to use schema
> > references. For now graph.txt is updated to refer to graph.yaml.
> >
> > For users of the graph binding, they should reference to the graph
> > schema from either 'ports' or 'port' property:
> >
> > properties:
> > ports:
> > type: object
> > $ref: graph.yaml#/properties/ports
> >
> > properties:
> > port@0:
> > description: What data this port has
> >
> > ...
> >
> > Or:
> >
> > properties:
> > port:
> > description: What data this port has
> > type: object
> > $ref: graph.yaml#/properties/port
>
> Sounds like a good approach.
>
> > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > v3:
> > - Move port 'reg' to port@* and make required
> > - Make remote-endpoint required
> > - Add 'additionalProperties: true' now required
> > - Fix yamllint warnings
> >
> > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > 2 files changed, 200 insertions(+), 128 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/graph.yaml
[...]
> > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > new file mode 100644
> > index 000000000000..b56720c5a13e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/graph.yaml
> > @@ -0,0 +1,199 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/graph.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common bindings for device graphs
> > +
> > +description: |
> > + The hierarchical organisation of the device tree is well suited to describe
> > + control flow to devices, but there can be more complex connections between
> > + devices that work together to form a logical compound device, following an
> > + arbitrarily complex graph.
> > + There already is a simple directed graph between devices tree nodes using
> > + phandle properties pointing to other nodes to describe connections that
> > + can not be inferred from device tree parent-child relationships. The device
> > + tree graph bindings described herein abstract more complex devices that can
> > + have multiple specifiable ports, each of which can be linked to one or more
> > + ports of other devices.
> > +
> > + These common bindings do not contain any information about the direction or
> > + type of the connections, they just map their existence. Specific properties
> > + may be described by specialized bindings depending on the type of connection.
> > +
> > + To see how this binding applies to video pipelines, for example, see
> > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > + Here the ports describe data interfaces, and the links between them are
> > + the connecting data buses. A single port with multiple connections can
> > + correspond to multiple devices being connected to the same physical bus.
> > +
> > +maintainers:
> > + - Philipp Zabel <p.zabel@pengutronix.de>
> > +
> > +select: false
> > +
> > +properties:
> > + port:
> > + type: object
> > + description:
> > + If there is more than one endpoint node or 'reg' property present in
> > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > + required.
> > +
> > + properties:
> > + "#address-cells":
> > + const: 1
> > +
> > + "#size-cells":
> > + const: 0
> > +
> > + patternProperties:
> > + "^endpoint(@[0-9a-f]+)?$":
> > + type: object
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + remote-endpoint:
> > + description: |
> > + phandle to an 'endpoint' subnode of a remote device node.
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > +
> > + required:
> > + - remote-endpoint
>
> As noted elsewhere, this shouldn't be required.
>
> Should we set additionalProperties: false here ?
No, we've got a bunch of properties that get added to endpoint nodes.
There's a few cases where 'port' nodes have properties too.
> > + ports:
> > + type: object
> > + description: |
> > + If there is more than one port node or 'reg' property present in port
> > + nodes then '#address-cells' and '#size-cells' properties are required.
> > + In such cases all port nodes can be grouped under 'ports' independently
> > + from any other child device nodes a device might have.
>
> Allowing multiple port nodes not grouped in a ports node has created
> complexity, with very little gain. Should we forbid that going forward ?
Yes, that's probably a separate change. The examples need updating
too. We do have a few cases we'll have to support though.
> > + properties:
> > + "#address-cells":
> > + const: 1
> > +
> > + "#size-cells":
> > + const: 0
> > +
> > + patternProperties:
> > + "^port(@[0-9a-f]+)?$":
> > + $ref: "#/properties/port"
> > + type: object
> > +
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + required:
> > + - reg
> > +
> > +
>
> Maybe a single blank line ?
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
I've gone thru and updated schemas to use this. Primarily to prove out
a meta-schema for it. So I'll be sending out another version.
Rob
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-11 14:25 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-11 14:25 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, Laurent Pinchart, Kuninori Morimoto, Sameer Pujar,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi,
Sam Ravnborg
On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Rob and Sameer,
>
> Thank you for the patch.
>
> On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > From: Sameer Pujar <spujar@nvidia.com>
> >
> > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > doc is referenced in multiple files and all of these need to use schema
> > references. For now graph.txt is updated to refer to graph.yaml.
> >
> > For users of the graph binding, they should reference to the graph
> > schema from either 'ports' or 'port' property:
> >
> > properties:
> > ports:
> > type: object
> > $ref: graph.yaml#/properties/ports
> >
> > properties:
> > port@0:
> > description: What data this port has
> >
> > ...
> >
> > Or:
> >
> > properties:
> > port:
> > description: What data this port has
> > type: object
> > $ref: graph.yaml#/properties/port
>
> Sounds like a good approach.
>
> > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > v3:
> > - Move port 'reg' to port@* and make required
> > - Make remote-endpoint required
> > - Add 'additionalProperties: true' now required
> > - Fix yamllint warnings
> >
> > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > 2 files changed, 200 insertions(+), 128 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/graph.yaml
[...]
> > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > new file mode 100644
> > index 000000000000..b56720c5a13e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/graph.yaml
> > @@ -0,0 +1,199 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/graph.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Common bindings for device graphs
> > +
> > +description: |
> > + The hierarchical organisation of the device tree is well suited to describe
> > + control flow to devices, but there can be more complex connections between
> > + devices that work together to form a logical compound device, following an
> > + arbitrarily complex graph.
> > + There already is a simple directed graph between devices tree nodes using
> > + phandle properties pointing to other nodes to describe connections that
> > + can not be inferred from device tree parent-child relationships. The device
> > + tree graph bindings described herein abstract more complex devices that can
> > + have multiple specifiable ports, each of which can be linked to one or more
> > + ports of other devices.
> > +
> > + These common bindings do not contain any information about the direction or
> > + type of the connections, they just map their existence. Specific properties
> > + may be described by specialized bindings depending on the type of connection.
> > +
> > + To see how this binding applies to video pipelines, for example, see
> > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > + Here the ports describe data interfaces, and the links between them are
> > + the connecting data buses. A single port with multiple connections can
> > + correspond to multiple devices being connected to the same physical bus.
> > +
> > +maintainers:
> > + - Philipp Zabel <p.zabel@pengutronix.de>
> > +
> > +select: false
> > +
> > +properties:
> > + port:
> > + type: object
> > + description:
> > + If there is more than one endpoint node or 'reg' property present in
> > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > + required.
> > +
> > + properties:
> > + "#address-cells":
> > + const: 1
> > +
> > + "#size-cells":
> > + const: 0
> > +
> > + patternProperties:
> > + "^endpoint(@[0-9a-f]+)?$":
> > + type: object
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + remote-endpoint:
> > + description: |
> > + phandle to an 'endpoint' subnode of a remote device node.
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > +
> > + required:
> > + - remote-endpoint
>
> As noted elsewhere, this shouldn't be required.
>
> Should we set additionalProperties: false here ?
No, we've got a bunch of properties that get added to endpoint nodes.
There's a few cases where 'port' nodes have properties too.
> > + ports:
> > + type: object
> > + description: |
> > + If there is more than one port node or 'reg' property present in port
> > + nodes then '#address-cells' and '#size-cells' properties are required.
> > + In such cases all port nodes can be grouped under 'ports' independently
> > + from any other child device nodes a device might have.
>
> Allowing multiple port nodes not grouped in a ports node has created
> complexity, with very little gain. Should we forbid that going forward ?
Yes, that's probably a separate change. The examples need updating
too. We do have a few cases we'll have to support though.
> > + properties:
> > + "#address-cells":
> > + const: 1
> > +
> > + "#size-cells":
> > + const: 0
> > +
> > + patternProperties:
> > + "^port(@[0-9a-f]+)?$":
> > + $ref: "#/properties/port"
> > + type: object
> > +
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + required:
> > + - reg
> > +
> > +
>
> Maybe a single blank line ?
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
I've gone thru and updated schemas to use this. Primarily to prove out
a meta-schema for it. So I'll be sending out another version.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-11 14:25 ` Rob Herring
@ 2020-11-11 14:27 ` Laurent Pinchart
-1 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-11 14:27 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Sameer Pujar, Laurent Pinchart, dri-devel,
linux-kernel, Thierry Reding, Sam Ravnborg, Philipp Zabel,
Kuninori Morimoto, Jacopo Mondi
Hi Rob,
On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > From: Sameer Pujar <spujar@nvidia.com>
> > >
> > > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > > doc is referenced in multiple files and all of these need to use schema
> > > references. For now graph.txt is updated to refer to graph.yaml.
> > >
> > > For users of the graph binding, they should reference to the graph
> > > schema from either 'ports' or 'port' property:
> > >
> > > properties:
> > > ports:
> > > type: object
> > > $ref: graph.yaml#/properties/ports
> > >
> > > properties:
> > > port@0:
> > > description: What data this port has
> > >
> > > ...
> > >
> > > Or:
> > >
> > > properties:
> > > port:
> > > description: What data this port has
> > > type: object
> > > $ref: graph.yaml#/properties/port
> >
> > Sounds like a good approach.
> >
> > > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > ---
> > > v3:
> > > - Move port 'reg' to port@* and make required
> > > - Make remote-endpoint required
> > > - Add 'additionalProperties: true' now required
> > > - Fix yamllint warnings
> > >
> > > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > > 2 files changed, 200 insertions(+), 128 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/graph.yaml
>
> [...]
>
> > > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > > new file mode 100644
> > > index 000000000000..b56720c5a13e
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/graph.yaml
> > > @@ -0,0 +1,199 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/graph.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Common bindings for device graphs
> > > +
> > > +description: |
> > > + The hierarchical organisation of the device tree is well suited to describe
> > > + control flow to devices, but there can be more complex connections between
> > > + devices that work together to form a logical compound device, following an
> > > + arbitrarily complex graph.
> > > + There already is a simple directed graph between devices tree nodes using
> > > + phandle properties pointing to other nodes to describe connections that
> > > + can not be inferred from device tree parent-child relationships. The device
> > > + tree graph bindings described herein abstract more complex devices that can
> > > + have multiple specifiable ports, each of which can be linked to one or more
> > > + ports of other devices.
> > > +
> > > + These common bindings do not contain any information about the direction or
> > > + type of the connections, they just map their existence. Specific properties
> > > + may be described by specialized bindings depending on the type of connection.
> > > +
> > > + To see how this binding applies to video pipelines, for example, see
> > > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > + Here the ports describe data interfaces, and the links between them are
> > > + the connecting data buses. A single port with multiple connections can
> > > + correspond to multiple devices being connected to the same physical bus.
> > > +
> > > +maintainers:
> > > + - Philipp Zabel <p.zabel@pengutronix.de>
> > > +
> > > +select: false
> > > +
> > > +properties:
> > > + port:
> > > + type: object
> > > + description:
> > > + If there is more than one endpoint node or 'reg' property present in
> > > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > > + required.
> > > +
> > > + properties:
> > > + "#address-cells":
> > > + const: 1
> > > +
> > > + "#size-cells":
> > > + const: 0
> > > +
> > > + patternProperties:
> > > + "^endpoint(@[0-9a-f]+)?$":
> > > + type: object
> > > + properties:
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + remote-endpoint:
> > > + description: |
> > > + phandle to an 'endpoint' subnode of a remote device node.
> > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > +
> > > + required:
> > > + - remote-endpoint
> >
> > As noted elsewhere, this shouldn't be required.
> >
> > Should we set additionalProperties: false here ?
>
> No, we've got a bunch of properties that get added to endpoint nodes.
> There's a few cases where 'port' nodes have properties too.
I meant the port node, which I wasn't aware needed additional
properties. Do you have any example ? (I wonder if you will point me to
bindings that I have written ;-))
> > > + ports:
> > > + type: object
> > > + description: |
> > > + If there is more than one port node or 'reg' property present in port
> > > + nodes then '#address-cells' and '#size-cells' properties are required.
> > > + In such cases all port nodes can be grouped under 'ports' independently
> > > + from any other child device nodes a device might have.
> >
> > Allowing multiple port nodes not grouped in a ports node has created
> > complexity, with very little gain. Should we forbid that going forward ?
>
> Yes, that's probably a separate change. The examples need updating
> too. We do have a few cases we'll have to support though.
Sure, it can be done on top.
> > > + properties:
> > > + "#address-cells":
> > > + const: 1
> > > +
> > > + "#size-cells":
> > > + const: 0
> > > +
> > > + patternProperties:
> > > + "^port(@[0-9a-f]+)?$":
> > > + $ref: "#/properties/port"
> > > + type: object
> > > +
> > > + properties:
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + required:
> > > + - reg
> > > +
> > > +
> >
> > Maybe a single blank line ?
> >
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> I've gone thru and updated schemas to use this. Primarily to prove out
> a meta-schema for it. So I'll be sending out another version.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-11 14:27 ` Laurent Pinchart
0 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-11 14:27 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Laurent Pinchart, Kuninori Morimoto, Sameer Pujar,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi,
Sam Ravnborg
Hi Rob,
On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > From: Sameer Pujar <spujar@nvidia.com>
> > >
> > > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > > doc is referenced in multiple files and all of these need to use schema
> > > references. For now graph.txt is updated to refer to graph.yaml.
> > >
> > > For users of the graph binding, they should reference to the graph
> > > schema from either 'ports' or 'port' property:
> > >
> > > properties:
> > > ports:
> > > type: object
> > > $ref: graph.yaml#/properties/ports
> > >
> > > properties:
> > > port@0:
> > > description: What data this port has
> > >
> > > ...
> > >
> > > Or:
> > >
> > > properties:
> > > port:
> > > description: What data this port has
> > > type: object
> > > $ref: graph.yaml#/properties/port
> >
> > Sounds like a good approach.
> >
> > > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > ---
> > > v3:
> > > - Move port 'reg' to port@* and make required
> > > - Make remote-endpoint required
> > > - Add 'additionalProperties: true' now required
> > > - Fix yamllint warnings
> > >
> > > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > > 2 files changed, 200 insertions(+), 128 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/graph.yaml
>
> [...]
>
> > > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > > new file mode 100644
> > > index 000000000000..b56720c5a13e
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/graph.yaml
> > > @@ -0,0 +1,199 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/graph.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Common bindings for device graphs
> > > +
> > > +description: |
> > > + The hierarchical organisation of the device tree is well suited to describe
> > > + control flow to devices, but there can be more complex connections between
> > > + devices that work together to form a logical compound device, following an
> > > + arbitrarily complex graph.
> > > + There already is a simple directed graph between devices tree nodes using
> > > + phandle properties pointing to other nodes to describe connections that
> > > + can not be inferred from device tree parent-child relationships. The device
> > > + tree graph bindings described herein abstract more complex devices that can
> > > + have multiple specifiable ports, each of which can be linked to one or more
> > > + ports of other devices.
> > > +
> > > + These common bindings do not contain any information about the direction or
> > > + type of the connections, they just map their existence. Specific properties
> > > + may be described by specialized bindings depending on the type of connection.
> > > +
> > > + To see how this binding applies to video pipelines, for example, see
> > > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > + Here the ports describe data interfaces, and the links between them are
> > > + the connecting data buses. A single port with multiple connections can
> > > + correspond to multiple devices being connected to the same physical bus.
> > > +
> > > +maintainers:
> > > + - Philipp Zabel <p.zabel@pengutronix.de>
> > > +
> > > +select: false
> > > +
> > > +properties:
> > > + port:
> > > + type: object
> > > + description:
> > > + If there is more than one endpoint node or 'reg' property present in
> > > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > > + required.
> > > +
> > > + properties:
> > > + "#address-cells":
> > > + const: 1
> > > +
> > > + "#size-cells":
> > > + const: 0
> > > +
> > > + patternProperties:
> > > + "^endpoint(@[0-9a-f]+)?$":
> > > + type: object
> > > + properties:
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + remote-endpoint:
> > > + description: |
> > > + phandle to an 'endpoint' subnode of a remote device node.
> > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > +
> > > + required:
> > > + - remote-endpoint
> >
> > As noted elsewhere, this shouldn't be required.
> >
> > Should we set additionalProperties: false here ?
>
> No, we've got a bunch of properties that get added to endpoint nodes.
> There's a few cases where 'port' nodes have properties too.
I meant the port node, which I wasn't aware needed additional
properties. Do you have any example ? (I wonder if you will point me to
bindings that I have written ;-))
> > > + ports:
> > > + type: object
> > > + description: |
> > > + If there is more than one port node or 'reg' property present in port
> > > + nodes then '#address-cells' and '#size-cells' properties are required.
> > > + In such cases all port nodes can be grouped under 'ports' independently
> > > + from any other child device nodes a device might have.
> >
> > Allowing multiple port nodes not grouped in a ports node has created
> > complexity, with very little gain. Should we forbid that going forward ?
>
> Yes, that's probably a separate change. The examples need updating
> too. We do have a few cases we'll have to support though.
Sure, it can be done on top.
> > > + properties:
> > > + "#address-cells":
> > > + const: 1
> > > +
> > > + "#size-cells":
> > > + const: 0
> > > +
> > > + patternProperties:
> > > + "^port(@[0-9a-f]+)?$":
> > > + $ref: "#/properties/port"
> > > + type: object
> > > +
> > > + properties:
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + required:
> > > + - reg
> > > +
> > > +
> >
> > Maybe a single blank line ?
> >
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> I've gone thru and updated schemas to use this. Primarily to prove out
> a meta-schema for it. So I'll be sending out another version.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-11 14:27 ` Laurent Pinchart
@ 2020-11-11 23:03 ` Rob Herring
-1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-11 23:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, Sameer Pujar, Laurent Pinchart, dri-devel,
linux-kernel, Thierry Reding, Sam Ravnborg, Philipp Zabel,
Kuninori Morimoto, Jacopo Mondi
On Wed, Nov 11, 2020 at 8:27 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Rob,
>
> On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> > On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > > From: Sameer Pujar <spujar@nvidia.com>
> > > >
> > > > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > > > doc is referenced in multiple files and all of these need to use schema
> > > > references. For now graph.txt is updated to refer to graph.yaml.
> > > >
> > > > For users of the graph binding, they should reference to the graph
> > > > schema from either 'ports' or 'port' property:
> > > >
> > > > properties:
> > > > ports:
> > > > type: object
> > > > $ref: graph.yaml#/properties/ports
> > > >
> > > > properties:
> > > > port@0:
> > > > description: What data this port has
> > > >
> > > > ...
> > > >
> > > > Or:
> > > >
> > > > properties:
> > > > port:
> > > > description: What data this port has
> > > > type: object
> > > > $ref: graph.yaml#/properties/port
> > >
> > > Sounds like a good approach.
> > >
> > > > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > ---
> > > > v3:
> > > > - Move port 'reg' to port@* and make required
> > > > - Make remote-endpoint required
> > > > - Add 'additionalProperties: true' now required
> > > > - Fix yamllint warnings
> > > >
> > > > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > > > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > > > 2 files changed, 200 insertions(+), 128 deletions(-)
> > > > create mode 100644 Documentation/devicetree/bindings/graph.yaml
> >
> > [...]
> >
> > > > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > > > new file mode 100644
> > > > index 000000000000..b56720c5a13e
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/graph.yaml
> > > > @@ -0,0 +1,199 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/graph.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Common bindings for device graphs
> > > > +
> > > > +description: |
> > > > + The hierarchical organisation of the device tree is well suited to describe
> > > > + control flow to devices, but there can be more complex connections between
> > > > + devices that work together to form a logical compound device, following an
> > > > + arbitrarily complex graph.
> > > > + There already is a simple directed graph between devices tree nodes using
> > > > + phandle properties pointing to other nodes to describe connections that
> > > > + can not be inferred from device tree parent-child relationships. The device
> > > > + tree graph bindings described herein abstract more complex devices that can
> > > > + have multiple specifiable ports, each of which can be linked to one or more
> > > > + ports of other devices.
> > > > +
> > > > + These common bindings do not contain any information about the direction or
> > > > + type of the connections, they just map their existence. Specific properties
> > > > + may be described by specialized bindings depending on the type of connection.
> > > > +
> > > > + To see how this binding applies to video pipelines, for example, see
> > > > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > > + Here the ports describe data interfaces, and the links between them are
> > > > + the connecting data buses. A single port with multiple connections can
> > > > + correspond to multiple devices being connected to the same physical bus.
> > > > +
> > > > +maintainers:
> > > > + - Philipp Zabel <p.zabel@pengutronix.de>
> > > > +
> > > > +select: false
> > > > +
> > > > +properties:
> > > > + port:
> > > > + type: object
> > > > + description:
> > > > + If there is more than one endpoint node or 'reg' property present in
> > > > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > > > + required.
> > > > +
> > > > + properties:
> > > > + "#address-cells":
> > > > + const: 1
> > > > +
> > > > + "#size-cells":
> > > > + const: 0
> > > > +
> > > > + patternProperties:
> > > > + "^endpoint(@[0-9a-f]+)?$":
> > > > + type: object
> > > > + properties:
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + remote-endpoint:
> > > > + description: |
> > > > + phandle to an 'endpoint' subnode of a remote device node.
> > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > +
> > > > + required:
> > > > + - remote-endpoint
> > >
> > > As noted elsewhere, this shouldn't be required.
> > >
> > > Should we set additionalProperties: false here ?
> >
> > No, we've got a bunch of properties that get added to endpoint nodes.
> > There's a few cases where 'port' nodes have properties too.
>
> I meant the port node, which I wasn't aware needed additional
> properties. Do you have any example ? (I wonder if you will point me to
> bindings that I have written ;-))
Not you, but Renesas. dual-lvds-{odd,even}-pixels was the only one I
think. But really, I think we could actually drop those if the port
numbering defines even/odd instead. There's a patch I just reviewed
for common dual lane panels. See
1604993797-14240-1-git-send-email-victor.liu@nxp.com
Rob
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-11 23:03 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-11 23:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, Laurent Pinchart, Kuninori Morimoto, Sameer Pujar,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi,
Sam Ravnborg
On Wed, Nov 11, 2020 at 8:27 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Rob,
>
> On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> > On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > > From: Sameer Pujar <spujar@nvidia.com>
> > > >
> > > > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > > > doc is referenced in multiple files and all of these need to use schema
> > > > references. For now graph.txt is updated to refer to graph.yaml.
> > > >
> > > > For users of the graph binding, they should reference to the graph
> > > > schema from either 'ports' or 'port' property:
> > > >
> > > > properties:
> > > > ports:
> > > > type: object
> > > > $ref: graph.yaml#/properties/ports
> > > >
> > > > properties:
> > > > port@0:
> > > > description: What data this port has
> > > >
> > > > ...
> > > >
> > > > Or:
> > > >
> > > > properties:
> > > > port:
> > > > description: What data this port has
> > > > type: object
> > > > $ref: graph.yaml#/properties/port
> > >
> > > Sounds like a good approach.
> > >
> > > > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > ---
> > > > v3:
> > > > - Move port 'reg' to port@* and make required
> > > > - Make remote-endpoint required
> > > > - Add 'additionalProperties: true' now required
> > > > - Fix yamllint warnings
> > > >
> > > > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > > > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > > > 2 files changed, 200 insertions(+), 128 deletions(-)
> > > > create mode 100644 Documentation/devicetree/bindings/graph.yaml
> >
> > [...]
> >
> > > > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > > > new file mode 100644
> > > > index 000000000000..b56720c5a13e
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/graph.yaml
> > > > @@ -0,0 +1,199 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/graph.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Common bindings for device graphs
> > > > +
> > > > +description: |
> > > > + The hierarchical organisation of the device tree is well suited to describe
> > > > + control flow to devices, but there can be more complex connections between
> > > > + devices that work together to form a logical compound device, following an
> > > > + arbitrarily complex graph.
> > > > + There already is a simple directed graph between devices tree nodes using
> > > > + phandle properties pointing to other nodes to describe connections that
> > > > + can not be inferred from device tree parent-child relationships. The device
> > > > + tree graph bindings described herein abstract more complex devices that can
> > > > + have multiple specifiable ports, each of which can be linked to one or more
> > > > + ports of other devices.
> > > > +
> > > > + These common bindings do not contain any information about the direction or
> > > > + type of the connections, they just map their existence. Specific properties
> > > > + may be described by specialized bindings depending on the type of connection.
> > > > +
> > > > + To see how this binding applies to video pipelines, for example, see
> > > > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > > + Here the ports describe data interfaces, and the links between them are
> > > > + the connecting data buses. A single port with multiple connections can
> > > > + correspond to multiple devices being connected to the same physical bus.
> > > > +
> > > > +maintainers:
> > > > + - Philipp Zabel <p.zabel@pengutronix.de>
> > > > +
> > > > +select: false
> > > > +
> > > > +properties:
> > > > + port:
> > > > + type: object
> > > > + description:
> > > > + If there is more than one endpoint node or 'reg' property present in
> > > > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > > > + required.
> > > > +
> > > > + properties:
> > > > + "#address-cells":
> > > > + const: 1
> > > > +
> > > > + "#size-cells":
> > > > + const: 0
> > > > +
> > > > + patternProperties:
> > > > + "^endpoint(@[0-9a-f]+)?$":
> > > > + type: object
> > > > + properties:
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + remote-endpoint:
> > > > + description: |
> > > > + phandle to an 'endpoint' subnode of a remote device node.
> > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > +
> > > > + required:
> > > > + - remote-endpoint
> > >
> > > As noted elsewhere, this shouldn't be required.
> > >
> > > Should we set additionalProperties: false here ?
> >
> > No, we've got a bunch of properties that get added to endpoint nodes.
> > There's a few cases where 'port' nodes have properties too.
>
> I meant the port node, which I wasn't aware needed additional
> properties. Do you have any example ? (I wonder if you will point me to
> bindings that I have written ;-))
Not you, but Renesas. dual-lvds-{odd,even}-pixels was the only one I
think. But really, I think we could actually drop those if the port
numbering defines even/odd instead. There's a patch I just reviewed
for common dual lane panels. See
1604993797-14240-1-git-send-email-victor.liu@nxp.com
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-11 23:03 ` Rob Herring
@ 2020-11-12 7:56 ` Laurent Pinchart
-1 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-12 7:56 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Sameer Pujar, Laurent Pinchart, dri-devel,
linux-kernel, Thierry Reding, Sam Ravnborg, Philipp Zabel,
Kuninori Morimoto, Jacopo Mondi
Hi Rob,
On Wed, Nov 11, 2020 at 05:03:26PM -0600, Rob Herring wrote:
> On Wed, Nov 11, 2020 at 8:27 AM Laurent Pinchart wrote:
> > On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> > > On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > > > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > > > From: Sameer Pujar <spujar@nvidia.com>
> > > > >
> > > > > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > > > > doc is referenced in multiple files and all of these need to use schema
> > > > > references. For now graph.txt is updated to refer to graph.yaml.
> > > > >
> > > > > For users of the graph binding, they should reference to the graph
> > > > > schema from either 'ports' or 'port' property:
> > > > >
> > > > > properties:
> > > > > ports:
> > > > > type: object
> > > > > $ref: graph.yaml#/properties/ports
> > > > >
> > > > > properties:
> > > > > port@0:
> > > > > description: What data this port has
> > > > >
> > > > > ...
> > > > >
> > > > > Or:
> > > > >
> > > > > properties:
> > > > > port:
> > > > > description: What data this port has
> > > > > type: object
> > > > > $ref: graph.yaml#/properties/port
> > > >
> > > > Sounds like a good approach.
> > > >
> > > > > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > > ---
> > > > > v3:
> > > > > - Move port 'reg' to port@* and make required
> > > > > - Make remote-endpoint required
> > > > > - Add 'additionalProperties: true' now required
> > > > > - Fix yamllint warnings
> > > > >
> > > > > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > > > > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > > > > 2 files changed, 200 insertions(+), 128 deletions(-)
> > > > > create mode 100644 Documentation/devicetree/bindings/graph.yaml
> > >
> > > [...]
> > >
> > > > > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..b56720c5a13e
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/graph.yaml
> > > > > @@ -0,0 +1,199 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/graph.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Common bindings for device graphs
> > > > > +
> > > > > +description: |
> > > > > + The hierarchical organisation of the device tree is well suited to describe
> > > > > + control flow to devices, but there can be more complex connections between
> > > > > + devices that work together to form a logical compound device, following an
> > > > > + arbitrarily complex graph.
> > > > > + There already is a simple directed graph between devices tree nodes using
> > > > > + phandle properties pointing to other nodes to describe connections that
> > > > > + can not be inferred from device tree parent-child relationships. The device
> > > > > + tree graph bindings described herein abstract more complex devices that can
> > > > > + have multiple specifiable ports, each of which can be linked to one or more
> > > > > + ports of other devices.
> > > > > +
> > > > > + These common bindings do not contain any information about the direction or
> > > > > + type of the connections, they just map their existence. Specific properties
> > > > > + may be described by specialized bindings depending on the type of connection.
> > > > > +
> > > > > + To see how this binding applies to video pipelines, for example, see
> > > > > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > > > + Here the ports describe data interfaces, and the links between them are
> > > > > + the connecting data buses. A single port with multiple connections can
> > > > > + correspond to multiple devices being connected to the same physical bus.
> > > > > +
> > > > > +maintainers:
> > > > > + - Philipp Zabel <p.zabel@pengutronix.de>
> > > > > +
> > > > > +select: false
> > > > > +
> > > > > +properties:
> > > > > + port:
> > > > > + type: object
> > > > > + description:
> > > > > + If there is more than one endpoint node or 'reg' property present in
> > > > > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > > > > + required.
> > > > > +
> > > > > + properties:
> > > > > + "#address-cells":
> > > > > + const: 1
> > > > > +
> > > > > + "#size-cells":
> > > > > + const: 0
> > > > > +
> > > > > + patternProperties:
> > > > > + "^endpoint(@[0-9a-f]+)?$":
> > > > > + type: object
> > > > > + properties:
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + remote-endpoint:
> > > > > + description: |
> > > > > + phandle to an 'endpoint' subnode of a remote device node.
> > > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > > +
> > > > > + required:
> > > > > + - remote-endpoint
> > > >
> > > > As noted elsewhere, this shouldn't be required.
> > > >
> > > > Should we set additionalProperties: false here ?
> > >
> > > No, we've got a bunch of properties that get added to endpoint nodes.
> > > There's a few cases where 'port' nodes have properties too.
> >
> > I meant the port node, which I wasn't aware needed additional
> > properties. Do you have any example ? (I wonder if you will point me to
> > bindings that I have written ;-))
>
> Not you, but Renesas. dual-lvds-{odd,even}-pixels was the only one I
> think. But really, I think we could actually drop those if the port
> numbering defines even/odd instead. There's a patch I just reviewed
> for common dual lane panels. See
> 1604993797-14240-1-git-send-email-victor.liu@nxp.com
We've discussed this before, see
Subject: Re: [PATCH v2 7/9] drm: rcar-du: lvds: Add dual-LVDS panels support
Message-ID: <20190815130834.GM5011@pendragon.ideasonboard.com>
"But what will then happen if you panel has more than two ports (for
audio for instance, or for other types of video links) ? It may not be
possible to always use port 0 and 1 for the LVDS even and odd pixels in
DT bindings of a particular panel or bridge."
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-12 7:56 ` Laurent Pinchart
0 siblings, 0 replies; 34+ messages in thread
From: Laurent Pinchart @ 2020-11-12 7:56 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Laurent Pinchart, Kuninori Morimoto, Sameer Pujar,
linux-kernel, dri-devel, Thierry Reding, Jacopo Mondi,
Sam Ravnborg
Hi Rob,
On Wed, Nov 11, 2020 at 05:03:26PM -0600, Rob Herring wrote:
> On Wed, Nov 11, 2020 at 8:27 AM Laurent Pinchart wrote:
> > On Wed, Nov 11, 2020 at 08:25:40AM -0600, Rob Herring wrote:
> > > On Wed, Nov 11, 2020 at 8:00 AM Laurent Pinchart wrote:
> > > > On Mon, Nov 02, 2020 at 02:36:54PM -0600, Rob Herring wrote:
> > > > > From: Sameer Pujar <spujar@nvidia.com>
> > > > >
> > > > > Convert device tree bindings of graph to YAML format. Currently graph.txt
> > > > > doc is referenced in multiple files and all of these need to use schema
> > > > > references. For now graph.txt is updated to refer to graph.yaml.
> > > > >
> > > > > For users of the graph binding, they should reference to the graph
> > > > > schema from either 'ports' or 'port' property:
> > > > >
> > > > > properties:
> > > > > ports:
> > > > > type: object
> > > > > $ref: graph.yaml#/properties/ports
> > > > >
> > > > > properties:
> > > > > port@0:
> > > > > description: What data this port has
> > > > >
> > > > > ...
> > > > >
> > > > > Or:
> > > > >
> > > > > properties:
> > > > > port:
> > > > > description: What data this port has
> > > > > type: object
> > > > > $ref: graph.yaml#/properties/port
> > > >
> > > > Sounds like a good approach.
> > > >
> > > > > Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> > > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > > ---
> > > > > v3:
> > > > > - Move port 'reg' to port@* and make required
> > > > > - Make remote-endpoint required
> > > > > - Add 'additionalProperties: true' now required
> > > > > - Fix yamllint warnings
> > > > >
> > > > > Documentation/devicetree/bindings/graph.txt | 129 +-----------
> > > > > Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> > > > > 2 files changed, 200 insertions(+), 128 deletions(-)
> > > > > create mode 100644 Documentation/devicetree/bindings/graph.yaml
> > >
> > > [...]
> > >
> > > > > diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> > > > > new file mode 100644
> > > > > index 000000000000..b56720c5a13e
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/graph.yaml
> > > > > @@ -0,0 +1,199 @@
> > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/graph.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: Common bindings for device graphs
> > > > > +
> > > > > +description: |
> > > > > + The hierarchical organisation of the device tree is well suited to describe
> > > > > + control flow to devices, but there can be more complex connections between
> > > > > + devices that work together to form a logical compound device, following an
> > > > > + arbitrarily complex graph.
> > > > > + There already is a simple directed graph between devices tree nodes using
> > > > > + phandle properties pointing to other nodes to describe connections that
> > > > > + can not be inferred from device tree parent-child relationships. The device
> > > > > + tree graph bindings described herein abstract more complex devices that can
> > > > > + have multiple specifiable ports, each of which can be linked to one or more
> > > > > + ports of other devices.
> > > > > +
> > > > > + These common bindings do not contain any information about the direction or
> > > > > + type of the connections, they just map their existence. Specific properties
> > > > > + may be described by specialized bindings depending on the type of connection.
> > > > > +
> > > > > + To see how this binding applies to video pipelines, for example, see
> > > > > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > > > > + Here the ports describe data interfaces, and the links between them are
> > > > > + the connecting data buses. A single port with multiple connections can
> > > > > + correspond to multiple devices being connected to the same physical bus.
> > > > > +
> > > > > +maintainers:
> > > > > + - Philipp Zabel <p.zabel@pengutronix.de>
> > > > > +
> > > > > +select: false
> > > > > +
> > > > > +properties:
> > > > > + port:
> > > > > + type: object
> > > > > + description:
> > > > > + If there is more than one endpoint node or 'reg' property present in
> > > > > + endpoint nodes then '#address-cells' and '#size-cells' properties are
> > > > > + required.
> > > > > +
> > > > > + properties:
> > > > > + "#address-cells":
> > > > > + const: 1
> > > > > +
> > > > > + "#size-cells":
> > > > > + const: 0
> > > > > +
> > > > > + patternProperties:
> > > > > + "^endpoint(@[0-9a-f]+)?$":
> > > > > + type: object
> > > > > + properties:
> > > > > + reg:
> > > > > + maxItems: 1
> > > > > +
> > > > > + remote-endpoint:
> > > > > + description: |
> > > > > + phandle to an 'endpoint' subnode of a remote device node.
> > > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > > +
> > > > > + required:
> > > > > + - remote-endpoint
> > > >
> > > > As noted elsewhere, this shouldn't be required.
> > > >
> > > > Should we set additionalProperties: false here ?
> > >
> > > No, we've got a bunch of properties that get added to endpoint nodes.
> > > There's a few cases where 'port' nodes have properties too.
> >
> > I meant the port node, which I wasn't aware needed additional
> > properties. Do you have any example ? (I wonder if you will point me to
> > bindings that I have written ;-))
>
> Not you, but Renesas. dual-lvds-{odd,even}-pixels was the only one I
> think. But really, I think we could actually drop those if the port
> numbering defines even/odd instead. There's a patch I just reviewed
> for common dual lane panels. See
> 1604993797-14240-1-git-send-email-victor.liu@nxp.com
We've discussed this before, see
Subject: Re: [PATCH v2 7/9] drm: rcar-du: lvds: Add dual-LVDS panels support
Message-ID: <20190815130834.GM5011@pendragon.ideasonboard.com>
"But what will then happen if you panel has more than two ports (for
audio for instance, or for other types of video links) ? It may not be
possible to always use port 0 and 1 for the LVDS even and odd pixels in
DT bindings of a particular panel or bridge."
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
2020-11-02 20:36 ` Rob Herring
@ 2020-11-12 20:49 ` Rob Herring
-1 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-12 20:49 UTC (permalink / raw)
To: Sameer Pujar, Laurent Pinchart, Sam Ravnborg, Mark Brown
Cc: dri-devel, linux-kernel, Thierry Reding, Philipp Zabel,
Kuninori Morimoto, Jacopo Mondi, devicetree
On Mon, Nov 2, 2020 at 2:36 PM Rob Herring <robh@kernel.org> wrote:
>
> From: Sameer Pujar <spujar@nvidia.com>
>
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to refer to graph.yaml.
>
> For users of the graph binding, they should reference to the graph
> schema from either 'ports' or 'port' property:
>
> properties:
> ports:
> type: object
> $ref: graph.yaml#/properties/ports
>
> properties:
> port@0:
> description: What data this port has
>
> ...
>
> Or:
>
> properties:
> port:
> description: What data this port has
> type: object
> $ref: graph.yaml#/properties/port
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> v3:
> - Move port 'reg' to port@* and make required
> - Make remote-endpoint required
> - Add 'additionalProperties: true' now required
> - Fix yamllint warnings
>
> Documentation/devicetree/bindings/graph.txt | 129 +-----------
> Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> 2 files changed, 200 insertions(+), 128 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/graph.yaml
I've decided to move this to the dt-schema repo instead[1]. I think
that will be easier to manage dependencies (audio-graph.yaml plus
anything else landing this cycle) than subsystems pulling a shared
branch. I haven't merged it yet, so let me know if any
comments/objections. Note that the meta-schema will have to come a bit
later once existing users are updated (which I have patches for).
Rob
[1] https://github.com/devicetree-org/dt-schema/tree/of-graph
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema
@ 2020-11-12 20:49 ` Rob Herring
0 siblings, 0 replies; 34+ messages in thread
From: Rob Herring @ 2020-11-12 20:49 UTC (permalink / raw)
To: Sameer Pujar, Laurent Pinchart, Sam Ravnborg, Mark Brown
Cc: devicetree, Kuninori Morimoto, linux-kernel, dri-devel,
Thierry Reding, Jacopo Mondi
On Mon, Nov 2, 2020 at 2:36 PM Rob Herring <robh@kernel.org> wrote:
>
> From: Sameer Pujar <spujar@nvidia.com>
>
> Convert device tree bindings of graph to YAML format. Currently graph.txt
> doc is referenced in multiple files and all of these need to use schema
> references. For now graph.txt is updated to refer to graph.yaml.
>
> For users of the graph binding, they should reference to the graph
> schema from either 'ports' or 'port' property:
>
> properties:
> ports:
> type: object
> $ref: graph.yaml#/properties/ports
>
> properties:
> port@0:
> description: What data this port has
>
> ...
>
> Or:
>
> properties:
> port:
> description: What data this port has
> type: object
> $ref: graph.yaml#/properties/port
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> v3:
> - Move port 'reg' to port@* and make required
> - Make remote-endpoint required
> - Add 'additionalProperties: true' now required
> - Fix yamllint warnings
>
> Documentation/devicetree/bindings/graph.txt | 129 +-----------
> Documentation/devicetree/bindings/graph.yaml | 199 +++++++++++++++++++
> 2 files changed, 200 insertions(+), 128 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/graph.yaml
I've decided to move this to the dt-schema repo instead[1]. I think
that will be easier to manage dependencies (audio-graph.yaml plus
anything else landing this cycle) than subsystems pulling a shared
branch. I haven't merged it yet, so let me know if any
comments/objections. Note that the meta-schema will have to come a bit
later once existing users are updated (which I have patches for).
Rob
[1] https://github.com/devicetree-org/dt-schema/tree/of-graph
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2020-11-12 20:49 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-02 20:36 [PATCH v3 0/3] dt-bindings: Convert graph bindings to json-schema Rob Herring
2020-11-02 20:36 ` Rob Herring
2020-11-02 20:36 ` [PATCH v3 1/3] " Rob Herring
2020-11-02 20:36 ` Rob Herring
2020-11-05 21:43 ` Sam Ravnborg
2020-11-05 21:43 ` Sam Ravnborg
2020-11-11 9:51 ` Sameer Pujar
2020-11-11 9:51 ` Sameer Pujar
2020-11-11 13:35 ` Rob Herring
2020-11-11 13:35 ` Rob Herring
2020-11-11 14:00 ` Laurent Pinchart
2020-11-11 14:00 ` Laurent Pinchart
2020-11-11 14:25 ` Rob Herring
2020-11-11 14:25 ` Rob Herring
2020-11-11 14:27 ` Laurent Pinchart
2020-11-11 14:27 ` Laurent Pinchart
2020-11-11 23:03 ` Rob Herring
2020-11-11 23:03 ` Rob Herring
2020-11-12 7:56 ` Laurent Pinchart
2020-11-12 7:56 ` Laurent Pinchart
2020-11-12 20:49 ` Rob Herring
2020-11-12 20:49 ` Rob Herring
2020-11-02 20:36 ` [PATCH v3 2/3] dt-bindings: usb-connector: Add reference to graph schema Rob Herring
2020-11-02 20:36 ` Rob Herring
2020-11-11 14:01 ` Laurent Pinchart
2020-11-11 14:01 ` Laurent Pinchart
2020-11-02 20:36 ` [PATCH v3 3/3] dt-bindings: panel: common: " Rob Herring
2020-11-02 20:36 ` Rob Herring
2020-11-05 21:46 ` Sam Ravnborg
2020-11-05 21:46 ` Sam Ravnborg
2020-11-11 14:02 ` Laurent Pinchart
2020-11-11 14:02 ` Laurent Pinchart
2020-11-03 6:05 ` [PATCH v3 0/3] dt-bindings: Convert graph bindings to json-schema Sameer Pujar
2020-11-03 6:05 ` Sameer Pujar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.