All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Sameer Pujar <spujar@nvidia.com>
Cc: broonie@kernel.org, lgirdwood@gmail.com,
	kuninori.morimoto.gx@renesas.com,
	pierre-louis.bossart@linux.intel.com, perex@perex.cz,
	tiwai@suse.com, p.zabel@pengutronix.de, thierry.reding@gmail.com,
	jonathanh@nvidia.com, alsa-devel@alsa-project.org,
	devicetree@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org, sharadg@nvidia.com,
	mkumard@nvidia.com, viswanathl@nvidia.com, rlokhande@nvidia.com,
	dramesh@nvidia.com, atalambedu@nvidia.com, nwartikar@nvidia.com,
	swarren@nvidia.com, nicoleotsuka@gmail.com
Subject: Re: [PATCH v4 08/15] Documentation: of: Convert graph bindings to json-schema
Date: Mon, 19 Oct 2020 16:56:28 -0500	[thread overview]
Message-ID: <20201019215628.GA3650804@bogus> (raw)
In-Reply-To: <1602859382-19505-9-git-send-email-spujar@nvidia.com>

On Fri, Oct 16, 2020 at 08:12:55PM +0530, Sameer Pujar wrote:
> Convert device tree bindings of graph to YAML format.

Thanks for doing this.

> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> ---
>  Documentation/devicetree/bindings/graph.txt  | 128 --------------------
>  Documentation/devicetree/bindings/graph.yaml | 170 +++++++++++++++++++++++++++
>  2 files changed, 170 insertions(+), 128 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/graph.txt
>  create mode 100644 Documentation/devicetree/bindings/graph.yaml

I'd like to move this to the dtschema repository instead.

> diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> new file mode 100644
> index 0000000..67804c1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/graph.yaml
> @@ -0,0 +1,170 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

As the original text defaulted to GPL2, this needs Philipp's permission 
to re-license.

> +%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>
> +
> +definitions:
> +
> +  port:
> +    type: object
> +    description: |
> +      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
> +      '#address-cells' and '#size-cells' properties are required in relevant
> +      parent node.

reg property.

> +
> +    patternProperties:
> +      "^endpoint(@[0-9a-f]+)?$":
> +        type: object
> +        properties:

reg?

> +          remote-endpoint:
> +            description: |
> +              phandle to an 'endpoint' subnode of a remote device node.
> +            $ref: /schemas/types.yaml#/definitions/phandle
> +
> +  ports:
> +    type: object
> +    patternProperties:
> +      "^port(@[0-9a-f]+)?$":
> +        $ref: "#/definitions/port"

No reason for this to be under 'definitions'. Just move down.

> +
> +properties:
> +  ports:
> +    $ref: "#/definitions/ports"
> +
> +patternProperties:
> +  "^port(@[0-9a-f]+)?$":
> +    $ref: "#/definitions/port"
> +
> +additionalProperties: false

This needs to be true here. But you need this within 'ports' and 'port'. 
(I think... I think we only have extra properties within endpoint 
nodes.) 

> +
> +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.7.4
> 

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Sameer Pujar <spujar@nvidia.com>
Cc: alsa-devel@alsa-project.org, kuninori.morimoto.gx@renesas.com,
	atalambedu@nvidia.com, linux-kernel@vger.kernel.org,
	thierry.reding@gmail.com, rlokhande@nvidia.com,
	swarren@nvidia.com, tiwai@suse.com,
	pierre-louis.bossart@linux.intel.com, jonathanh@nvidia.com,
	devicetree@vger.kernel.org, nicoleotsuka@gmail.com,
	broonie@kernel.org, linux-tegra@vger.kernel.org,
	mkumard@nvidia.com, viswanathl@nvidia.com, lgirdwood@gmail.com,
	nwartikar@nvidia.com, p.zabel@pengutronix.de, sharadg@nvidia.com,
	dramesh@nvidia.com
Subject: Re: [PATCH v4 08/15] Documentation: of: Convert graph bindings to json-schema
Date: Mon, 19 Oct 2020 16:56:28 -0500	[thread overview]
Message-ID: <20201019215628.GA3650804@bogus> (raw)
In-Reply-To: <1602859382-19505-9-git-send-email-spujar@nvidia.com>

On Fri, Oct 16, 2020 at 08:12:55PM +0530, Sameer Pujar wrote:
> Convert device tree bindings of graph to YAML format.

Thanks for doing this.

> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> ---
>  Documentation/devicetree/bindings/graph.txt  | 128 --------------------
>  Documentation/devicetree/bindings/graph.yaml | 170 +++++++++++++++++++++++++++
>  2 files changed, 170 insertions(+), 128 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/graph.txt
>  create mode 100644 Documentation/devicetree/bindings/graph.yaml

I'd like to move this to the dtschema repository instead.

> diff --git a/Documentation/devicetree/bindings/graph.yaml b/Documentation/devicetree/bindings/graph.yaml
> new file mode 100644
> index 0000000..67804c1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/graph.yaml
> @@ -0,0 +1,170 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)

As the original text defaulted to GPL2, this needs Philipp's permission 
to re-license.

> +%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>
> +
> +definitions:
> +
> +  port:
> +    type: object
> +    description: |
> +      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
> +      '#address-cells' and '#size-cells' properties are required in relevant
> +      parent node.

