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