1 Device tree binding for NVIDIA Tegra XUSB pad controller
2 ========================================================
4 The Tegra XUSB pad controller manages a set of lanes, each of which can be
5 assigned to one out of a set of different pads. Some of these pads have an
6 associated PHY that must be powered up before the pad can be used.
8 This document defines the device-specific binding for the XUSB pad controller.
10 Refer to pinctrl-bindings.txt in this directory for generic information about
11 pin controller device tree bindings and ../phy/phy-bindings.txt for details on
12 how to describe and reference PHYs in device trees.
16 - compatible: For Tegra124, must contain "nvidia,tegra124-xusb-padctl".
17 Otherwise, must contain '"nvidia,<chip>-xusb-padctl",
18 "nvidia-tegra124-xusb-padctl"', where <chip> is tegra132 or tegra210.
19 - reg: Physical base address and length of the controller's registers.
20 - resets: Must contain an entry for each entry in reset-names.
21 See ../reset/reset.txt for details.
22 - reset-names: Must include the following entries:
24 - #phy-cells: Should be 1. The specifier is the index of the PHY to reference.
25 See <dt-bindings/pinctrl/pinctrl-tegra-xusb.h> for the list of valid values.
30 Child nodes contain the pinmux configurations following the conventions from
31 the pinctrl-bindings.txt document. Typically a single, static configuration is
32 given and applied at boot time.
34 Each subnode describes groups of lanes along with parameters and pads that
35 they should be assigned to. The name of these subnodes is not important. All
36 subnodes should be parsed solely based on their content.
38 Each subnode only applies the parameters that are explicitly listed. In other
39 words, if a subnode that lists a function but no pin configuration parameters
40 implies no information about any pin configuration parameters. Similarly, a
41 subnode that describes only an IDDQ parameter implies no information about
42 what function the pins are assigned to. For this reason even seemingly boolean
43 values are actually tristates in this binding: unspecified, off or on.
44 Unspecified is represented as an absent property, and off/on are represented
45 as integer values 0 and 1.
48 - nvidia,lanes: An array of strings. Each string is the name of a lane.
51 - nvidia,function: A string that is the name of the function (pad) that the
52 pin or group should be assigned to. Valid values for function names are
54 - nvidia,iddq: Enables IDDQ mode of the lane. (0: no, 1: yes)
56 Note that not all of these properties are valid for all lanes. Lanes can be
57 divided into three groups:
59 - otg-0, otg-1, otg-2:
61 Valid functions for this group are: "snps", "xusb", "uart", "rsvd".
63 The nvidia,iddq property does not apply to this group.
65 - ulpi-0, hsic-0, hsic-1:
67 Valid functions for this group are: "snps", "xusb".
69 The nvidia,iddq property does not apply to this group.
71 - pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, sata-0:
73 Valid functions for this group are: "pcie", "usb3", "sata", "rsvd".
83 compatible = "nvidia,tegra124-xusb-padctl";
84 reg = <0x0 0x7009f000 0x0 0x1000>;
85 resets = <&tegra_car 142>;
86 reset-names = "padctl";
94 pcie-controller@0,01003000 {
105 padctl: padctl@0,7009f000 {
106 pinctrl-0 = <&padctl_default>;
107 pinctrl-names = "default";
109 padctl_default: pinmux {
111 nvidia,lanes = "pcie-0", "pcie-1";
112 nvidia,function = "usb3";
117 nvidia,lanes = "pcie-2", "pcie-3",
119 nvidia,function = "pcie";
124 nvidia,lanes = "sata-0";
125 nvidia,function = "sata";