Commit | Line | Data |
---|---|---|
4c20386c DB |
1 | GPIO Interfaces |
2 | ||
3 | This provides an overview of GPIO access conventions on Linux. | |
4 | ||
5 | ||
6 | What is a GPIO? | |
7 | =============== | |
8 | A "General Purpose Input/Output" (GPIO) is a flexible software-controlled | |
9 | digital signal. They are provided from many kinds of chip, and are familiar | |
10 | to Linux developers working with embedded and custom hardware. Each GPIO | |
11 | represents a bit connected to a particular pin, or "ball" on Ball Grid Array | |
12 | (BGA) packages. Board schematics show which external hardware connects to | |
13 | which GPIOs. Drivers can be written generically, so that board setup code | |
14 | passes such pin configuration data to drivers. | |
15 | ||
16 | System-on-Chip (SOC) processors heavily rely on GPIOs. In some cases, every | |
17 | non-dedicated pin can be configured as a GPIO; and most chips have at least | |
18 | several dozen of them. Programmable logic devices (like FPGAs) can easily | |
19 | provide GPIOs; multifunction chips like power managers, and audio codecs | |
20 | often have a few such pins to help with pin scarcity on SOCs; and there are | |
21 | also "GPIO Expander" chips that connect using the I2C or SPI serial busses. | |
22 | Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS | |
23 | firmware knowing how they're used). | |
24 | ||
25 | The exact capabilities of GPIOs vary between systems. Common options: | |
26 | ||
27 | - Output values are writable (high=1, low=0). Some chips also have | |
28 | options about how that value is driven, so that for example only one | |
29 | value might be driven ... supporting "wire-OR" and similar schemes | |
1668be71 | 30 | for the other value (notably, "open drain" signaling). |
4c20386c DB |
31 | |
32 | - Input values are likewise readable (1, 0). Some chips support readback | |
33 | of pins configured as "output", which is very useful in such "wire-OR" | |
34 | cases (to support bidirectional signaling). GPIO controllers may have | |
35 | input de-glitch logic, sometimes with software controls. | |
36 | ||
37 | - Inputs can often be used as IRQ signals, often edge triggered but | |
38 | sometimes level triggered. Such IRQs may be configurable as system | |
39 | wakeup events, to wake the system from a low power state. | |
40 | ||
41 | - Usually a GPIO will be configurable as either input or output, as needed | |
42 | by different product boards; single direction ones exist too. | |
43 | ||
44 | - Most GPIOs can be accessed while holding spinlocks, but those accessed | |
45 | through a serial bus normally can't. Some systems support both types. | |
46 | ||
47 | On a given board each GPIO is used for one specific purpose like monitoring | |
48 | MMC/SD card insertion/removal, detecting card writeprotect status, driving | |
49 | a LED, configuring a transceiver, bitbanging a serial bus, poking a hardware | |
50 | watchdog, sensing a switch, and so on. | |
51 | ||
52 | ||
53 | GPIO conventions | |
54 | ================ | |
55 | Note that this is called a "convention" because you don't need to do it this | |
56 | way, and it's no crime if you don't. There **are** cases where portability | |
57 | is not the main issue; GPIOs are often used for the kind of board-specific | |
58 | glue logic that may even change between board revisions, and can't ever be | |
59 | used on a board that's wired differently. Only least-common-denominator | |
60 | functionality can be very portable. Other features are platform-specific, | |
61 | and that can be critical for glue logic. | |
62 | ||
63 | Plus, this doesn't define an implementation framework, just an interface. | |
64 | One platform might implement it as simple inline functions accessing chip | |
65 | registers; another might implement it by delegating through abstractions | |
66 | used for several very different kinds of GPIO controller. | |
67 | ||
68 | That said, if the convention is supported on their platform, drivers should | |
32993b79 DB |
69 | use it when possible. Platforms should declare GENERIC_GPIO support in |
70 | Kconfig (boolean true), which multi-platform drivers can depend on when | |
71 | using the include file: | |
4c20386c DB |
72 | |
73 | #include <asm/gpio.h> | |
74 | ||
75 | If you stick to this convention then it'll be easier for other developers to | |
76 | see what your code is doing, and help maintain it. | |
77 | ||
78 | ||
79 | Identifying GPIOs | |
80 | ----------------- | |
81 | GPIOs are identified by unsigned integers in the range 0..MAX_INT. That | |
82 | reserves "negative" numbers for other purposes like marking signals as | |
f5de6111 DB |
83 | "not available on this board", or indicating faults. Code that doesn't |
84 | touch the underlying hardware treats these integers as opaque cookies. | |
4c20386c DB |
85 | |
86 | Platforms define how they use those integers, and usually #define symbols | |
87 | for the GPIO lines so that board-specific setup code directly corresponds | |
88 | to the relevant schematics. In contrast, drivers should only use GPIO | |
89 | numbers passed to them from that setup code, using platform_data to hold | |
90 | board-specific pin configuration data (along with other board specific | |
91 | data they need). That avoids portability problems. | |
92 | ||
93 | So for example one platform uses numbers 32-159 for GPIOs; while another | |
94 | uses numbers 0..63 with one set of GPIO controllers, 64-79 with another | |
95 | type of GPIO controller, and on one particular board 80-95 with an FPGA. | |
96 | The numbers need not be contiguous; either of those platforms could also | |
97 | use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders. | |
98 | ||
99 | Whether a platform supports multiple GPIO controllers is currently a | |
100 | platform-specific implementation issue. | |
101 | ||
102 | ||
103 | Using GPIOs | |
104 | ----------- | |
105 | One of the first things to do with a GPIO, often in board setup code when | |
106 | setting up a platform_device using the GPIO, is mark its direction: | |
107 | ||
108 | /* set as input or output, returning 0 or negative errno */ | |
109 | int gpio_direction_input(unsigned gpio); | |
28735a72 | 110 | int gpio_direction_output(unsigned gpio, int value); |
4c20386c DB |
111 | |
112 | The return value is zero for success, else a negative errno. It should | |
113 | be checked, since the get/set calls don't have error returns and since | |
114 | misconfiguration is possible. (These calls could sleep.) | |
115 | ||
28735a72 DB |
116 | For output GPIOs, the value provided becomes the initial output value. |
117 | This helps avoid signal glitching during system startup. | |
118 | ||
4c20386c DB |
119 | Setting the direction can fail if the GPIO number is invalid, or when |
120 | that particular GPIO can't be used in that mode. It's generally a bad | |
121 | idea to rely on boot firmware to have set the direction correctly, since | |
122 | it probably wasn't validated to do more than boot Linux. (Similarly, | |
123 | that board setup code probably needs to multiplex that pin as a GPIO, | |
124 | and configure pullups/pulldowns appropriately.) | |
125 | ||
126 | ||
127 | Spinlock-Safe GPIO access | |
128 | ------------------------- | |
129 | Most GPIO controllers can be accessed with memory read/write instructions. | |
130 | That doesn't need to sleep, and can safely be done from inside IRQ handlers. | |
131 | ||
132 | Use these calls to access such GPIOs: | |
133 | ||
134 | /* GPIO INPUT: return zero or nonzero */ | |
135 | int gpio_get_value(unsigned gpio); | |
136 | ||
137 | /* GPIO OUTPUT */ | |
138 | void gpio_set_value(unsigned gpio, int value); | |
139 | ||
140 | The values are boolean, zero for low, nonzero for high. When reading the | |
141 | value of an output pin, the value returned should be what's seen on the | |
142 | pin ... that won't always match the specified output value, because of | |
143 | issues including wire-OR and output latencies. | |
144 | ||
145 | The get/set calls have no error returns because "invalid GPIO" should have | |
146 | been reported earlier in gpio_set_direction(). However, note that not all | |
147 | platforms can read the value of output pins; those that can't should always | |
f5de6111 DB |
148 | return zero. Also, using these calls for GPIOs that can't safely be accessed |
149 | without sleeping (see below) is an error. | |
4c20386c | 150 | |
f5de6111 | 151 | Platform-specific implementations are encouraged to optimize the two |
4c20386c DB |
152 | calls to access the GPIO value in cases where the GPIO number (and for |
153 | output, value) are constant. It's normal for them to need only a couple | |
154 | of instructions in such cases (reading or writing a hardware register), | |
155 | and not to need spinlocks. Such optimized calls can make bitbanging | |
156 | applications a lot more efficient (in both space and time) than spending | |
157 | dozens of instructions on subroutine calls. | |
158 | ||
159 | ||
160 | GPIO access that may sleep | |
161 | -------------------------- | |
162 | Some GPIO controllers must be accessed using message based busses like I2C | |
163 | or SPI. Commands to read or write those GPIO values require waiting to | |
164 | get to the head of a queue to transmit a command and get its response. | |
165 | This requires sleeping, which can't be done from inside IRQ handlers. | |
166 | ||
167 | Platforms that support this type of GPIO distinguish them from other GPIOs | |
168 | by returning nonzero from this call: | |
169 | ||
170 | int gpio_cansleep(unsigned gpio); | |
171 | ||
172 | To access such GPIOs, a different set of accessors is defined: | |
173 | ||
174 | /* GPIO INPUT: return zero or nonzero, might sleep */ | |
175 | int gpio_get_value_cansleep(unsigned gpio); | |
176 | ||
177 | /* GPIO OUTPUT, might sleep */ | |
178 | void gpio_set_value_cansleep(unsigned gpio, int value); | |
179 | ||
180 | Other than the fact that these calls might sleep, and will not be ignored | |
181 | for GPIOs that can't be accessed from IRQ handlers, these calls act the | |
182 | same as the spinlock-safe calls. | |
183 | ||
184 | ||
185 | Claiming and Releasing GPIOs (OPTIONAL) | |
186 | --------------------------------------- | |
187 | To help catch system configuration errors, two calls are defined. | |
188 | However, many platforms don't currently support this mechanism. | |
189 | ||
190 | /* request GPIO, returning 0 or negative errno. | |
191 | * non-null labels may be useful for diagnostics. | |
192 | */ | |
193 | int gpio_request(unsigned gpio, const char *label); | |
194 | ||
195 | /* release previously-claimed GPIO */ | |
196 | void gpio_free(unsigned gpio); | |
197 | ||
198 | Passing invalid GPIO numbers to gpio_request() will fail, as will requesting | |
199 | GPIOs that have already been claimed with that call. The return value of | |
200 | gpio_request() must be checked. (These calls could sleep.) | |
201 | ||
202 | These calls serve two basic purposes. One is marking the signals which | |
203 | are actually in use as GPIOs, for better diagnostics; systems may have | |
204 | several hundred potential GPIOs, but often only a dozen are used on any | |
205 | given board. Another is to catch conflicts between drivers, reporting | |
206 | errors when drivers wrongly think they have exclusive use of that signal. | |
207 | ||
208 | These two calls are optional because not not all current Linux platforms | |
209 | offer such functionality in their GPIO support; a valid implementation | |
210 | could return success for all gpio_request() calls. Unlike the other calls, | |
211 | the state they represent doesn't normally match anything from a hardware | |
212 | register; it's just a software bitmap which clearly is not necessary for | |
213 | correct operation of hardware or (bug free) drivers. | |
214 | ||
215 | Note that requesting a GPIO does NOT cause it to be configured in any | |
216 | way; it just marks that GPIO as in use. Separate code must handle any | |
217 | pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown). | |
218 | ||
219 | ||
220 | GPIOs mapped to IRQs | |
221 | -------------------- | |
222 | GPIO numbers are unsigned integers; so are IRQ numbers. These make up | |
223 | two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can | |
224 | map between them using calls like: | |
225 | ||
226 | /* map GPIO numbers to IRQ numbers */ | |
227 | int gpio_to_irq(unsigned gpio); | |
228 | ||
229 | /* map IRQ numbers to GPIO numbers */ | |
230 | int irq_to_gpio(unsigned irq); | |
231 | ||
232 | Those return either the corresponding number in the other namespace, or | |
233 | else a negative errno code if the mapping can't be done. (For example, | |
234 | some GPIOs can't used as IRQs.) It is an unchecked error to use a GPIO | |
235 | number that hasn't been marked as an input using gpio_set_direction(), or | |
236 | to use an IRQ number that didn't originally come from gpio_to_irq(). | |
237 | ||
238 | These two mapping calls are expected to cost on the order of a single | |
239 | addition or subtraction. They're not allowed to sleep. | |
240 | ||
241 | Non-error values returned from gpio_to_irq() can be passed to request_irq() | |
242 | or free_irq(). They will often be stored into IRQ resources for platform | |
243 | devices, by the board-specific initialization code. Note that IRQ trigger | |
244 | options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are | |
245 | system wakeup capabilities. | |
246 | ||
247 | Non-error values returned from irq_to_gpio() would most commonly be used | |
f5de6111 DB |
248 | with gpio_get_value(), for example to initialize or update driver state |
249 | when the IRQ is edge-triggered. | |
4c20386c DB |
250 | |
251 | ||
1668be71 DB |
252 | Emulating Open Drain Signals |
253 | ---------------------------- | |
254 | Sometimes shared signals need to use "open drain" signaling, where only the | |
255 | low signal level is actually driven. (That term applies to CMOS transistors; | |
256 | "open collector" is used for TTL.) A pullup resistor causes the high signal | |
257 | level. This is sometimes called a "wire-AND"; or more practically, from the | |
258 | negative logic (low=true) perspective this is a "wire-OR". | |
259 | ||
260 | One common example of an open drain signal is a shared active-low IRQ line. | |
261 | Also, bidirectional data bus signals sometimes use open drain signals. | |
262 | ||
263 | Some GPIO controllers directly support open drain outputs; many don't. When | |
264 | you need open drain signaling but your hardware doesn't directly support it, | |
265 | there's a common idiom you can use to emulate it with any GPIO pin that can | |
266 | be used as either an input or an output: | |
267 | ||
268 | LOW: gpio_direction_output(gpio, 0) ... this drives the signal | |
269 | and overrides the pullup. | |
270 | ||
271 | HIGH: gpio_direction_input(gpio) ... this turns off the output, | |
272 | so the pullup (or some other device) controls the signal. | |
273 | ||
274 | If you are "driving" the signal high but gpio_get_value(gpio) reports a low | |
275 | value (after the appropriate rise time passes), you know some other component | |
276 | is driving the shared signal low. That's not necessarily an error. As one | |
277 | common example, that's how I2C clocks are stretched: a slave that needs a | |
278 | slower clock delays the rising edge of SCK, and the I2C master adjusts its | |
279 | signaling rate accordingly. | |
280 | ||
4c20386c DB |
281 | |
282 | What do these conventions omit? | |
283 | =============================== | |
284 | One of the biggest things these conventions omit is pin multiplexing, since | |
285 | this is highly chip-specific and nonportable. One platform might not need | |
286 | explicit multiplexing; another might have just two options for use of any | |
287 | given pin; another might have eight options per pin; another might be able | |
288 | to route a given GPIO to any one of several pins. (Yes, those examples all | |
289 | come from systems that run Linux today.) | |
290 | ||
291 | Related to multiplexing is configuration and enabling of the pullups or | |
292 | pulldowns integrated on some platforms. Not all platforms support them, | |
293 | or support them in the same way; and any given board might use external | |
294 | pullups (or pulldowns) so that the on-chip ones should not be used. | |
295 | ||
296 | There are other system-specific mechanisms that are not specified here, | |
297 | like the aforementioned options for input de-glitching and wire-OR output. | |
298 | Hardware may support reading or writing GPIOs in gangs, but that's usually | |
f5de6111 | 299 | configuration dependent: for GPIOs sharing the same bank. (GPIOs are |
4c20386c | 300 | commonly grouped in banks of 16 or 32, with a given SOC having several such |
f5de6111 DB |
301 | banks.) Some systems can trigger IRQs from output GPIOs. Code relying on |
302 | such mechanisms will necessarily be nonportable. | |
4c20386c DB |
303 | |
304 | Dynamic definition of GPIOs is not currently supported; for example, as | |
305 | a side effect of configuring an add-on board with some GPIO expanders. | |
306 | ||
307 | These calls are purely for kernel space, but a userspace API could be built | |
308 | on top of it. |