reg property.

> +
> +    patternProperties:
> +      "^endpoint(@[0-9a-f]+)?$":
> +        type: object
> +        properties:

reg?

> +          remote-endpoint:
> +            description: |
> +              phandle to an 'endpoint' subnode of a remote device node.
> +            $ref: /schemas/types.yaml#/definitions/phandle
> +
> +  ports:
> +    type: object
> +    patternProperties:
> +      "^port(@[0-9a-f]+)?$":
> +        $ref: "#/definitions/port"

No reason for this to be under 'definitions'. Just move down.

> +
> +properties:
> +  ports:
> +    $ref: "#/definitions/ports"
> +
> +patternProperties:
> +  "^port(@[0-9a-f]+)?$":
> +    $ref: "#/definitions/port"
> +
> +additionalProperties: false

This needs to be true here. But you need this within 'ports' and 'port'. 
(I think... I think we only have extra properties within endpoint 
nodes.) 

> +
> +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.7.4
> 

  reply	other threads:[~2020-10-19 21:56 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-16 14:42 [PATCH v4 00/15] Audio graph card updates and usage with Tegra210 audio Sameer Pujar
2020-10-16 14:42 ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 01/15] ASoC: soc-core: Fix component name_prefix parsing Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 02/15] ASoC: soc-pcm: Get all BEs along DAPM path Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 03/15] ASoC: audio-graph: Use of_node and DAI for DPCM DAI link names Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 04/15] ASoC: audio-graph: Identify 'no_pcm' DAI links for DPCM Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 05/15] ASoC: audio-graph: Support empty Codec endpoint Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 06/15] ASoC: audio-graph: Expose new members for asoc_simple_priv Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 07/15] ASoC: audio-graph: Expose helpers from audio graph Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 08/15] Documentation: of: Convert graph bindings to json-schema Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-19 21:56   ` Rob Herring [this message]
2020-10-19 21:56     ` Rob Herring
2020-10-20  5:34     ` Sameer Pujar
2020-10-20  5:34       ` Sameer Pujar
2020-10-20  8:30     ` Philipp Zabel
2020-10-20  8:30       ` Philipp Zabel
2020-10-23 13:45       ` Sameer Pujar
2020-10-23 13:45         ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 09/15] ASoC: dt-bindings: audio-graph: Convert " Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-19  2:50   ` Kuninori Morimoto
2020-10-19  2:50     ` Kuninori Morimoto
2020-10-19  4:30     ` Sameer Pujar
2020-10-19  4:30       ` Sameer Pujar
2020-10-19  4:41       ` Kuninori Morimoto
2020-10-19  4:41         ` Kuninori Morimoto
2020-10-19 22:11         ` Rob Herring
2020-10-19 22:11           ` Rob Herring
2020-10-16 14:42 ` [PATCH v4 10/15] ASoC: dt-bindings: tegra: Add graph bindings Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-19 22:11   ` Rob Herring
2020-10-19 22:11     ` Rob Herring
2020-10-20  6:03     ` Sameer Pujar
2020-10-20  6:03       ` Sameer Pujar
2020-10-16 14:42 ` [PATCH v4 11/15] ASoC: dt-bindings: tegra: Add json-schema for Tegra audio graph card Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-19 22:16   ` Rob Herring
2020-10-19 22:16     ` Rob Herring
2020-10-20  6:16     ` Sameer Pujar
2020-10-20  6:16       ` Sameer Pujar
2020-10-20 13:24       ` Rob Herring
2020-10-20 13:24         ` Rob Herring
2020-10-16 14:42 ` [PATCH v4 12/15] ASoC: tegra: Add audio graph based card driver Sameer Pujar
2020-10-16 14:42   ` Sameer Pujar
2020-10-16 14:43 ` [PATCH v4 13/15] arm64: defconfig: Enable Tegra audio graph " Sameer Pujar
2020-10-16 14:43   ` Sameer Pujar
2020-10-16 14:43 ` [PATCH v4 14/15] arm64: tegra: Audio graph header for Tegra210 Sameer Pujar
2020-10-16 14:43   ` Sameer Pujar
2020-10-16 14:43 ` [PATCH v4 15/15] arm64: tegra: Audio graph sound card for Jetson Nano and TX1 Sameer Pujar
2020-10-16 14:43   ` Sameer Pujar
2020-10-30  6:34 ` [PATCH v4 00/15] Audio graph card updates and usage with Tegra210 audio Sameer Pujar
2020-10-30  6:34   ` Sameer Pujar
2020-10-30 13:58   ` Mark Brown
2020-10-30 13:58     ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201019215628.GA3650804@bogus \
    --to=robh@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=atalambedu@nvidia.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dramesh@nvidia.com \
    --cc=jonathanh@nvidia.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mkumard@nvidia.com \
    --cc=nicoleotsuka@gmail.com \
    --cc=nwartikar@nvidia.com \
    --cc=p.zabel@pengutronix.de \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=rlokhande@nvidia.com \
    --cc=sharadg@nvidia.com \
    --cc=spujar@nvidia.com \
    --cc=swarren@nvidia.com \
    --cc=thierry.reding@gmail.com \
    --cc=tiwai@suse.com \
    --cc=viswanathl@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.