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