Commit | Line | Data |
---|---|---|
7ee2c130 JN |
1 | ====================== |
2 | Legacy GPIO Interfaces | |
3 | ====================== | |
4c20386c DB |
4 | |
5 | This provides an overview of GPIO access conventions on Linux. | |
6 | ||
7560fa60 DB |
7 | These calls use the gpio_* naming prefix. No other calls should use that |
8 | prefix, or the related __gpio_* prefix. | |
9 | ||
4c20386c DB |
10 | |
11 | What is a GPIO? | |
12 | =============== | |
13 | A "General Purpose Input/Output" (GPIO) is a flexible software-controlled | |
14 | digital signal. They are provided from many kinds of chip, and are familiar | |
15 | to Linux developers working with embedded and custom hardware. Each GPIO | |
16 | represents a bit connected to a particular pin, or "ball" on Ball Grid Array | |
17 | (BGA) packages. Board schematics show which external hardware connects to | |
18 | which GPIOs. Drivers can be written generically, so that board setup code | |
19 | passes such pin configuration data to drivers. | |
20 | ||
21 | System-on-Chip (SOC) processors heavily rely on GPIOs. In some cases, every | |
22 | non-dedicated pin can be configured as a GPIO; and most chips have at least | |
23 | several dozen of them. Programmable logic devices (like FPGAs) can easily | |
24 | provide GPIOs; multifunction chips like power managers, and audio codecs | |
25 | often have a few such pins to help with pin scarcity on SOCs; and there are | |
26 | also "GPIO Expander" chips that connect using the I2C or SPI serial busses. | |
27 | Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS | |
28 | firmware knowing how they're used). | |
29 | ||
30 | The exact capabilities of GPIOs vary between systems. Common options: | |
31 | ||
32 | - Output values are writable (high=1, low=0). Some chips also have | |
33 | options about how that value is driven, so that for example only one | |
34 | value might be driven ... supporting "wire-OR" and similar schemes | |
1668be71 | 35 | for the other value (notably, "open drain" signaling). |
4c20386c DB |
36 | |
37 | - Input values are likewise readable (1, 0). Some chips support readback | |
38 | of pins configured as "output", which is very useful in such "wire-OR" | |
39 | cases (to support bidirectional signaling). GPIO controllers may have | |
7c2db759 | 40 | input de-glitch/debounce logic, sometimes with software controls. |
4c20386c DB |
41 | |
42 | - Inputs can often be used as IRQ signals, often edge triggered but | |
43 | sometimes level triggered. Such IRQs may be configurable as system | |
44 | wakeup events, to wake the system from a low power state. | |
45 | ||
46 | - Usually a GPIO will be configurable as either input or output, as needed | |
47 | by different product boards; single direction ones exist too. | |
48 | ||
49 | - Most GPIOs can be accessed while holding spinlocks, but those accessed | |
50 | through a serial bus normally can't. Some systems support both types. | |
51 | ||
52 | On a given board each GPIO is used for one specific purpose like monitoring | |
53 | MMC/SD card insertion/removal, detecting card writeprotect status, driving | |
54 | a LED, configuring a transceiver, bitbanging a serial bus, poking a hardware | |
55 | watchdog, sensing a switch, and so on. | |
56 | ||
57 | ||
58 | GPIO conventions | |
59 | ================ | |
60 | Note that this is called a "convention" because you don't need to do it this | |
61 | way, and it's no crime if you don't. There **are** cases where portability | |
62 | is not the main issue; GPIOs are often used for the kind of board-specific | |
63 | glue logic that may even change between board revisions, and can't ever be | |
64 | used on a board that's wired differently. Only least-common-denominator | |
65 | functionality can be very portable. Other features are platform-specific, | |
66 | and that can be critical for glue logic. | |
67 | ||
7c2db759 | 68 | Plus, this doesn't require any implementation framework, just an interface. |
4c20386c DB |
69 | One platform might implement it as simple inline functions accessing chip |
70 | registers; another might implement it by delegating through abstractions | |
7c2db759 DB |
71 | used for several very different kinds of GPIO controller. (There is some |
72 | optional code supporting such an implementation strategy, described later | |
73 | in this document, but drivers acting as clients to the GPIO interface must | |
74 | not care how it's implemented.) | |
4c20386c DB |
75 | |
76 | That said, if the convention is supported on their platform, drivers should | |
65053e1a LW |
77 | use it when possible. Platforms must select GPIOLIB if GPIO functionality |
78 | is strictly required. Drivers that can't work without | |
7fd2bf3d AC |
79 | standard GPIO calls should have Kconfig entries which depend on GPIOLIB. The |
80 | GPIO calls are available, either as "real code" or as optimized-away stubs, | |
81 | when drivers use the include file: | |
4c20386c | 82 | |
7560fa60 | 83 | #include <linux/gpio.h> |
4c20386c DB |
84 | |
85 | If you stick to this convention then it'll be easier for other developers to | |
86 | see what your code is doing, and help maintain it. | |
87 | ||
a0a99835 DB |
88 | Note that these operations include I/O barriers on platforms which need to |
89 | use them; drivers don't need to add them explicitly. | |
90 | ||
4c20386c DB |
91 | |
92 | Identifying GPIOs | |
93 | ----------------- | |
94 | GPIOs are identified by unsigned integers in the range 0..MAX_INT. That | |
95 | reserves "negative" numbers for other purposes like marking signals as | |
f5de6111 DB |
96 | "not available on this board", or indicating faults. Code that doesn't |
97 | touch the underlying hardware treats these integers as opaque cookies. | |
4c20386c DB |
98 | |
99 | Platforms define how they use those integers, and usually #define symbols | |
100 | for the GPIO lines so that board-specific setup code directly corresponds | |
101 | to the relevant schematics. In contrast, drivers should only use GPIO | |
102 | numbers passed to them from that setup code, using platform_data to hold | |
103 | board-specific pin configuration data (along with other board specific | |
104 | data they need). That avoids portability problems. | |
105 | ||
106 | So for example one platform uses numbers 32-159 for GPIOs; while another | |
107 | uses numbers 0..63 with one set of GPIO controllers, 64-79 with another | |
108 | type of GPIO controller, and on one particular board 80-95 with an FPGA. | |
109 | The numbers need not be contiguous; either of those platforms could also | |
110 | use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders. | |
111 | ||
e6de1808 GL |
112 | If you want to initialize a structure with an invalid GPIO number, use |
113 | some negative number (perhaps "-EINVAL"); that will never be valid. To | |
c956126c DB |
114 | test if such number from such a structure could reference a GPIO, you |
115 | may use this predicate: | |
e6de1808 GL |
116 | |
117 | int gpio_is_valid(int number); | |
118 | ||
119 | A number that's not valid will be rejected by calls which may request | |
120 | or free GPIOs (see below). Other numbers may also be rejected; for | |
c956126c | 121 | example, a number might be valid but temporarily unused on a given board. |
4c20386c | 122 | |
c956126c DB |
123 | Whether a platform supports multiple GPIO controllers is a platform-specific |
124 | implementation issue, as are whether that support can leave "holes" in the space | |
125 | of GPIO numbers, and whether new controllers can be added at runtime. Such issues | |
126 | can affect things including whether adjacent GPIO numbers are both valid. | |
4c20386c DB |
127 | |
128 | Using GPIOs | |
129 | ----------- | |
8a0cecff DB |
130 | The first thing a system should do with a GPIO is allocate it, using |
131 | the gpio_request() call; see later. | |
132 | ||
133 | One of the next things to do with a GPIO, often in board setup code when | |
7ee2c130 | 134 | setting up a platform_device using the GPIO, is mark its direction:: |
4c20386c DB |
135 | |
136 | /* set as input or output, returning 0 or negative errno */ | |
137 | int gpio_direction_input(unsigned gpio); | |
28735a72 | 138 | int gpio_direction_output(unsigned gpio, int value); |
4c20386c | 139 | |
d8a3515e | 140 | The return value is zero for success, else a negative errno. It should |
4c20386c | 141 | be checked, since the get/set calls don't have error returns and since |
83c6590c DB |
142 | misconfiguration is possible. You should normally issue these calls from |
143 | a task context. However, for spinlock-safe GPIOs it's OK to use them | |
144 | before tasking is enabled, as part of early board setup. | |
4c20386c | 145 | |
28735a72 DB |
146 | For output GPIOs, the value provided becomes the initial output value. |
147 | This helps avoid signal glitching during system startup. | |
148 | ||
7c2db759 DB |
149 | For compatibility with legacy interfaces to GPIOs, setting the direction |
150 | of a GPIO implicitly requests that GPIO (see below) if it has not been | |
8a0cecff DB |
151 | requested already. That compatibility is being removed from the optional |
152 | gpiolib framework. | |
7c2db759 | 153 | |
4c20386c DB |
154 | Setting the direction can fail if the GPIO number is invalid, or when |
155 | that particular GPIO can't be used in that mode. It's generally a bad | |
156 | idea to rely on boot firmware to have set the direction correctly, since | |
157 | it probably wasn't validated to do more than boot Linux. (Similarly, | |
158 | that board setup code probably needs to multiplex that pin as a GPIO, | |
159 | and configure pullups/pulldowns appropriately.) | |
160 | ||
161 | ||
162 | Spinlock-Safe GPIO access | |
163 | ------------------------- | |
164 | Most GPIO controllers can be accessed with memory read/write instructions. | |
9c4ba946 DB |
165 | Those don't need to sleep, and can safely be done from inside hard |
166 | (nonthreaded) IRQ handlers and similar contexts. | |
4c20386c | 167 | |
7d0b8064 | 168 | Use the following calls to access such GPIOs:: |
4c20386c DB |
169 | |
170 | /* GPIO INPUT: return zero or nonzero */ | |
171 | int gpio_get_value(unsigned gpio); | |
172 | ||
173 | /* GPIO OUTPUT */ | |
174 | void gpio_set_value(unsigned gpio, int value); | |
175 | ||
176 | The values are boolean, zero for low, nonzero for high. When reading the | |
177 | value of an output pin, the value returned should be what's seen on the | |
178 | pin ... that won't always match the specified output value, because of | |
7c2db759 | 179 | issues including open-drain signaling and output latencies. |
4c20386c DB |
180 | |
181 | The get/set calls have no error returns because "invalid GPIO" should have | |
be1ff386 | 182 | been reported earlier from gpio_direction_*(). However, note that not all |
4c20386c | 183 | platforms can read the value of output pins; those that can't should always |
f5de6111 DB |
184 | return zero. Also, using these calls for GPIOs that can't safely be accessed |
185 | without sleeping (see below) is an error. | |
4c20386c | 186 | |
f5de6111 | 187 | Platform-specific implementations are encouraged to optimize the two |
4c20386c DB |
188 | calls to access the GPIO value in cases where the GPIO number (and for |
189 | output, value) are constant. It's normal for them to need only a couple | |
190 | of instructions in such cases (reading or writing a hardware register), | |
191 | and not to need spinlocks. Such optimized calls can make bitbanging | |
192 | applications a lot more efficient (in both space and time) than spending | |
193 | dozens of instructions on subroutine calls. | |
194 | ||
195 | ||
196 | GPIO access that may sleep | |
197 | -------------------------- | |
198 | Some GPIO controllers must be accessed using message based busses like I2C | |
199 | or SPI. Commands to read or write those GPIO values require waiting to | |
200 | get to the head of a queue to transmit a command and get its response. | |
201 | This requires sleeping, which can't be done from inside IRQ handlers. | |
7ee2c130 | 202 | To access such GPIOs, a different set of accessors is defined:: |
4c20386c DB |
203 | |
204 | /* GPIO INPUT: return zero or nonzero, might sleep */ | |
205 | int gpio_get_value_cansleep(unsigned gpio); | |
206 | ||
207 | /* GPIO OUTPUT, might sleep */ | |
208 | void gpio_set_value_cansleep(unsigned gpio, int value); | |
209 | ||
9c4ba946 DB |
210 | Accessing such GPIOs requires a context which may sleep, for example |
211 | a threaded IRQ handler, and those accessors must be used instead of | |
212 | spinlock-safe accessors without the cansleep() name suffix. | |
213 | ||
214 | Other than the fact that these accessors might sleep, and will work | |
215 | on GPIOs that can't be accessed from hardIRQ handlers, these calls act | |
216 | the same as the spinlock-safe calls. | |
217 | ||
7ee2c130 | 218 | **IN ADDITION** calls to setup and configure such GPIOs must be made |
9c4ba946 | 219 | from contexts which may sleep, since they may need to access the GPIO |
7ee2c130 JN |
220 | controller chip too (These setup calls are usually made from board |
221 | setup or driver probe/teardown code, so this is an easy constraint.):: | |
9c4ba946 | 222 | |
7ee2c130 JN |
223 | gpio_direction_input() |
224 | gpio_direction_output() | |
225 | gpio_request() | |
9c4ba946 | 226 | |
7ee2c130 | 227 | ## gpio_request_one() |
9c4ba946 | 228 | |
7ee2c130 | 229 | gpio_free() |
4c20386c DB |
230 | |
231 | ||
8a0cecff DB |
232 | Claiming and Releasing GPIOs |
233 | ---------------------------- | |
7ee2c130 | 234 | To help catch system configuration errors, two calls are defined:: |
4c20386c DB |
235 | |
236 | /* request GPIO, returning 0 or negative errno. | |
237 | * non-null labels may be useful for diagnostics. | |
238 | */ | |
239 | int gpio_request(unsigned gpio, const char *label); | |
240 | ||
241 | /* release previously-claimed GPIO */ | |
242 | void gpio_free(unsigned gpio); | |
243 | ||
244 | Passing invalid GPIO numbers to gpio_request() will fail, as will requesting | |
245 | GPIOs that have already been claimed with that call. The return value of | |
83c6590c DB |
246 | gpio_request() must be checked. You should normally issue these calls from |
247 | a task context. However, for spinlock-safe GPIOs it's OK to request GPIOs | |
248 | before tasking is enabled, as part of early board setup. | |
4c20386c DB |
249 | |
250 | These calls serve two basic purposes. One is marking the signals which | |
251 | are actually in use as GPIOs, for better diagnostics; systems may have | |
252 | several hundred potential GPIOs, but often only a dozen are used on any | |
7c2db759 DB |
253 | given board. Another is to catch conflicts, identifying errors when |
254 | (a) two or more drivers wrongly think they have exclusive use of that | |
255 | signal, or (b) something wrongly believes it's safe to remove drivers | |
256 | needed to manage a signal that's in active use. That is, requesting a | |
257 | GPIO can serve as a kind of lock. | |
4c20386c | 258 | |
35e8bb51 DB |
259 | Some platforms may also use knowledge about what GPIOs are active for |
260 | power management, such as by powering down unused chip sectors and, more | |
261 | easily, gating off unused clocks. | |
262 | ||
0dc665d4 SW |
263 | For GPIOs that use pins known to the pinctrl subsystem, that subsystem should |
264 | be informed of their use; a gpiolib driver's .request() operation may call | |
a9a1d2a7 LW |
265 | pinctrl_gpio_request(), and a gpiolib driver's .free() operation may call |
266 | pinctrl_gpio_free(). The pinctrl subsystem allows a pinctrl_gpio_request() | |
0dc665d4 SW |
267 | to succeed concurrently with a pin or pingroup being "owned" by a device for |
268 | pin multiplexing. | |
269 | ||
270 | Any programming of pin multiplexing hardware that is needed to route the | |
271 | GPIO signal to the appropriate pin should occur within a GPIO driver's | |
272 | .direction_input() or .direction_output() operations, and occur after any | |
273 | setup of an output GPIO's value. This allows a glitch-free migration from a | |
274 | pin's special function to GPIO. This is sometimes required when using a GPIO | |
275 | to implement a workaround on signals typically driven by a non-GPIO HW block. | |
276 | ||
277 | Some platforms allow some or all GPIO signals to be routed to different pins. | |
278 | Similarly, other aspects of the GPIO or pin may need to be configured, such as | |
279 | pullup/pulldown. Platform software should arrange that any such details are | |
280 | configured prior to gpio_request() being called for those GPIOs, e.g. using | |
281 | the pinctrl subsystem's mapping table, so that GPIO users need not be aware | |
282 | of these details. | |
4c20386c | 283 | |
7c2db759 DB |
284 | Also note that it's your responsibility to have stopped using a GPIO |
285 | before you free it. | |
286 | ||
3e45f1d1 | 287 | Considering in most cases GPIOs are actually configured right after they |
7ee2c130 | 288 | are claimed, three additional calls are defined:: |
3e45f1d1 EM |
289 | |
290 | /* request a single GPIO, with initial configuration specified by | |
291 | * 'flags', identical to gpio_request() wrt other arguments and | |
292 | * return value | |
293 | */ | |
294 | int gpio_request_one(unsigned gpio, unsigned long flags, const char *label); | |
295 | ||
3e45f1d1 EM |
296 | where 'flags' is currently defined to specify the following properties: |
297 | ||
298 | * GPIOF_DIR_IN - to configure direction as input | |
299 | * GPIOF_DIR_OUT - to configure direction as output | |
300 | ||
301 | * GPIOF_INIT_LOW - as output, set initial level to LOW | |
302 | * GPIOF_INIT_HIGH - as output, set initial level to HIGH | |
303 | ||
304 | since GPIOF_INIT_* are only valid when configured as output, so group valid | |
305 | combinations as: | |
306 | ||
307 | * GPIOF_IN - configure as input | |
308 | * GPIOF_OUT_INIT_LOW - configured as output, initial level LOW | |
309 | * GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH | |
310 | ||
3e45f1d1 | 311 | Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is |
7ee2c130 | 312 | introduced to encapsulate all three fields as:: |
3e45f1d1 EM |
313 | |
314 | struct gpio { | |
315 | unsigned gpio; | |
316 | unsigned long flags; | |
317 | const char *label; | |
318 | }; | |
319 | ||
7ee2c130 | 320 | A typical example of usage:: |
3e45f1d1 EM |
321 | |
322 | static struct gpio leds_gpios[] = { | |
323 | { 32, GPIOF_OUT_INIT_HIGH, "Power LED" }, /* default to ON */ | |
324 | { 33, GPIOF_OUT_INIT_LOW, "Green LED" }, /* default to OFF */ | |
325 | { 34, GPIOF_OUT_INIT_LOW, "Red LED" }, /* default to OFF */ | |
326 | { 35, GPIOF_OUT_INIT_LOW, "Blue LED" }, /* default to OFF */ | |
327 | { ... }, | |
328 | }; | |
329 | ||
330 | err = gpio_request_one(31, GPIOF_IN, "Reset Button"); | |
331 | if (err) | |
332 | ... | |
333 | ||
4c20386c DB |
334 | |
335 | GPIOs mapped to IRQs | |
336 | -------------------- | |
337 | GPIO numbers are unsigned integers; so are IRQ numbers. These make up | |
338 | two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can | |
7ee2c130 | 339 | map between them using calls like:: |
4c20386c DB |
340 | |
341 | /* map GPIO numbers to IRQ numbers */ | |
342 | int gpio_to_irq(unsigned gpio); | |
343 | ||
4c20386c DB |
344 | Those return either the corresponding number in the other namespace, or |
345 | else a negative errno code if the mapping can't be done. (For example, | |
7c2db759 | 346 | some GPIOs can't be used as IRQs.) It is an unchecked error to use a GPIO |
be1ff386 | 347 | number that wasn't set up as an input using gpio_direction_input(), or |
4c20386c DB |
348 | to use an IRQ number that didn't originally come from gpio_to_irq(). |
349 | ||
350 | These two mapping calls are expected to cost on the order of a single | |
351 | addition or subtraction. They're not allowed to sleep. | |
352 | ||
353 | Non-error values returned from gpio_to_irq() can be passed to request_irq() | |
354 | or free_irq(). They will often be stored into IRQ resources for platform | |
355 | devices, by the board-specific initialization code. Note that IRQ trigger | |
356 | options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are | |
357 | system wakeup capabilities. | |
358 | ||
4c20386c | 359 | |
1668be71 DB |
360 | Emulating Open Drain Signals |
361 | ---------------------------- | |
362 | Sometimes shared signals need to use "open drain" signaling, where only the | |
363 | low signal level is actually driven. (That term applies to CMOS transistors; | |
364 | "open collector" is used for TTL.) A pullup resistor causes the high signal | |
365 | level. This is sometimes called a "wire-AND"; or more practically, from the | |
366 | negative logic (low=true) perspective this is a "wire-OR". | |
367 | ||
368 | One common example of an open drain signal is a shared active-low IRQ line. | |
369 | Also, bidirectional data bus signals sometimes use open drain signals. | |
370 | ||
371 | Some GPIO controllers directly support open drain outputs; many don't. When | |
372 | you need open drain signaling but your hardware doesn't directly support it, | |
373 | there's a common idiom you can use to emulate it with any GPIO pin that can | |
374 | be used as either an input or an output: | |
375 | ||
376 | LOW: gpio_direction_output(gpio, 0) ... this drives the signal | |
377 | and overrides the pullup. | |
378 | ||
379 | HIGH: gpio_direction_input(gpio) ... this turns off the output, | |
380 | so the pullup (or some other device) controls the signal. | |
381 | ||
382 | If you are "driving" the signal high but gpio_get_value(gpio) reports a low | |
383 | value (after the appropriate rise time passes), you know some other component | |
384 | is driving the shared signal low. That's not necessarily an error. As one | |
385 | common example, that's how I2C clocks are stretched: a slave that needs a | |
386 | slower clock delays the rising edge of SCK, and the I2C master adjusts its | |
387 | signaling rate accordingly. | |
388 | ||
4c20386c | 389 | |
f23f1516 SH |
390 | GPIO controllers and the pinctrl subsystem |
391 | ------------------------------------------ | |
392 | ||
393 | A GPIO controller on a SOC might be tightly coupled with the pinctrl | |
394 | subsystem, in the sense that the pins can be used by other functions | |
395 | together with an optional gpio feature. We have already covered the | |
396 | case where e.g. a GPIO controller need to reserve a pin or set the | |
7ee2c130 | 397 | direction of a pin by calling any of:: |
f23f1516 | 398 | |
7ee2c130 JN |
399 | pinctrl_gpio_request() |
400 | pinctrl_gpio_free() | |
401 | pinctrl_gpio_direction_input() | |
402 | pinctrl_gpio_direction_output() | |
f23f1516 SH |
403 | |
404 | But how does the pin control subsystem cross-correlate the GPIO | |
405 | numbers (which are a global business) to a certain pin on a certain | |
406 | pin controller? | |
407 | ||
408 | This is done by registering "ranges" of pins, which are essentially | |
409 | cross-reference tables. These are described in | |
5513b411 | 410 | Documentation/driver-api/pin-control.rst |
f23f1516 SH |
411 | |
412 | While the pin allocation is totally managed by the pinctrl subsystem, | |
413 | gpio (under gpiolib) is still maintained by gpio drivers. It may happen | |
414 | that different pin ranges in a SoC is managed by different gpio drivers. | |
415 | ||
416 | This makes it logical to let gpio drivers announce their pin ranges to | |
a9a1d2a7 | 417 | the pin ctrl subsystem before it will call 'pinctrl_gpio_request' in order |
f23f1516 SH |
418 | to request the corresponding pin to be prepared by the pinctrl subsystem |
419 | before any gpio usage. | |
420 | ||
421 | For this, the gpio controller can register its pin range with pinctrl | |
422 | subsystem. There are two ways of doing it currently: with or without DT. | |
423 | ||
424 | For with DT support refer to Documentation/devicetree/bindings/gpio/gpio.txt. | |
425 | ||
426 | For non-DT support, user can call gpiochip_add_pin_range() with appropriate | |
427 | parameters to register a range of gpio pins with a pinctrl driver. For this | |
428 | exact name string of pinctrl device has to be passed as one of the | |
429 | argument to this routine. | |
430 | ||
431 | ||
4c20386c DB |
432 | What do these conventions omit? |
433 | =============================== | |
434 | One of the biggest things these conventions omit is pin multiplexing, since | |
435 | this is highly chip-specific and nonportable. One platform might not need | |
436 | explicit multiplexing; another might have just two options for use of any | |
437 | given pin; another might have eight options per pin; another might be able | |
438 | to route a given GPIO to any one of several pins. (Yes, those examples all | |
439 | come from systems that run Linux today.) | |
440 | ||
441 | Related to multiplexing is configuration and enabling of the pullups or | |
442 | pulldowns integrated on some platforms. Not all platforms support them, | |
443 | or support them in the same way; and any given board might use external | |
444 | pullups (or pulldowns) so that the on-chip ones should not be used. | |
7c2db759 | 445 | (When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.) |
7560fa60 DB |
446 | Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a |
447 | platform-specific issue, as are models like (not) having a one-to-one | |
448 | correspondence between configurable pins and GPIOs. | |
4c20386c DB |
449 | |
450 | There are other system-specific mechanisms that are not specified here, | |
451 | like the aforementioned options for input de-glitching and wire-OR output. | |
452 | Hardware may support reading or writing GPIOs in gangs, but that's usually | |
f5de6111 | 453 | configuration dependent: for GPIOs sharing the same bank. (GPIOs are |
4c20386c | 454 | commonly grouped in banks of 16 or 32, with a given SOC having several such |
7c2db759 DB |
455 | banks.) Some systems can trigger IRQs from output GPIOs, or read values |
456 | from pins not managed as GPIOs. Code relying on such mechanisms will | |
457 | necessarily be nonportable. | |
4c20386c | 458 | |
7c2db759 | 459 | Dynamic definition of GPIOs is not currently standard; for example, as |
4c20386c DB |
460 | a side effect of configuring an add-on board with some GPIO expanders. |
461 | ||
7c2db759 DB |
462 | |
463 | GPIO implementor's framework (OPTIONAL) | |
464 | ======================================= | |
465 | As noted earlier, there is an optional implementation framework making it | |
466 | easier for platforms to support different kinds of GPIO controller using | |
d8f388d8 | 467 | the same programming interface. This framework is called "gpiolib". |
7c2db759 DB |
468 | |
469 | As a debugging aid, if debugfs is available a /sys/kernel/debug/gpio file | |
470 | will be found there. That will list all the controllers registered through | |
471 | this framework, and the state of the GPIOs currently in use. | |
472 | ||
473 | ||
474 | Controller Drivers: gpio_chip | |
475 | ----------------------------- | |
476 | In this framework each GPIO controller is packaged as a "struct gpio_chip" | |
477 | with information common to each controller of that type: | |
478 | ||
479 | - methods to establish GPIO direction | |
480 | - methods used to access GPIO values | |
481 | - flag saying whether calls to its methods may sleep | |
482 | - optional debugfs dump method (showing extra state like pullup config) | |
483 | - label for diagnostics | |
484 | ||
485 | There is also per-instance data, which may come from device.platform_data: | |
486 | the number of its first GPIO, and how many GPIOs it exposes. | |
487 | ||
488 | The code implementing a gpio_chip should support multiple instances of the | |
489 | controller, possibly using the driver model. That code will configure each | |
490 | gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be | |
491 | rare; use gpiochip_remove() when it is unavoidable. | |
492 | ||
493 | Most often a gpio_chip is part of an instance-specific structure with state | |
494 | not exposed by the GPIO interfaces, such as addressing, power management, | |
bfc9dcab | 495 | and more. Chips such as codecs will have complex non-GPIO state. |
7c2db759 DB |
496 | |
497 | Any debugfs dump method should normally ignore signals which haven't been | |
498 | requested as GPIOs. They can use gpiochip_is_requested(), which returns | |
499 | either NULL or the label associated with that GPIO when it was requested. | |
500 | ||
501 | ||
502 | Platform Support | |
503 | ---------------- | |
65053e1a LW |
504 | To force-enable this framework, a platform's Kconfig will "select" GPIOLIB, |
505 | else it is up to the user to configure support for GPIO. | |
7c2db759 | 506 | |
7444a72e MB |
507 | If neither of these options are selected, the platform does not support |
508 | GPIOs through GPIO-lib and the code cannot be enabled by the user. | |
509 | ||
7c2db759 | 510 | Trivial implementations of those functions can directly use framework |
7ee2c130 | 511 | code, which always dispatches through the gpio_chip:: |
7c2db759 DB |
512 | |
513 | #define gpio_get_value __gpio_get_value | |
514 | #define gpio_set_value __gpio_set_value | |
7c2db759 DB |
515 | |
516 | Fancier implementations could instead define those as inline functions with | |
517 | logic optimizing access to specific SOC-based GPIOs. For example, if the | |
518 | referenced GPIO is the constant "12", getting or setting its value could | |
519 | cost as little as two or three instructions, never sleeping. When such an | |
520 | optimization is not possible those calls must delegate to the framework | |
521 | code, costing at least a few dozen instructions. For bitbanged I/O, such | |
522 | instruction savings can be significant. | |
523 | ||
524 | For SOCs, platform-specific code defines and registers gpio_chip instances | |
525 | for each bank of on-chip GPIOs. Those GPIOs should be numbered/labeled to | |
526 | match chip vendor documentation, and directly match board schematics. They | |
527 | may well start at zero and go up to a platform-specific limit. Such GPIOs | |
528 | are normally integrated into platform initialization to make them always be | |
529 | available, from arch_initcall() or earlier; they can often serve as IRQs. | |
530 | ||
531 | ||
532 | Board Support | |
533 | ------------- | |
534 | For external GPIO controllers -- such as I2C or SPI expanders, ASICs, multi | |
535 | function devices, FPGAs or CPLDs -- most often board-specific code handles | |
536 | registering controller devices and ensures that their drivers know what GPIO | |
537 | numbers to use with gpiochip_add(). Their numbers often start right after | |
538 | platform-specific GPIOs. | |
539 | ||
540 | For example, board setup code could create structures identifying the range | |
541 | of GPIOs that chip will expose, and passes them to each GPIO expander chip | |
542 | using platform_data. Then the chip driver's probe() routine could pass that | |
543 | data to gpiochip_add(). | |
544 | ||
545 | Initialization order can be important. For example, when a device relies on | |
546 | an I2C-based GPIO, its probe() routine should only be called after that GPIO | |
547 | becomes available. That may mean the device should not be registered until | |
548 | calls for that GPIO can work. One way to address such dependencies is for | |
549 | such gpio_chip controllers to provide setup() and teardown() callbacks to | |
550 | board specific code; those board specific callbacks would register devices | |
d8f388d8 DB |
551 | once all the necessary resources are available, and remove them later when |
552 | the GPIO controller device becomes unavailable. | |
553 | ||
554 | ||
555 | Sysfs Interface for Userspace (OPTIONAL) | |
556 | ======================================== | |
557 | Platforms which use the "gpiolib" implementors framework may choose to | |
558 | configure a sysfs user interface to GPIOs. This is different from the | |
559 | debugfs interface, since it provides control over GPIO direction and | |
560 | value instead of just showing a gpio state summary. Plus, it could be | |
561 | present on production systems without debugging support. | |
562 | ||
19f59460 | 563 | Given appropriate hardware documentation for the system, userspace could |
d8f388d8 DB |
564 | know for example that GPIO #23 controls the write protect line used to |
565 | protect boot loader segments in flash memory. System upgrade procedures | |
566 | may need to temporarily remove that protection, first importing a GPIO, | |
567 | then changing its output state, then updating the code before re-enabling | |
568 | the write protection. In normal use, GPIO #23 would never be touched, | |
569 | and the kernel would have no need to know about it. | |
570 | ||
571 | Again depending on appropriate hardware documentation, on some systems | |
572 | userspace GPIO can be used to determine system configuration data that | |
573 | standard kernels won't know about. And for some tasks, simple userspace | |
574 | GPIO drivers could be all that the system really needs. | |
575 | ||
576 | Note that standard kernel drivers exist for common "LEDs and Buttons" | |
577 | GPIO tasks: "leds-gpio" and "gpio_keys", respectively. Use those | |
578 | instead of talking directly to the GPIOs; they integrate with kernel | |
579 | frameworks better than your userspace code could. | |
580 | ||
581 | ||
582 | Paths in Sysfs | |
583 | -------------- | |
584 | There are three kinds of entry in /sys/class/gpio: | |
585 | ||
586 | - Control interfaces used to get userspace control over GPIOs; | |
587 | ||
588 | - GPIOs themselves; and | |
589 | ||
590 | - GPIO controllers ("gpio_chip" instances). | |
591 | ||
592 | That's in addition to standard files including the "device" symlink. | |
593 | ||
594 | The control interfaces are write-only: | |
595 | ||
596 | /sys/class/gpio/ | |
597 | ||
598 | "export" ... Userspace may ask the kernel to export control of | |
599 | a GPIO to userspace by writing its number to this file. | |
600 | ||
601 | Example: "echo 19 > export" will create a "gpio19" node | |
602 | for GPIO #19, if that's not requested by kernel code. | |
603 | ||
604 | "unexport" ... Reverses the effect of exporting to userspace. | |
605 | ||
606 | Example: "echo 19 > unexport" will remove a "gpio19" | |
607 | node exported using the "export" file. | |
608 | ||
609 | GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42) | |
610 | and have the following read/write attributes: | |
611 | ||
612 | /sys/class/gpio/gpioN/ | |
613 | ||
614 | "direction" ... reads as either "in" or "out". This value may | |
615 | normally be written. Writing as "out" defaults to | |
616 | initializing the value as low. To ensure glitch free | |
617 | operation, values "low" and "high" may be written to | |
618 | configure the GPIO as an output with that initial value. | |
619 | ||
620 | Note that this attribute *will not exist* if the kernel | |
621 | doesn't support changing the direction of a GPIO, or | |
622 | it was exported by kernel code that didn't explicitly | |
623 | allow userspace to reconfigure this GPIO's direction. | |
624 | ||
625 | "value" ... reads as either 0 (low) or 1 (high). If the GPIO | |
626 | is configured as an output, this value may be written; | |
627 | any nonzero value is treated as high. | |
628 | ||
ebde7b06 BW |
629 | If the pin can be configured as interrupt-generating interrupt |
630 | and if it has been configured to generate interrupts (see the | |
631 | description of "edge"), you can poll(2) on that file and | |
632 | poll(2) will return whenever the interrupt was triggered. If | |
9aac1e33 UKK |
633 | you use poll(2), set the events POLLPRI. If you use select(2), |
634 | set the file descriptor in exceptfds. After poll(2) returns, | |
635 | either lseek(2) to the beginning of the sysfs file and read the | |
636 | new value or close the file and re-open it to read the value. | |
ebde7b06 | 637 | |
ff77c352 DG |
638 | "edge" ... reads as either "none", "rising", "falling", or |
639 | "both". Write these strings to select the signal edge(s) | |
640 | that will make poll(2) on the "value" file return. | |
641 | ||
642 | This file exists only if the pin can be configured as an | |
643 | interrupt generating input pin. | |
644 | ||
07697461 JN |
645 | "active_low" ... reads as either 0 (false) or 1 (true). Write |
646 | any nonzero value to invert the value attribute both | |
647 | for reading and writing. Existing and subsequent | |
648 | poll(2) support configuration via the edge attribute | |
649 | for "rising" and "falling" edges will follow this | |
650 | setting. | |
651 | ||
bfc9dcab | 652 | GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the |
d8f388d8 DB |
653 | controller implementing GPIOs starting at #42) and have the following |
654 | read-only attributes: | |
655 | ||
656 | /sys/class/gpio/gpiochipN/ | |
657 | ||
658 | "base" ... same as N, the first GPIO managed by this chip | |
659 | ||
660 | "label" ... provided for diagnostics (not always unique) | |
661 | ||
662 | "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1) | |
663 | ||
664 | Board documentation should in most cases cover what GPIOs are used for | |
665 | what purposes. However, those numbers are not always stable; GPIOs on | |
666 | a daughtercard might be different depending on the base board being used, | |
667 | or other cards in the stack. In such cases, you may need to use the | |
668 | gpiochip nodes (possibly in conjunction with schematics) to determine | |
669 | the correct GPIO number to use for a given signal. | |
670 | ||
671 | ||
7ee2c130 JN |
672 | API Reference |
673 | ============= | |
674 | ||
675 | The functions listed in this section are deprecated. The GPIO descriptor based | |
676 | API should be used in new code. | |
677 | ||
678 | .. kernel-doc:: drivers/gpio/gpiolib-legacy.c | |
679 | :export: |