Messages in this thread | | | Subject | Re: [PATCH v3 1/3] dt-bindings: Convert graph bindings to json-schema | From | Sameer Pujar <> | Date | Wed, 11 Nov 2020 15:21:53 +0530 |
| |
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
| |