| Message ID | 1446657109-15568-2-git-send-email-thierry.reding@gmail.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
On 11/04/2015 10:11 AM, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > 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,tegra-xusb-padctl.txt | 359 +++++++++++++++++++++ For Tegra bindings, we usually use the full compatible value as the filename, so I'd expect the chip number in the filename too. I'd expect to see a patch in this series that edits the existing Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt and mentions that the binding is deprecated. > diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt > +Device tree binding for NVIDIA Tegra XUSB pad controller > +======================================================== > + > +The Tegra XUSB pad controller manages a set of pads, each of which controls > +one or more lanes. The term "pad" usually refers to a single pad/pin/ball/signal on the chip. As such, saying "pad" here for something that's more than one pin is a bit confusing, even if that is what our HW documentation calls it. > Each lane can in turn be assigned to one out of a set of > +different outputs. That doesn't sound correct. That phrasing implies that the mux is between the HW-blocks-known-as-pads and the "outputs", whereas the mux is actually between the IO controllers and the HW-blocks-known-as-pads > A pad contains logic common for all its lanes. Each lane > +can additionally be separately configured and powered up. I'd suggest rephrasing that all as: The Tegra XUSB pad controller manages a set of IO lanes (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 HW documentation. Each such "pad" may control either one or multiple lanes, and 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). Perhaps add the following after that? The XUSB pad controller contains a software-configurable mux that sits between the IO controller ports (e.g. PCIe) and the lanes. > +Required properties: > +-------------------- > +- compatible: Must be: > + - "nvidia,tegra124-xusb-padctl": for Tegra124 and Tegra132 For Tegra132, we need both a "tegra124" and a "tegra132 value". I would suggest listing the valid complete property values for each SoC for simplicity and preciseness, as I did in the XUSB controller binding proposal I link to later: - compatible: Valid options are: - Tegra124: "nvidia,tegra124-xusb-padctl". - Tegra132: "nvidia,tegra132-xusb-padctl", \ "nvidia,tegra124-xusb-padctl". This also makes it very easy to add entries for future SoCs without editing the diff touching any existing lines of text. > +- reg: Physical base address and length of the controller's registers. > +- resets: Must contain an entry for each entry in reset-names. > +- reset-names: Must include the following entries: > + - "padctl" Are there no clocks or power domains that affect XUSB padctl? I suppose we can start off without any, and add them later if we need. > +- mboxes: Must contain an entry for each entry in mbox-names. > +- mbox-names: Must include the following entries: > + - "xusb" I thought we'd decided not to use any mbox binding or drivers in XUSB now? See for example my proposed XUSB controller binding at: http://www.spinics.net/lists/linux-tegra/msg23922.html [PATCH V9] dt: add NVIDIA Tegra XUSB controller binding The idea is that the mailbox should be entirely internal to the XUSB controller driver, and if the receipt of a mailbox message requires any change in the XUSB pad controller programming, the XUSB controller driver should simply call the XUSB pad controller driver to perform that operation. > +Pad nodes: > +========== > +For Tegra124 and Tegra132, the following pads exist: utmi, ulpi, hsic, pcie > +and sata. No extra resources are required for operation of these pads. Judging by the diagram in the TRM (e.g. figure 41 in the Tegra124 TRM, figure 36 in the Tegra210 TRM), there is not a single "utmi" pad, but rather a separate pad per USB2 lane. However, the other types of pads are indeed multi-lane. The TRM also refers to "USB2" pads rather than "UTMI" pads. I don't see a ULPI pad in the diagram either. Assuming the diagram in the TRM is consistent with the register layout, I think we should have the following set of pad nodes: utmi-0 utmi-1 utmi-2 hsic pcie sata > +Required properties: > +-------------------- > +For Tegra124 and Tegra132, the list of valid PHY nodes is given below: > +- utmi: utmi-0, utmi-1, utmi-2 > + - functions: "snps", "xusb", "uart" I think that entry needs rework based on my comment above re: the set of utmi PHYs/pads that exist. > +Port nodes: > +=========== > + > +A required child node named "ports" contains a list of all the ports exposed > +by the XUSB pad controller. Per-port configuration is only required for USB. I'm not sure this section clearly spells out there must be a node named "ports" inside the main node, and a node per port within "ports". The structure/text under "Pad nodes" seemed better at that. Perhaps add the text "Each port represents the connection between one port on an IO controller, such as a PCIe root port, and the XUSB pad controller" either here, or mention something like this in the introduction to this binding? Otherwise, someone the distinction between lanes, ports, ... might not be clear to someone not familiar with Tegra. Perhaps an ASCII art diagram might make sense? > +UTMI ports: > +----------- > +Optional properties: > +- vbus-supply: phandle to a regulator supplying the VBUS voltage. This is the only port type that specifies vbus-supply as a valid property. There could well be control over VBUS even for ULPI. Shouldn't we add this property there too? > +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,port: 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 Wouldn't it be better to name the node after the physical port number, just like we name the PHY/lane nodes after the PHY/lane identity? We don't seem to have any such mapping information in the UTMI port nodes; how do we correlate the USB2 and USB3 ports? I wonder if we shouldn't represent USB (physical) ports at the lane-side of the XUSB pad controller rather than the IO controller side. That way, we could pack both USB2- and USB3-related information into a single node. For example, vbus-supply really applies equally to the companion USB2 and USB3 ports, whereas this binding represents those two parts of the overall USB port separately, with the vbus-supply property appearing in only one of the two places. I guess this boils down to what a "port" actually is; the IO controller <-> XUSB pad controller interface, or the XUSB pad controller <-> SoC pins interface. > +For Tegra124 and Tegra132, the XUSB pad controller exposes the following > +ports: > +- 3x UTMI: utmi-0, utmi-1, utmi-2 > +- 1x ULPI: ulpi-0 > +- 2x HSIC: hsic-0, hsic-1 > +- 2x super-speed USB: usb3-0, usb3-1 I suspect that chunk would be better placed directly inside the "Port nodes:" section, since it describes valid values for the nodes that are subsequently described. Do we need port nodes for PCIe or SATA at all? If not, should we s/ports/usb-ports/ in the container node name? I suppose it doesn't matter, but it feels slightly odd to only represent some of the ports. > +Examples: > +========= > + > +Tegra124 and Tegra132: > +---------------------- The example isn't valid for Tegra132 since the compatible values don't include any Tegra132 entry. BTW, I've suggested a lot of phrasing changes. Once we've settled the other questions, just let me know if you want me to propose an updated version of the patch that contains all those phrasing changes so you don't have to do them all yourself. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 04/11/15 17:11, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > 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. > > Signed-off-by: Thierry Reding <treding@nvidia.com> > --- > .../bindings/phy/nvidia,tegra-xusb-padctl.txt | 359 +++++++++++++++++++++ > 1 file changed, 359 insertions(+) > create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt > > diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt > new file mode 100644 > index 000000000000..026e924ae54a > --- /dev/null > +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt > @@ -0,0 +1,359 @@ > +Device tree binding for NVIDIA Tegra XUSB pad controller > +======================================================== > + > +The Tegra XUSB pad controller manages a set of pads, each of which controls > +one or more lanes. Each lane can in turn be assigned to one out of a set of > +different outputs. A pad contains logic common for all its lanes. Each lane > +can additionally 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). > + > +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. > + > +Required properties: > +-------------------- > +- compatible: Must be: > + - "nvidia,tegra124-xusb-padctl": for Tegra124 and Tegra132 > +- reg: Physical base address and length of the controller's registers. > +- resets: Must contain an entry for each entry in reset-names. > +- reset-names: Must include the following entries: > + - "padctl" > +- mboxes: Must contain an entry for each entry in mbox-names. > +- mbox-names: Must include the following entries: > + - "xusb" > + > + > +Pad nodes: > +========== > + > +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". > + > +For Tegra124 and Tegra132, the following pads exist: utmi, ulpi, hsic, pcie > +and sata. No extra resources are required for operation of these pads. > + > + > +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 > +- #phy-cells: Should be 0. Since each lane represents a single PHY, there is > + no need for an additional specifier. > +- nvidia,function: The output function of the PHY. See below for a list of > + valid functions per SoC generation. > + > +For Tegra124 and Tegra132, the list of valid PHY nodes is given below: > +- utmi: utmi-0, utmi-1, utmi-2 > + - functions: "snps", "xusb", "uart" > +- ulpi: ulpi-0 > + - functions: "snps", "xusb" > +- hsic: hsic-0, hsic-1 > + - functions: "snps", "xusb" > +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4 > + - functions: "pcie", "usb3-ss" Per the patch I recently sent out [0], although from the register description the above is correct, the reality is that the usb3-ss function is not available on all pcie lanes. We really need to make this clear somehow. > +- sata: sata-0 > + - functions: "usb3-ss", "sata" > + > +Port nodes: > +=========== > + > +A required child node named "ports" contains a list of all the ports exposed > +by the XUSB pad controller. Per-port configuration is only required for USB. What about pcie? For example, how/where can we map the pcie1-x2 to the pcie lanes? Again per patch [0] there are only a finite number of options for mapping pcie ports to lanes and so it would be good to represent this as well. > +UTMI ports: > +----------- > + > +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 > + > +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. > +- vbus-supply: phandle to a regulator supplying the VBUS voltage. > + > +ULPI ports: > +----------- > + > +Optional properties: > +- status: Defines the operation status of the port. Valid values are: > + - "disabled": the port is disabled > + - "okay": the port is enabled > +- 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. > + > +HSIC ports: > +----------- > + > +Required properties: > +- status: Defines the operation status of the port. Valid values are: > + - "disabled": the port is disabled > + - "okay": the port is enabled > + > +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,port: 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 I am a bit confused by what nvidia,port property is used for. Is this to program XUSB_PADCTL_SS_PORT_MAP_0? If so then I think that this should be an optional property because if you want to use the usb3 ports for usb3, then we should not need to specify this here. Also the XHCI has 3 usb2 ports and 2 usb3 ports and so when you have port numbers 0-2 I am not sure what you are referring too. Cheers Jon [0] https://lkml.org/lkml/2015/10/16/193 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 5, 2015 at 1:55 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >> +UTMI ports: >> +----------- >> + >> +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 >> + >> +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. >> +- vbus-supply: phandle to a regulator supplying the VBUS voltage. >> + >> +ULPI ports: >> +----------- >> + >> +Optional properties: >> +- status: Defines the operation status of the port. Valid values are: >> + - "disabled": the port is disabled >> + - "okay": the port is enabled >> +- 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. >> + >> +HSIC ports: >> +----------- >> + >> +Required properties: >> +- status: Defines the operation status of the port. Valid values are: >> + - "disabled": the port is disabled >> + - "okay": the port is enabled >> + >> +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,port: 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 > > I am a bit confused by what nvidia,port property is used for. Is this to > program XUSB_PADCTL_SS_PORT_MAP_0? If so then I think that this should > be an optional property because if you want to use the usb3 ports for > usb3, then we should not need to specify this here. "nvidia,port" is used to program XUSB_PADCTL_SS_PORT_MAP and is definitely required. It specifies the UTMI port to which the SS port is mapped to. For example, Nyan-Big has 3 UTMI ports (0, 1 (internal), and 2) and 2 SS ports (0 and 1). SS port 0 is mapped to the same physical port as UTMI port 0 and SS port 1 is mapped to the same physical port as UTMI port 2. > Also the XHCI has 3 usb2 ports and 2 usb3 ports and so when you have > port numbers 0-2 I am not sure what you are referring too. The port numbers correspond tot he UTMI ports, so 3 UTMI ports = possible port values of 0 - 2. Maybe "port" isn't the best name here? -Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/11/15 18:13, Andrew Bresticker wrote: > On Thu, Nov 5, 2015 at 1:55 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> +UTMI ports: >>> +----------- >>> + >>> +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 >>> + >>> +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. >>> +- vbus-supply: phandle to a regulator supplying the VBUS voltage. >>> + >>> +ULPI ports: >>> +----------- >>> + >>> +Optional properties: >>> +- status: Defines the operation status of the port. Valid values are: >>> + - "disabled": the port is disabled >>> + - "okay": the port is enabled >>> +- 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. >>> + >>> +HSIC ports: >>> +----------- >>> + >>> +Required properties: >>> +- status: Defines the operation status of the port. Valid values are: >>> + - "disabled": the port is disabled >>> + - "okay": the port is enabled >>> + >>> +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,port: 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 >> >> I am a bit confused by what nvidia,port property is used for. Is this to >> program XUSB_PADCTL_SS_PORT_MAP_0? If so then I think that this should >> be an optional property because if you want to use the usb3 ports for >> usb3, then we should not need to specify this here. > > "nvidia,port" is used to program XUSB_PADCTL_SS_PORT_MAP and is > definitely required. It specifies the UTMI port to which the SS port > is mapped to. For example, Nyan-Big has 3 UTMI ports (0, 1 > (internal), and 2) and 2 SS ports (0 and 1). SS port 0 is mapped to > the same physical port as UTMI port 0 and SS port 1 is mapped to the > same physical port as UTMI port 2. By port, you mean usb3 connector/receptacle right? I had also been thinking about the use-case where you have an embedded usb3 device (on the same pcb) directly connected to the tegra and so I was wondering if setting this register would be still necessary. However, I have checked with the designers and they told me that we do still need to set this even if this case. So it does appear to be required after all. Sorry for the noise. Jon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt new file mode 100644 index 000000000000..026e924ae54a --- /dev/null +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt @@ -0,0 +1,359 @@ +Device tree binding for NVIDIA Tegra XUSB pad controller +======================================================== + +The Tegra XUSB pad controller manages a set of pads, each of which controls +one or more lanes. Each lane can in turn be assigned to one out of a set of +different outputs. A pad contains logic common for all its lanes. Each lane +can additionally 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). + +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. + +Required properties: +-------------------- +- compatible: Must be: + - "nvidia,tegra124-xusb-padctl": for Tegra124 and Tegra132 +- reg: Physical base address and length of the controller's registers. +- resets: Must contain an entry for each entry in reset-names. +- reset-names: Must include the following entries: + - "padctl" +- mboxes: Must contain an entry for each entry in mbox-names. +- mbox-names: Must include the following entries: + - "xusb" + + +Pad nodes: +========== + +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". + +For Tegra124 and Tegra132, the following pads exist: utmi, ulpi, hsic, pcie +and sata. No extra resources are required for operation of these pads. + + +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 +- #phy-cells: Should be 0. Since each lane represents a single PHY, there is + no need for an additional specifier. +- nvidia,function: The output function of the PHY. See below for a list of + valid functions per SoC generation. + +For Tegra124 and Tegra132, the list of valid PHY nodes is given below: +- utmi: utmi-0, utmi-1, utmi-2 + - functions: "snps", "xusb", "uart" +- ulpi: ulpi-0 + - functions: "snps", "xusb" +- hsic: hsic-0, hsic-1 + - functions: "snps", "xusb" +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4 + - functions: "pcie", "usb3-ss" +- sata: sata-0 + - functions: "usb3-ss", "sata" + +Port nodes: +=========== + +A required child node named "ports" contains a list of all the ports exposed +by the XUSB pad controller. Per-port configuration is only required for USB. + +UTMI ports: +----------- + +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 + +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. +- vbus-supply: phandle to a regulator supplying the VBUS voltage. + +ULPI ports: +----------- + +Optional properties: +- status: Defines the operation status of the port. Valid values are: + - "disabled": the port is disabled + - "okay": the port is enabled +- 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. + +HSIC ports: +----------- + +Required properties: +- status: Defines the operation status of the port. Valid values are: + - "disabled": the port is disabled + - "okay": the port is enabled + +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,port: 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 + +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. + +For Tegra124 and Tegra132, the XUSB pad controller exposes the following +ports: +- 3x UTMI: utmi-0, utmi-1, utmi-2 +- 1x ULPI: ulpi-0 +- 2x HSIC: hsic-0, hsic-1 +- 2x super-speed USB: usb3-0, usb3-1 + + +Examples: +========= + +Tegra124 and Tegra132: +---------------------- + +SoC include: + + padctl@0,7009f000 { + compatible = "nvidia,tegra124-xusb-padctl"; + reg = <0x0 0x7009f000 0x0 0x1000>; + resets = <&tegra_car 142>; + reset-names = "padctl"; + mboxes = <&xusb_mbox>; + mbox-names = "xusb"; + + pads { + utmi { + status = "disabled"; + + utmi-0 { + status = "disabled"; + #phy-cells = <0>; + }; + + utmi-1 { + status = "disabled"; + #phy-cells = <0>; + }; + + utmi-2 { + status = "disabled"; + #phy-cells = <0>; + }; + }; + + ulpi { + status = "disabled"; + + ulpi-0 { + status = "disabled"; + #phy-cells = <0>; + }; + }; + + hsic { + status = "disabled"; + + hsic-0 { + status = "disabled"; + #phy-cells = <0>; + }; + + hsic-1 { + status = "disabled"; + #phy-cells = <0>; + }; + }; + + pcie { + status = "disabled"; + + pcie-0 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-1 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-2 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-3 { + status = "disabled"; + #phy-cells = <0>; + }; + + pcie-4 { + status = "disabled"; + #phy-cells = <0>; + }; + }; + + sata { + status = "disabled"; + + sata-0 { + status = "disabled"; + #phy-cells = <0>; + }; + }; + }; + + ports { + utmi-0 { + status = "disabled"; + }; + + utmi-1 { + status = "disabled"; + }; + + utmi-2 { + status = "disabled"; + }; + + ulpi-0 { + status = "disabled"; + }; + + hsic-0 { + status = "disabled"; + }; + + hsic-1 { + status = "disabled"; + }; + + usb3-0 { + status = "disabled"; + }; + + usb3-1 { + status = "disabled"; + }; + }; + }; + +Board file: + + padctl@0,7009f000 { + status = "okay"; + + pads { + utmi { + status = "okay"; + + utmi-0 { + nvidia,function = "xusb"; + status = "okay"; + }; + + utmi-1 { + nvidia,function = "xusb"; + status = "okay"; + }; + + utmi-2 { + nvidia,function = "xusb"; + status = "okay"; + }; + }; + + pcie { + status = "okay"; + + pcie-0 { + nvidia,function = "usb3-ss"; + status = "okay"; + }; + + pcie-2 { + nvidia,function = "pcie"; + status = "okay"; + }; + + pcie-4 { + nvidia,function = "pcie"; + status = "okay"; + }; + }; + + sata { + status = "okay"; + + sata-0 { + nvidia,function = "sata"; + status = "okay"; + }; + }; + }; + + ports { + /* Micro A/B */ + utmi-0 { + status = "okay"; + mode = "otg"; + }; + + /* Mini PCIe */ + utmi-1 { + status = "okay"; + mode = "host"; + }; + + /* USB3 */ + utmi-2 { + status = "okay"; + mode = "host"; + + vbus-supply = <&vdd_usb3_vbus>; + }; + + usb3-0 { + nvidia,port = <2>; + status = "okay"; + }; + }; + };