From: Rob Herring <robh@kernel.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Jon Hunter <jonathanh@nvidia.com>,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-tegra@vger.kernel.org
Subject: Re: [PATCH v3] dt-bindings: phy: tegra-xusb: Convert to json-schema
Date: Tue, 17 Jan 2023 12:49:31 -0600 [thread overview]
Message-ID: <20230117184931.GA3431713-robh@kernel.org> (raw)
In-Reply-To: <20230113150804.1272555-1-thierry.reding@gmail.com>
On Fri, Jan 13, 2023 at 04:08:04PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Convert the Tegra XUSB pad controller bindings from free-form text
> format to json-schema.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v3:
> - use | to keep paragraphs in multi-paragraph descriptions
> - move additionalProperties to improve readability
> - clarify that "status" can also be absent
> - drop phandle and status properties
> - remove quotes around references
> - use dual licensing
>
> Changes in v2:
> - split up into multiple schemas
>
> .../phy/nvidia,tegra124-xusb-padctl.txt | 779 -----------------
> .../phy/nvidia,tegra124-xusb-padctl.yaml | 654 +++++++++++++++
> .../phy/nvidia,tegra186-xusb-padctl.yaml | 544 ++++++++++++
> .../phy/nvidia,tegra194-xusb-padctl.yaml | 630 ++++++++++++++
> .../phy/nvidia,tegra210-xusb-padctl.yaml | 786 ++++++++++++++++++
> 5 files changed, 2614 insertions(+), 779 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt
> create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
> create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra186-xusb-padctl.yaml
> create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra194-xusb-padctl.yaml
> create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra210-xusb-padctl.yaml
>
> diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
> new file mode 100644
> index 000000000000..33b41b6b2fd5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.yaml
> @@ -0,0 +1,654 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/nvidia,tegra124-xusb-padctl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA Tegra124 XUSB pad controller
> +
> +maintainers:
> + - Thierry Reding <thierry.reding@gmail.com>
> + - Jon Hunter <jonathanh@nvidia.com>
> +
> +description: |
> + The Tegra XUSB pad controller manages a set of I/O lanes (with differential
> + signals) which connect directly to pins/pads on the SoC package. Each lane
> + is controlled by a HW block referred to as a "pad" in the Tegra hardware
> + documentation. Each such "pad" may control either one or multiple lanes,
> + and thus contains any logic common to all its lanes. Each lane can be
> + separately configured and powered up.
> +
> + Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or
> + super-speed USB. Other lanes are for various types of low-speed, full-speed
> + or high-speed USB (such as UTMI, ULPI and HSIC). The XUSB pad controller
> + contains a software-configurable mux that sits between the I/O controller
> + ports (e.g. PCIe) and the lanes.
> +
> + In addition to per-lane configuration, USB 3.0 ports may require additional
> + settings on a per-board basis.
> +
> + Pads will be represented as children of the top-level XUSB pad controller
> + device tree node. Each lane exposed by the pad will be represented by its
> + own subnode and can be referenced by users of the lane using the standard
> + PHY bindings, as described by the phy-bindings.txt file in this directory.
> +
> + The Tegra hardware documentation refers to the connection between the XUSB
> + pad controller and the XUSB controller as "ports". This is confusing since
> + "port" is typically used to denote the physical USB receptacle. The device
> + tree binding in this document uses the term "port" to refer to the logical
> + abstraction of the signals that are routed to a USB receptacle (i.e. a PHY
> + for the USB signal, the VBUS power supply, the USB 2.0 companion port for
> + USB 3.0 receptacles, ...).
> +
> +properties:
> + compatible:
> + oneOf:
> + - enum:
> + - nvidia,tegra124-xusb-padctl
> +
> + - items:
> + - const: nvidia,tegra132-xusb-padctl
> + - const: nvidia,tegra124-xusb-padctl
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + items:
> + - description: XUSB pad controller interrupt
> +
> + resets:
> + items:
> + - description: pad controller reset
> +
> + reset-names:
> + items:
> + - const: padctl
> +
> + avdd-pll-utmip-supply:
> + description: UTMI PLL power supply. Must supply 1.8 V.
> +
> + avdd-pll-erefe-supply:
> + description: PLLE reference PLL power supply. Must supply 1.05 V.
> +
> + avdd-pex-pll-supply:
> + description: PCIe/USB3 PLL power supply. Must supply 1.05 V.
> +
> + hvdd-pex-pll-e-supply:
> + description: High-voltage PLLE power supply. Must supply 3.3 V.
> +
> + pads:
> + description: A required child node named "pads" contains a list of
> + subnodes, one for each of the pads exposed by the XUSB pad controller.
> + Each pad may need additional resources that can be referenced in its
> + pad node.
> +
> + The "status" property is used to enable or disable the use of a pad.
> + If set to "disabled", the pad will not be used on the given board. In
> + order to use the pad and any of its lanes, this property must be set
> + to "okay" or be absent.
> + type: object
> + additionalProperties: false
> + properties:
> + usb2:
> + type: object
> + additionalProperties: false
> + properties:
> + clocks:
> + items:
> + - description: USB2 tracking clock
> +
> + clock-names:
> + items:
> + - const: trk
> +
> + lanes:
> + type: object
> + additionalProperties: false
> + properties:
> + usb2-0:
Any reason to not make this a pattern? '^usb2-[0-2]$'
Same question in several other cases.
> + type: object
> + additionalProperties: false
> + properties:
> + "#phy-cells":
> + const: 0
> +
> + nvidia,function:
> + description: Function selection for this lane.
> + $ref: /schemas/types.yaml#/definitions/string
> + enum: [ snps, xusb, uart ]
> +
> + usb2-1:
> + type: object
> + additionalProperties: false
> + properties:
> + "#phy-cells":
> + const: 0
> +
> + nvidia,function:
> + description: Function selection for this lane.
> + $ref: /schemas/types.yaml#/definitions/string
> + enum: [ snps, xusb, uart ]
> +
> + usb2-2:
> + type: object
> + additionalProperties: false
> + properties:
> + "#phy-cells":
> + const: 0
> +
> + nvidia,function:
> + description: Function selection for this lane.
> + $ref: /schemas/types.yaml#/definitions/string
> + enum: [ snps, xusb, uart ]
next prev parent reply other threads:[~2023-01-17 19:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 15:08 [PATCH v3] dt-bindings: phy: tegra-xusb: Convert to json-schema Thierry Reding
2023-01-17 18:49 ` Rob Herring [this message]
2023-01-18 17:26 ` Vinod Koul
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=20230117184931.GA3431713-robh@kernel.org \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=kishon@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-tegra@vger.kernel.org \
--cc=thierry.reding@gmail.com \
--cc=vkoul@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).