Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

From: Stephen Warren
Date: Wed Mar 16 2016 - 13:39:36 EST


On 03/04/2016 09:19 AM, Thierry Reding wrote:
From: Thierry Reding <treding@xxxxxxxxxx>

The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
set of lanes that are used for PCIe, SATA and USB.

.../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 376 +++++++++++++++++++++
.../pinctrl/nvidia,tegra124-xusb-padctl.txt | 5 +

It seems odd to add part of the deprecation notice in this patch and one more line in the second/next patch. Did an update get squashed into the wrong commit? I'd suggest moving the edit to existing file nvidia,tegra124-xusb-padctl.txt entirely into patch 2. Perhaps this could happen while/when the patch is applied to avoid having to post another version.

diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt

...
+Pads will be represented as children of the top-level XUSB pad controller
> +device tree node.

Nit: grand-children, since they're house inside pads{} first. I might suggest:

A "pads" node exists to represent all pads contained within the XUSB controller. Each pad is represented as a subnode of the pads 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.

"Each lane exposed by the pad will be represented as a subnode of the pad node ..."?

I'd suggest adding a similar paragraph describing the ports node, and that ports are child nodes of that. Otherwise, since the documentation of the nodes isn't nested in any way, it's not clear from the text exactly what nodes are children of what other nodes.

+The Tegra hardware documentation refers to the connection between the XUSB
+pad controller and the XUSB controller as "ports".

I think, being pedantic, that "port" in the TRM refers to the set of signals at the edge/interface-to the IO controller, not the connection between the IO controller and the XUSB controller. Still, the existing wording in this patch is fine; no need to change it.

Still, the examples do clear this up, so perhaps it's not worth another version of the series to fix this. Or if you do think it's worth fixing, I'd be perfectly happy to see that done in follow-on patches. If you want I can write that follow-on patch once this series is applied.

...
+PHY nodes:
+==========
+
+Each pad node has one or more children, each representing one of the lanes
+controlled by the pad.
+
+Required properties:
+--------------------
+- status: Defines the operation status of the PHY. Valid values are:
+ - "disabled": the PHY is disabled
+ - "okay": the PHY is enabled

Presumably the standard semantics of a missing status property implicitly meaning "okay" are also intended? A similar comment applies to other places where status is documented. "status" is typically not a required property.

+Port nodes:
+===========

+USB2 ports:
+-----------

Should that say "UTMI ports"? ULPI and HSIC below are (or can be) USB2 ports too.

+Required properties:
+- status: Defines the operation status of the port. Valid values are:
+ - "disabled": the port is disabled
+ - "okay": the port is enabled
+- mode: A string that determines the mode in which to run the port. Valid
+ values are:
+ - "host": for USB host mode
+ - "device": for USB device mode
+ - "otg": for USB OTG mode

How do these properties tie the DT-based port definition to a particular PHY/lane/... in HW? I don't see a property that contains any kind of HW ID here.

...
+Optional properties:
+- nvidia,internal: A boolean property whose presence determines that a port
+ is internal. In the absence of this property the port is considered to be
+ external.

It's not clear what "internal" and "external" mean. Presumably it's on-PCB vs. physical-connector-exposed-to-the-user. It may be worth explicitly mentioning that.

Is there no vbus-supply for USB2/UTMI ports? I'm also not sure why vbus-supply is optional for ULPI and HSIC. Even if there is no SW /control/ over VBUS, there still must be some source of power; IIRC Mark Brown typically desires that to be explicitly modelled with an always-on regulator if there's no SW control.

+Super-speed USB ports:
+----------------------
+
+Required properties:
+- status: Defines the operation status of the port. Valid values are:
+ - "disabled": the port is disabled
+ - "okay": the port is enabled
+- nvidia,usb2-companion: A single cell that specifies the physical port number
+ to map this super-speed USB port to. The range of valid port numbers varies
+ with the SoC generation:
+ - 0-2: for Tegra124 and Tegra132

How can this be used to look up the corresponding USB2 node in DT? I would have expected a phandle here, with the physical (HW) port ID being represented in the referenced node. Otherwise, I don't see how to tie together the USB2 and USB3 DT nodes.

+For Tegra124 and Tegra132, the XUSB pad controller exposes the following
+ports:
+- 3x USB2: usb2-0, usb2-1, usb2-2
+- 1x ULPI: ulpi-0
+- 2x HSIC: hsic-0, hsic-1
+- 2x super-speed USB: usb3-0, usb3-1

Oh, is the physical port ID implicit in the DT node name? It may be worth mentioning that when describing the properties for each type of node.

I'll assume that's how the USB2<->USB3 mapping works. All of my comments are mainly re: the description/documentation of the binding itself. That can all be enhanced later. The underlying binding itself, and the example, look reasonable. As such, this patch,

Acked-by: Stephen Warren <swarren@xxxxxxxxxx>