Commit | Line | Data |
---|---|---|
ec6b9255 SW |
1 | NVIDIA Tegra186 GPIO controllers |
2 | ||
3 | Tegra186 contains two GPIO controllers; a main controller and an "AON" | |
4 | controller. This binding document applies to both controllers. The register | |
5 | layouts for the controllers share many similarities, but also some significant | |
6 | differences. Hence, this document describes closely related but different | |
7 | bindings and compatible values. | |
8 | ||
9 | The Tegra186 GPIO controller allows software to set the IO direction of, and | |
10 | read/write the value of, numerous GPIO signals. Routing of GPIO signals to | |
11 | package balls is under the control of a separate pin controller HW block. Two | |
12 | major sets of registers exist: | |
13 | ||
14 | a) Security registers, which allow configuration of allowed access to the GPIO | |
15 | register set. These registers exist in a single contiguous block of physical | |
16 | address space. The size of this block, and the security features available, | |
17 | varies between the different GPIO controllers. | |
18 | ||
19 | Access to this set of registers is not necessary in all circumstances. Code | |
20 | that wishes to configure access to the GPIO registers needs access to these | |
21 | registers to do so. Code which simply wishes to read or write GPIO data does not | |
22 | need access to these registers. | |
23 | ||
24 | b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO | |
25 | controllers, these registers are exposed via multiple "physical aliases" in | |
26 | address space, each of which access the same underlying state. See the hardware | |
27 | documentation for rationale. Any particular GPIO client is expected to access | |
28 | just one of these physical aliases. | |
29 | ||
30 | Tegra HW documentation describes a unified naming convention for all GPIOs | |
31 | implemented by the SoC. Each GPIO is assigned to a port, and a port may control | |
32 | a number of GPIOs. Thus, each GPIO is named according to an alphabetical port | |
33 | name and an integer GPIO name within the port. For example, GPIO_PA0, GPIO_PN6, | |
34 | or GPIO_PCC3. | |
35 | ||
36 | The number of ports implemented by each GPIO controller varies. The number of | |
37 | implemented GPIOs within each port varies. GPIO registers within a controller | |
38 | are grouped and laid out according to the port they affect. | |
39 | ||
40 | The mapping from port name to the GPIO controller that implements that port, and | |
41 | the mapping from port name to register offset within a controller, are both | |
42 | extremely non-linear. The header file <dt-bindings/gpio/tegra186-gpio.h> | |
43 | describes the port-level mapping. In that file, the naming convention for ports | |
44 | matches the HW documentation. The values chosen for the names are alphabetically | |
45 | sorted within a particular controller. Drivers need to map between the DT GPIO | |
46 | IDs and HW register offsets using a lookup table. | |
47 | ||
48 | Each GPIO controller can generate a number of interrupt signals. Each signal | |
49 | represents the aggregate status for all GPIOs within a set of ports. Thus, the | |
50 | number of interrupt signals generated by a controller varies as a rough function | |
51 | of the number of ports it implements. Note that the HW documentation refers to | |
52 | both the overall controller HW module and the sets-of-ports as "controllers". | |
53 | ||
54 | Each GPIO controller in fact generates multiple interrupts signals for each set | |
55 | of ports. Each GPIO may be configured to feed into a specific one of the | |
56 | interrupt signals generated by a set-of-ports. The intent is for each generated | |
57 | signal to be routed to a different CPU, thus allowing different CPUs to each | |
58 | handle subsets of the interrupts within a port. The status of each of these | |
59 | per-port-set signals is reported via a separate register. Thus, a driver needs | |
60 | to know which status register to observe. This binding currently defines no | |
61 | configuration mechanism for this. By default, drivers should use register | |
62 | GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could | |
63 | define a property to configure this. | |
64 | ||
65 | Required properties: | |
66 | - compatible | |
67 | Array of strings. | |
68 | One of: | |
69 | - "nvidia,tegra186-gpio". | |
70 | - "nvidia,tegra186-gpio-aon". | |
71 | - reg-names | |
72 | Array of strings. | |
73 | Contains a list of names for the register spaces described by the reg | |
74 | property. May contain the following entries, in any order: | |
75 | - "gpio": Mandatory. GPIO control registers. This may cover either: | |
76 | a) The single physical alias that this OS should use. | |
77 | b) All physical aliases that exist in the controller. This is | |
78 | appropriate when the OS is responsible for managing assignment of | |
79 | the physical aliases. | |
80 | - "security": Optional. Security configuration registers. | |
81 | Users of this binding MUST look up entries in the reg property by name, | |
82 | using this reg-names property to do so. | |
83 | - reg | |
84 | Array of (physical base address, length) tuples. | |
85 | Must contain one entry per entry in the reg-names property, in a matching | |
86 | order. | |
87 | - interrupts | |
88 | Array of interrupt specifiers. | |
89 | The interrupt outputs from the HW block, one per set of ports, in the | |
90 | order the HW manual describes them. The number of entries required varies | |
91 | depending on compatible value: | |
92 | - "nvidia,tegra186-gpio": 6 entries. | |
93 | - "nvidia,tegra186-gpio-aon": 1 entry. | |
94 | - gpio-controller | |
95 | Boolean. | |
96 | Marks the device node as a GPIO controller/provider. | |
97 | - #gpio-cells | |
98 | Single-cell integer. | |
99 | Must be <2>. | |
100 | Indicates how many cells are used in a consumer's GPIO specifier. | |
101 | In the specifier: | |
102 | - The first cell is the pin number. | |
103 | See <dt-bindings/gpio/tegra186-gpio.h>. | |
104 | - The second cell contains flags: | |
105 | - Bit 0 specifies polarity | |
106 | - 0: Active-high (normal). | |
107 | - 1: Active-low (inverted). | |
108 | - interrupt-controller | |
109 | Boolean. | |
110 | Marks the device node as an interrupt controller/provider. | |
111 | - #interrupt-cells | |
112 | Single-cell integer. | |
113 | Must be <2>. | |
114 | Indicates how many cells are used in a consumer's interrupt specifier. | |
115 | In the specifier: | |
116 | - The first cell is the GPIO number. | |
117 | See <dt-bindings/gpio/tegra186-gpio.h>. | |
118 | - The second cell is contains flags: | |
119 | - Bits [3:0] indicate trigger type and level: | |
120 | - 1: Low-to-high edge triggered. | |
121 | - 2: High-to-low edge triggered. | |
122 | - 4: Active high level-sensitive. | |
123 | - 8: Active low level-sensitive. | |
124 | Valid combinations are 1, 2, 3, 4, 8. | |
125 | ||
126 | Example: | |
127 | ||
128 | #include <dt-bindings/interrupt-controller/irq.h> | |
129 | ||
130 | gpio@2200000 { | |
131 | compatible = "nvidia,tegra186-gpio"; | |
132 | reg-names = "security", "gpio"; | |
133 | reg = | |
134 | <0x0 0x2200000 0x0 0x10000>, | |
135 | <0x0 0x2210000 0x0 0x10000>; | |
136 | interrupts = | |
137 | <0 47 IRQ_TYPE_LEVEL_HIGH>, | |
138 | <0 50 IRQ_TYPE_LEVEL_HIGH>, | |
139 | <0 53 IRQ_TYPE_LEVEL_HIGH>, | |
140 | <0 56 IRQ_TYPE_LEVEL_HIGH>, | |
141 | <0 59 IRQ_TYPE_LEVEL_HIGH>, | |
142 | <0 180 IRQ_TYPE_LEVEL_HIGH>; | |
143 | gpio-controller; | |
144 | #gpio-cells = <2>; | |
145 | interrupt-controller; | |
146 | #interrupt-cells = <2>; | |
147 | }; | |
148 | ||
149 | gpio@c2f0000 { | |
150 | compatible = "nvidia,tegra186-gpio-aon"; | |
151 | reg-names = "security", "gpio"; | |
152 | reg = | |
153 | <0x0 0xc2f0000 0x0 0x1000>, | |
154 | <0x0 0xc2f1000 0x0 0x1000>; | |
155 | interrupts = | |
156 | <0 60 IRQ_TYPE_LEVEL_HIGH>; | |
157 | gpio-controller; | |
158 | #gpio-cells = <2>; | |
159 | interrupt-controller; | |
160 | #interrupt-cells = <2>; | |
161 | }; |