1Device tree binding for NVIDIA Tegra XUSB pad controller 2======================================================== 3 4The Tegra XUSB pad controller manages a set of lanes, each of which can be 5assigned to one out of a set of different pads. Some of these pads have an 6associated PHY that must be powered up before the pad can be used. 7 8This document defines the device-specific binding for the XUSB pad controller. 9 10Refer to pinctrl-bindings.txt in this directory for generic information about 11pin controller device tree bindings and ../phy/phy-bindings.txt for details on 12how to describe and reference PHYs in device trees. 13 14Required properties: 15-------------------- 16- compatible: should be "nvidia,tegra124-xusb-padctl" 17- reg: Physical base address and length of the controller's registers. 18- resets: Must contain an entry for each entry in reset-names. 19 See ../reset/reset.txt for details. 20- reset-names: Must include the following entries: 21 - padctl 22- #phy-cells: Should be 1. The specifier is the index of the PHY to reference. 23 See <dt-bindings/pinctrl/pinctrl-tegra-xusb.h> for the list of valid values. 24 25Lane muxing: 26------------ 27 28Child nodes contain the pinmux configurations following the conventions from 29the pinctrl-bindings.txt document. Typically a single, static configuration is 30given and applied at boot time. 31 32Each subnode describes groups of lanes along with parameters and pads that 33they should be assigned to. The name of these subnodes is not important. All 34subnodes should be parsed solely based on their content. 35 36Each subnode only applies the parameters that are explicitly listed. In other 37words, if a subnode that lists a function but no pin configuration parameters 38implies no information about any pin configuration parameters. Similarly, a 39subnode that describes only an IDDQ parameter implies no information about 40what function the pins are assigned to. For this reason even seemingly boolean 41values are actually tristates in this binding: unspecified, off or on. 42Unspecified is represented as an absent property, and off/on are represented 43as integer values 0 and 1. 44 45Required properties: 46- nvidia,lanes: An array of strings. Each string is the name of a lane. 47 48Optional properties: 49- nvidia,function: A string that is the name of the function (pad) that the 50 pin or group should be assigned to. Valid values for function names are 51 listed below. 52- nvidia,iddq: Enables IDDQ mode of the lane. (0: no, 1: yes) 53 54Note that not all of these properties are valid for all lanes. Lanes can be 55divided into three groups: 56 57 - otg-0, otg-1, otg-2: 58 59 Valid functions for this group are: "snps", "xusb", "uart", "rsvd". 60 61 The nvidia,iddq property does not apply to this group. 62 63 - ulpi-0, hsic-0, hsic-1: 64 65 Valid functions for this group are: "snps", "xusb". 66 67 The nvidia,iddq property does not apply to this group. 68 69 - pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, sata-0: 70 71 Valid functions for this group are: "pcie", "usb3", "sata", "rsvd". 72 73 74Example: 75======== 76 77SoC file extract: 78----------------- 79 80 padctl@0,7009f000 { 81 compatible = "nvidia,tegra124-xusb-padctl"; 82 reg = <0x0 0x7009f000 0x0 0x1000>; 83 resets = <&tegra_car 142>; 84 reset-names = "padctl"; 85 86 #phy-cells = <1>; 87 }; 88 89Board file extract: 90------------------- 91 92 pcie-controller@0,01003000 { 93 ... 94 95 phys = <&padctl 0>; 96 phy-names = "pcie"; 97 98 ... 99 }; 100 101 ... 102 103 padctl: padctl@0,7009f000 { 104 pinctrl-0 = <&padctl_default>; 105 pinctrl-names = "default"; 106 107 padctl_default: pinmux { 108 usb3 { 109 nvidia,lanes = "pcie-0", "pcie-1"; 110 nvidia,function = "usb3"; 111 nvidia,iddq = <0>; 112 }; 113 114 pcie { 115 nvidia,lanes = "pcie-2", "pcie-3", 116 "pcie-4"; 117 nvidia,function = "pcie"; 118 nvidia,iddq = <0>; 119 }; 120 121 sata { 122 nvidia,lanes = "sata-0"; 123 nvidia,function = "sata"; 124 nvidia,iddq = <0>; 125 }; 126 }; 127 }; 128