David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 1 | GPIO Interfaces |
| 2 | |
| 3 | This provides an overview of GPIO access conventions on Linux. |
| 4 | |
David Brownell | 7560fa6 | 2008-03-04 14:28:27 -0800 | [diff] [blame] | 5 | These calls use the gpio_* naming prefix. No other calls should use that |
| 6 | prefix, or the related __gpio_* prefix. |
| 7 | |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 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 |
David Brownell | 1668be7 | 2007-04-11 23:28:42 -0700 | [diff] [blame] | 33 | for the other value (notably, "open drain" signaling). |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 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 |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 38 | input de-glitch/debounce logic, sometimes with software controls. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 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 | |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 66 | Plus, this doesn't require any implementation framework, just an interface. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 67 | One platform might implement it as simple inline functions accessing chip |
| 68 | registers; another might implement it by delegating through abstractions |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 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.) |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 73 | |
| 74 | That said, if the convention is supported on their platform, drivers should |
David Brownell | 7560fa6 | 2008-03-04 14:28:27 -0800 | [diff] [blame] | 75 | use it when possible. Platforms must declare GENERIC_GPIO support in their |
| 76 | Kconfig (boolean true), and provide an <asm/gpio.h> file. Drivers that can't |
| 77 | work without standard GPIO calls should have Kconfig entries which depend |
| 78 | on GENERIC_GPIO. The GPIO calls are available, either as "real code" or as |
| 79 | optimized-away stubs, when drivers use the include file: |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 80 | |
David Brownell | 7560fa6 | 2008-03-04 14:28:27 -0800 | [diff] [blame] | 81 | #include <linux/gpio.h> |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 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 | |
David Brownell | a0a9983 | 2007-07-19 01:47:52 -0700 | [diff] [blame] | 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 | |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 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 |
David Brownell | f5de611 | 2007-02-16 01:27:14 -0800 | [diff] [blame] | 94 | "not available on this board", or indicating faults. Code that doesn't |
| 95 | touch the underlying hardware treats these integers as opaque cookies. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 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 | |
Guennadi Liakhovetski | e6de180 | 2008-04-28 02:14:46 -0700 | [diff] [blame] | 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 a number could reference a GPIO, you may use this predicate: |
| 113 | |
| 114 | int gpio_is_valid(int number); |
| 115 | |
| 116 | A number that's not valid will be rejected by calls which may request |
| 117 | or free GPIOs (see below). Other numbers may also be rejected; for |
| 118 | example, a number might be valid but unused on a given board. |
| 119 | |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 120 | Whether a platform supports multiple GPIO controllers is currently a |
| 121 | platform-specific implementation issue. |
| 122 | |
| 123 | |
| 124 | Using GPIOs |
| 125 | ----------- |
David Brownell | 8a0cecf | 2009-04-02 16:57:06 -0700 | [diff] [blame] | 126 | The first thing a system should do with a GPIO is allocate it, using |
| 127 | the gpio_request() call; see later. |
| 128 | |
| 129 | One of the next things to do with a GPIO, often in board setup code when |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 130 | setting up a platform_device using the GPIO, is mark its direction: |
| 131 | |
| 132 | /* set as input or output, returning 0 or negative errno */ |
| 133 | int gpio_direction_input(unsigned gpio); |
David Brownell | 28735a7 | 2007-03-16 13:38:14 -0800 | [diff] [blame] | 134 | int gpio_direction_output(unsigned gpio, int value); |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 135 | |
| 136 | The return value is zero for success, else a negative errno. It should |
| 137 | be checked, since the get/set calls don't have error returns and since |
David Brownell | 83c6590 | 2007-05-16 22:11:13 -0700 | [diff] [blame] | 138 | misconfiguration is possible. You should normally issue these calls from |
| 139 | a task context. However, for spinlock-safe GPIOs it's OK to use them |
| 140 | before tasking is enabled, as part of early board setup. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 141 | |
David Brownell | 28735a7 | 2007-03-16 13:38:14 -0800 | [diff] [blame] | 142 | For output GPIOs, the value provided becomes the initial output value. |
| 143 | This helps avoid signal glitching during system startup. |
| 144 | |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 145 | For compatibility with legacy interfaces to GPIOs, setting the direction |
| 146 | of a GPIO implicitly requests that GPIO (see below) if it has not been |
David Brownell | 8a0cecf | 2009-04-02 16:57:06 -0700 | [diff] [blame] | 147 | requested already. That compatibility is being removed from the optional |
| 148 | gpiolib framework. |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 149 | |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 150 | Setting the direction can fail if the GPIO number is invalid, or when |
| 151 | that particular GPIO can't be used in that mode. It's generally a bad |
| 152 | idea to rely on boot firmware to have set the direction correctly, since |
| 153 | it probably wasn't validated to do more than boot Linux. (Similarly, |
| 154 | that board setup code probably needs to multiplex that pin as a GPIO, |
| 155 | and configure pullups/pulldowns appropriately.) |
| 156 | |
| 157 | |
| 158 | Spinlock-Safe GPIO access |
| 159 | ------------------------- |
| 160 | Most GPIO controllers can be accessed with memory read/write instructions. |
| 161 | That doesn't need to sleep, and can safely be done from inside IRQ handlers. |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 162 | (That includes hardirq contexts on RT kernels.) |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 163 | |
| 164 | Use these calls to access such GPIOs: |
| 165 | |
| 166 | /* GPIO INPUT: return zero or nonzero */ |
| 167 | int gpio_get_value(unsigned gpio); |
| 168 | |
| 169 | /* GPIO OUTPUT */ |
| 170 | void gpio_set_value(unsigned gpio, int value); |
| 171 | |
| 172 | The values are boolean, zero for low, nonzero for high. When reading the |
| 173 | value of an output pin, the value returned should be what's seen on the |
| 174 | pin ... that won't always match the specified output value, because of |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 175 | issues including open-drain signaling and output latencies. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 176 | |
| 177 | The get/set calls have no error returns because "invalid GPIO" should have |
David Brownell | be1ff38 | 2007-07-23 18:43:57 -0700 | [diff] [blame] | 178 | been reported earlier from gpio_direction_*(). However, note that not all |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 179 | platforms can read the value of output pins; those that can't should always |
David Brownell | f5de611 | 2007-02-16 01:27:14 -0800 | [diff] [blame] | 180 | return zero. Also, using these calls for GPIOs that can't safely be accessed |
| 181 | without sleeping (see below) is an error. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 182 | |
David Brownell | f5de611 | 2007-02-16 01:27:14 -0800 | [diff] [blame] | 183 | Platform-specific implementations are encouraged to optimize the two |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 184 | calls to access the GPIO value in cases where the GPIO number (and for |
| 185 | output, value) are constant. It's normal for them to need only a couple |
| 186 | of instructions in such cases (reading or writing a hardware register), |
| 187 | and not to need spinlocks. Such optimized calls can make bitbanging |
| 188 | applications a lot more efficient (in both space and time) than spending |
| 189 | dozens of instructions on subroutine calls. |
| 190 | |
| 191 | |
| 192 | GPIO access that may sleep |
| 193 | -------------------------- |
| 194 | Some GPIO controllers must be accessed using message based busses like I2C |
| 195 | or SPI. Commands to read or write those GPIO values require waiting to |
| 196 | get to the head of a queue to transmit a command and get its response. |
| 197 | This requires sleeping, which can't be done from inside IRQ handlers. |
| 198 | |
| 199 | Platforms that support this type of GPIO distinguish them from other GPIOs |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 200 | by returning nonzero from this call (which requires a valid GPIO number, |
David Brownell | 8a0cecf | 2009-04-02 16:57:06 -0700 | [diff] [blame] | 201 | which should have been previously allocated with gpio_request): |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 202 | |
| 203 | int gpio_cansleep(unsigned gpio); |
| 204 | |
| 205 | To access such GPIOs, a different set of accessors is defined: |
| 206 | |
| 207 | /* GPIO INPUT: return zero or nonzero, might sleep */ |
| 208 | int gpio_get_value_cansleep(unsigned gpio); |
| 209 | |
| 210 | /* GPIO OUTPUT, might sleep */ |
| 211 | void gpio_set_value_cansleep(unsigned gpio, int value); |
| 212 | |
| 213 | Other than the fact that these calls might sleep, and will not be ignored |
| 214 | for GPIOs that can't be accessed from IRQ handlers, these calls act the |
| 215 | same as the spinlock-safe calls. |
| 216 | |
| 217 | |
David Brownell | 8a0cecf | 2009-04-02 16:57:06 -0700 | [diff] [blame] | 218 | Claiming and Releasing GPIOs |
| 219 | ---------------------------- |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 220 | To help catch system configuration errors, two calls are defined. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 221 | |
| 222 | /* request GPIO, returning 0 or negative errno. |
| 223 | * non-null labels may be useful for diagnostics. |
| 224 | */ |
| 225 | int gpio_request(unsigned gpio, const char *label); |
| 226 | |
| 227 | /* release previously-claimed GPIO */ |
| 228 | void gpio_free(unsigned gpio); |
| 229 | |
| 230 | Passing invalid GPIO numbers to gpio_request() will fail, as will requesting |
| 231 | GPIOs that have already been claimed with that call. The return value of |
David Brownell | 83c6590 | 2007-05-16 22:11:13 -0700 | [diff] [blame] | 232 | gpio_request() must be checked. You should normally issue these calls from |
| 233 | a task context. However, for spinlock-safe GPIOs it's OK to request GPIOs |
| 234 | before tasking is enabled, as part of early board setup. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 235 | |
| 236 | These calls serve two basic purposes. One is marking the signals which |
| 237 | are actually in use as GPIOs, for better diagnostics; systems may have |
| 238 | several hundred potential GPIOs, but often only a dozen are used on any |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 239 | given board. Another is to catch conflicts, identifying errors when |
| 240 | (a) two or more drivers wrongly think they have exclusive use of that |
| 241 | signal, or (b) something wrongly believes it's safe to remove drivers |
| 242 | needed to manage a signal that's in active use. That is, requesting a |
| 243 | GPIO can serve as a kind of lock. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 244 | |
David Brownell | 35e8bb5 | 2008-10-15 22:03:16 -0700 | [diff] [blame] | 245 | Some platforms may also use knowledge about what GPIOs are active for |
| 246 | power management, such as by powering down unused chip sectors and, more |
| 247 | easily, gating off unused clocks. |
| 248 | |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 249 | Note that requesting a GPIO does NOT cause it to be configured in any |
| 250 | way; it just marks that GPIO as in use. Separate code must handle any |
| 251 | pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown). |
| 252 | |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 253 | Also note that it's your responsibility to have stopped using a GPIO |
| 254 | before you free it. |
| 255 | |
Eric Miao | 3e45f1d | 2010-03-05 13:44:35 -0800 | [diff] [blame^] | 256 | Considering in most cases GPIOs are actually configured right after they |
| 257 | are claimed, three additional calls are defined: |
| 258 | |
| 259 | /* request a single GPIO, with initial configuration specified by |
| 260 | * 'flags', identical to gpio_request() wrt other arguments and |
| 261 | * return value |
| 262 | */ |
| 263 | int gpio_request_one(unsigned gpio, unsigned long flags, const char *label); |
| 264 | |
| 265 | /* request multiple GPIOs in a single call |
| 266 | */ |
| 267 | int gpio_request_array(struct gpio *array, size_t num); |
| 268 | |
| 269 | /* release multiple GPIOs in a single call |
| 270 | */ |
| 271 | void gpio_free_array(struct gpio *array, size_t num); |
| 272 | |
| 273 | where 'flags' is currently defined to specify the following properties: |
| 274 | |
| 275 | * GPIOF_DIR_IN - to configure direction as input |
| 276 | * GPIOF_DIR_OUT - to configure direction as output |
| 277 | |
| 278 | * GPIOF_INIT_LOW - as output, set initial level to LOW |
| 279 | * GPIOF_INIT_HIGH - as output, set initial level to HIGH |
| 280 | |
| 281 | since GPIOF_INIT_* are only valid when configured as output, so group valid |
| 282 | combinations as: |
| 283 | |
| 284 | * GPIOF_IN - configure as input |
| 285 | * GPIOF_OUT_INIT_LOW - configured as output, initial level LOW |
| 286 | * GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH |
| 287 | |
| 288 | In the future, these flags can be extended to support more properties such |
| 289 | as open-drain status. |
| 290 | |
| 291 | Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is |
| 292 | introduced to encapsulate all three fields as: |
| 293 | |
| 294 | struct gpio { |
| 295 | unsigned gpio; |
| 296 | unsigned long flags; |
| 297 | const char *label; |
| 298 | }; |
| 299 | |
| 300 | A typical example of usage: |
| 301 | |
| 302 | static struct gpio leds_gpios[] = { |
| 303 | { 32, GPIOF_OUT_INIT_HIGH, "Power LED" }, /* default to ON */ |
| 304 | { 33, GPIOF_OUT_INIT_LOW, "Green LED" }, /* default to OFF */ |
| 305 | { 34, GPIOF_OUT_INIT_LOW, "Red LED" }, /* default to OFF */ |
| 306 | { 35, GPIOF_OUT_INIT_LOW, "Blue LED" }, /* default to OFF */ |
| 307 | { ... }, |
| 308 | }; |
| 309 | |
| 310 | err = gpio_request_one(31, GPIOF_IN, "Reset Button"); |
| 311 | if (err) |
| 312 | ... |
| 313 | |
| 314 | err = gpio_request_array(leds_gpios, ARRAY_SIZE(leds_gpios)); |
| 315 | if (err) |
| 316 | ... |
| 317 | |
| 318 | gpio_free_array(leds_gpios, ARRAY_SIZE(leds_gpios)); |
| 319 | |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 320 | |
| 321 | GPIOs mapped to IRQs |
| 322 | -------------------- |
| 323 | GPIO numbers are unsigned integers; so are IRQ numbers. These make up |
| 324 | two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can |
| 325 | map between them using calls like: |
| 326 | |
| 327 | /* map GPIO numbers to IRQ numbers */ |
| 328 | int gpio_to_irq(unsigned gpio); |
| 329 | |
David Brownell | 0f6d504 | 2008-10-15 22:03:14 -0700 | [diff] [blame] | 330 | /* map IRQ numbers to GPIO numbers (avoid using this) */ |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 331 | int irq_to_gpio(unsigned irq); |
| 332 | |
| 333 | Those return either the corresponding number in the other namespace, or |
| 334 | else a negative errno code if the mapping can't be done. (For example, |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 335 | some GPIOs can't be used as IRQs.) It is an unchecked error to use a GPIO |
David Brownell | be1ff38 | 2007-07-23 18:43:57 -0700 | [diff] [blame] | 336 | number that wasn't set up as an input using gpio_direction_input(), or |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 337 | to use an IRQ number that didn't originally come from gpio_to_irq(). |
| 338 | |
| 339 | These two mapping calls are expected to cost on the order of a single |
| 340 | addition or subtraction. They're not allowed to sleep. |
| 341 | |
| 342 | Non-error values returned from gpio_to_irq() can be passed to request_irq() |
| 343 | or free_irq(). They will often be stored into IRQ resources for platform |
| 344 | devices, by the board-specific initialization code. Note that IRQ trigger |
| 345 | options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are |
| 346 | system wakeup capabilities. |
| 347 | |
| 348 | Non-error values returned from irq_to_gpio() would most commonly be used |
David Brownell | f5de611 | 2007-02-16 01:27:14 -0800 | [diff] [blame] | 349 | with gpio_get_value(), for example to initialize or update driver state |
David Brownell | 0f6d504 | 2008-10-15 22:03:14 -0700 | [diff] [blame] | 350 | when the IRQ is edge-triggered. Note that some platforms don't support |
| 351 | this reverse mapping, so you should avoid using it. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 352 | |
| 353 | |
David Brownell | 1668be7 | 2007-04-11 23:28:42 -0700 | [diff] [blame] | 354 | Emulating Open Drain Signals |
| 355 | ---------------------------- |
| 356 | Sometimes shared signals need to use "open drain" signaling, where only the |
| 357 | low signal level is actually driven. (That term applies to CMOS transistors; |
| 358 | "open collector" is used for TTL.) A pullup resistor causes the high signal |
| 359 | level. This is sometimes called a "wire-AND"; or more practically, from the |
| 360 | negative logic (low=true) perspective this is a "wire-OR". |
| 361 | |
| 362 | One common example of an open drain signal is a shared active-low IRQ line. |
| 363 | Also, bidirectional data bus signals sometimes use open drain signals. |
| 364 | |
| 365 | Some GPIO controllers directly support open drain outputs; many don't. When |
| 366 | you need open drain signaling but your hardware doesn't directly support it, |
| 367 | there's a common idiom you can use to emulate it with any GPIO pin that can |
| 368 | be used as either an input or an output: |
| 369 | |
| 370 | LOW: gpio_direction_output(gpio, 0) ... this drives the signal |
| 371 | and overrides the pullup. |
| 372 | |
| 373 | HIGH: gpio_direction_input(gpio) ... this turns off the output, |
| 374 | so the pullup (or some other device) controls the signal. |
| 375 | |
| 376 | If you are "driving" the signal high but gpio_get_value(gpio) reports a low |
| 377 | value (after the appropriate rise time passes), you know some other component |
| 378 | is driving the shared signal low. That's not necessarily an error. As one |
| 379 | common example, that's how I2C clocks are stretched: a slave that needs a |
| 380 | slower clock delays the rising edge of SCK, and the I2C master adjusts its |
| 381 | signaling rate accordingly. |
| 382 | |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 383 | |
| 384 | What do these conventions omit? |
| 385 | =============================== |
| 386 | One of the biggest things these conventions omit is pin multiplexing, since |
| 387 | this is highly chip-specific and nonportable. One platform might not need |
| 388 | explicit multiplexing; another might have just two options for use of any |
| 389 | given pin; another might have eight options per pin; another might be able |
| 390 | to route a given GPIO to any one of several pins. (Yes, those examples all |
| 391 | come from systems that run Linux today.) |
| 392 | |
| 393 | Related to multiplexing is configuration and enabling of the pullups or |
| 394 | pulldowns integrated on some platforms. Not all platforms support them, |
| 395 | or support them in the same way; and any given board might use external |
| 396 | pullups (or pulldowns) so that the on-chip ones should not be used. |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 397 | (When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.) |
David Brownell | 7560fa6 | 2008-03-04 14:28:27 -0800 | [diff] [blame] | 398 | Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a |
| 399 | platform-specific issue, as are models like (not) having a one-to-one |
| 400 | correspondence between configurable pins and GPIOs. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 401 | |
| 402 | There are other system-specific mechanisms that are not specified here, |
| 403 | like the aforementioned options for input de-glitching and wire-OR output. |
| 404 | Hardware may support reading or writing GPIOs in gangs, but that's usually |
David Brownell | f5de611 | 2007-02-16 01:27:14 -0800 | [diff] [blame] | 405 | configuration dependent: for GPIOs sharing the same bank. (GPIOs are |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 406 | commonly grouped in banks of 16 or 32, with a given SOC having several such |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 407 | banks.) Some systems can trigger IRQs from output GPIOs, or read values |
| 408 | from pins not managed as GPIOs. Code relying on such mechanisms will |
| 409 | necessarily be nonportable. |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 410 | |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 411 | Dynamic definition of GPIOs is not currently standard; for example, as |
David Brownell | 4c20386 | 2007-02-12 00:53:11 -0800 | [diff] [blame] | 412 | a side effect of configuring an add-on board with some GPIO expanders. |
| 413 | |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 414 | |
| 415 | GPIO implementor's framework (OPTIONAL) |
| 416 | ======================================= |
| 417 | As noted earlier, there is an optional implementation framework making it |
| 418 | easier for platforms to support different kinds of GPIO controller using |
David Brownell | d8f388d8 | 2008-07-25 01:46:07 -0700 | [diff] [blame] | 419 | the same programming interface. This framework is called "gpiolib". |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 420 | |
| 421 | As a debugging aid, if debugfs is available a /sys/kernel/debug/gpio file |
| 422 | will be found there. That will list all the controllers registered through |
| 423 | this framework, and the state of the GPIOs currently in use. |
| 424 | |
| 425 | |
| 426 | Controller Drivers: gpio_chip |
| 427 | ----------------------------- |
| 428 | In this framework each GPIO controller is packaged as a "struct gpio_chip" |
| 429 | with information common to each controller of that type: |
| 430 | |
| 431 | - methods to establish GPIO direction |
| 432 | - methods used to access GPIO values |
| 433 | - flag saying whether calls to its methods may sleep |
| 434 | - optional debugfs dump method (showing extra state like pullup config) |
| 435 | - label for diagnostics |
| 436 | |
| 437 | There is also per-instance data, which may come from device.platform_data: |
| 438 | the number of its first GPIO, and how many GPIOs it exposes. |
| 439 | |
| 440 | The code implementing a gpio_chip should support multiple instances of the |
| 441 | controller, possibly using the driver model. That code will configure each |
| 442 | gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be |
| 443 | rare; use gpiochip_remove() when it is unavoidable. |
| 444 | |
| 445 | Most often a gpio_chip is part of an instance-specific structure with state |
| 446 | not exposed by the GPIO interfaces, such as addressing, power management, |
Dominik D. Geyer | bfc9dca | 2009-12-06 18:30:44 -0800 | [diff] [blame] | 447 | and more. Chips such as codecs will have complex non-GPIO state. |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 448 | |
| 449 | Any debugfs dump method should normally ignore signals which haven't been |
| 450 | requested as GPIOs. They can use gpiochip_is_requested(), which returns |
| 451 | either NULL or the label associated with that GPIO when it was requested. |
| 452 | |
| 453 | |
| 454 | Platform Support |
| 455 | ---------------- |
Michael Buesch | 7444a72 | 2008-07-25 01:46:11 -0700 | [diff] [blame] | 456 | To support this framework, a platform's Kconfig will "select" either |
| 457 | ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 458 | and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines |
| 459 | three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep(). |
| 460 | They may also want to provide a custom value for ARCH_NR_GPIOS. |
| 461 | |
Michael Buesch | 7444a72 | 2008-07-25 01:46:11 -0700 | [diff] [blame] | 462 | ARCH_REQUIRE_GPIOLIB means that the gpio-lib code will always get compiled |
| 463 | into the kernel on that architecture. |
| 464 | |
| 465 | ARCH_WANT_OPTIONAL_GPIOLIB means the gpio-lib code defaults to off and the user |
| 466 | can enable it and build it into the kernel optionally. |
| 467 | |
| 468 | If neither of these options are selected, the platform does not support |
| 469 | GPIOs through GPIO-lib and the code cannot be enabled by the user. |
| 470 | |
David Brownell | 7c2db75 | 2008-02-04 22:28:21 -0800 | [diff] [blame] | 471 | Trivial implementations of those functions can directly use framework |
| 472 | code, which always dispatches through the gpio_chip: |
| 473 | |
| 474 | #define gpio_get_value __gpio_get_value |
| 475 | #define gpio_set_value __gpio_set_value |
| 476 | #define gpio_cansleep __gpio_cansleep |
| 477 | |
| 478 | Fancier implementations could instead define those as inline functions with |
| 479 | logic optimizing access to specific SOC-based GPIOs. For example, if the |
| 480 | referenced GPIO is the constant "12", getting or setting its value could |
| 481 | cost as little as two or three instructions, never sleeping. When such an |
| 482 | optimization is not possible those calls must delegate to the framework |
| 483 | code, costing at least a few dozen instructions. For bitbanged I/O, such |
| 484 | instruction savings can be significant. |
| 485 | |
| 486 | For SOCs, platform-specific code defines and registers gpio_chip instances |
| 487 | for each bank of on-chip GPIOs. Those GPIOs should be numbered/labeled to |
| 488 | match chip vendor documentation, and directly match board schematics. They |
| 489 | may well start at zero and go up to a platform-specific limit. Such GPIOs |
| 490 | are normally integrated into platform initialization to make them always be |
| 491 | available, from arch_initcall() or earlier; they can often serve as IRQs. |
| 492 | |
| 493 | |
| 494 | Board Support |
| 495 | ------------- |
| 496 | For external GPIO controllers -- such as I2C or SPI expanders, ASICs, multi |
| 497 | function devices, FPGAs or CPLDs -- most often board-specific code handles |
| 498 | registering controller devices and ensures that their drivers know what GPIO |
| 499 | numbers to use with gpiochip_add(). Their numbers often start right after |
| 500 | platform-specific GPIOs. |
| 501 | |
| 502 | For example, board setup code could create structures identifying the range |
| 503 | of GPIOs that chip will expose, and passes them to each GPIO expander chip |
| 504 | using platform_data. Then the chip driver's probe() routine could pass that |
| 505 | data to gpiochip_add(). |
| 506 | |
| 507 | Initialization order can be important. For example, when a device relies on |
| 508 | an I2C-based GPIO, its probe() routine should only be called after that GPIO |
| 509 | becomes available. That may mean the device should not be registered until |
| 510 | calls for that GPIO can work. One way to address such dependencies is for |
| 511 | such gpio_chip controllers to provide setup() and teardown() callbacks to |
| 512 | board specific code; those board specific callbacks would register devices |
David Brownell | d8f388d8 | 2008-07-25 01:46:07 -0700 | [diff] [blame] | 513 | once all the necessary resources are available, and remove them later when |
| 514 | the GPIO controller device becomes unavailable. |
| 515 | |
| 516 | |
| 517 | Sysfs Interface for Userspace (OPTIONAL) |
| 518 | ======================================== |
| 519 | Platforms which use the "gpiolib" implementors framework may choose to |
| 520 | configure a sysfs user interface to GPIOs. This is different from the |
| 521 | debugfs interface, since it provides control over GPIO direction and |
| 522 | value instead of just showing a gpio state summary. Plus, it could be |
| 523 | present on production systems without debugging support. |
| 524 | |
Matt LaPlante | 19f5946 | 2009-04-27 15:06:31 +0200 | [diff] [blame] | 525 | Given appropriate hardware documentation for the system, userspace could |
David Brownell | d8f388d8 | 2008-07-25 01:46:07 -0700 | [diff] [blame] | 526 | know for example that GPIO #23 controls the write protect line used to |
| 527 | protect boot loader segments in flash memory. System upgrade procedures |
| 528 | may need to temporarily remove that protection, first importing a GPIO, |
| 529 | then changing its output state, then updating the code before re-enabling |
| 530 | the write protection. In normal use, GPIO #23 would never be touched, |
| 531 | and the kernel would have no need to know about it. |
| 532 | |
| 533 | Again depending on appropriate hardware documentation, on some systems |
| 534 | userspace GPIO can be used to determine system configuration data that |
| 535 | standard kernels won't know about. And for some tasks, simple userspace |
| 536 | GPIO drivers could be all that the system really needs. |
| 537 | |
| 538 | Note that standard kernel drivers exist for common "LEDs and Buttons" |
| 539 | GPIO tasks: "leds-gpio" and "gpio_keys", respectively. Use those |
| 540 | instead of talking directly to the GPIOs; they integrate with kernel |
| 541 | frameworks better than your userspace code could. |
| 542 | |
| 543 | |
| 544 | Paths in Sysfs |
| 545 | -------------- |
| 546 | There are three kinds of entry in /sys/class/gpio: |
| 547 | |
| 548 | - Control interfaces used to get userspace control over GPIOs; |
| 549 | |
| 550 | - GPIOs themselves; and |
| 551 | |
| 552 | - GPIO controllers ("gpio_chip" instances). |
| 553 | |
| 554 | That's in addition to standard files including the "device" symlink. |
| 555 | |
| 556 | The control interfaces are write-only: |
| 557 | |
| 558 | /sys/class/gpio/ |
| 559 | |
| 560 | "export" ... Userspace may ask the kernel to export control of |
| 561 | a GPIO to userspace by writing its number to this file. |
| 562 | |
| 563 | Example: "echo 19 > export" will create a "gpio19" node |
| 564 | for GPIO #19, if that's not requested by kernel code. |
| 565 | |
| 566 | "unexport" ... Reverses the effect of exporting to userspace. |
| 567 | |
| 568 | Example: "echo 19 > unexport" will remove a "gpio19" |
| 569 | node exported using the "export" file. |
| 570 | |
| 571 | GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42) |
| 572 | and have the following read/write attributes: |
| 573 | |
| 574 | /sys/class/gpio/gpioN/ |
| 575 | |
| 576 | "direction" ... reads as either "in" or "out". This value may |
| 577 | normally be written. Writing as "out" defaults to |
| 578 | initializing the value as low. To ensure glitch free |
| 579 | operation, values "low" and "high" may be written to |
| 580 | configure the GPIO as an output with that initial value. |
| 581 | |
| 582 | Note that this attribute *will not exist* if the kernel |
| 583 | doesn't support changing the direction of a GPIO, or |
| 584 | it was exported by kernel code that didn't explicitly |
| 585 | allow userspace to reconfigure this GPIO's direction. |
| 586 | |
| 587 | "value" ... reads as either 0 (low) or 1 (high). If the GPIO |
| 588 | is configured as an output, this value may be written; |
| 589 | any nonzero value is treated as high. |
| 590 | |
Daniel Glöckner | ff77c35 | 2009-09-22 16:46:38 -0700 | [diff] [blame] | 591 | "edge" ... reads as either "none", "rising", "falling", or |
| 592 | "both". Write these strings to select the signal edge(s) |
| 593 | that will make poll(2) on the "value" file return. |
| 594 | |
| 595 | This file exists only if the pin can be configured as an |
| 596 | interrupt generating input pin. |
| 597 | |
Jani Nikula | 0769746 | 2009-12-15 16:46:20 -0800 | [diff] [blame] | 598 | "active_low" ... reads as either 0 (false) or 1 (true). Write |
| 599 | any nonzero value to invert the value attribute both |
| 600 | for reading and writing. Existing and subsequent |
| 601 | poll(2) support configuration via the edge attribute |
| 602 | for "rising" and "falling" edges will follow this |
| 603 | setting. |
| 604 | |
Dominik D. Geyer | bfc9dca | 2009-12-06 18:30:44 -0800 | [diff] [blame] | 605 | GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the |
David Brownell | d8f388d8 | 2008-07-25 01:46:07 -0700 | [diff] [blame] | 606 | controller implementing GPIOs starting at #42) and have the following |
| 607 | read-only attributes: |
| 608 | |
| 609 | /sys/class/gpio/gpiochipN/ |
| 610 | |
| 611 | "base" ... same as N, the first GPIO managed by this chip |
| 612 | |
| 613 | "label" ... provided for diagnostics (not always unique) |
| 614 | |
| 615 | "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1) |
| 616 | |
| 617 | Board documentation should in most cases cover what GPIOs are used for |
| 618 | what purposes. However, those numbers are not always stable; GPIOs on |
| 619 | a daughtercard might be different depending on the base board being used, |
| 620 | or other cards in the stack. In such cases, you may need to use the |
| 621 | gpiochip nodes (possibly in conjunction with schematics) to determine |
| 622 | the correct GPIO number to use for a given signal. |
| 623 | |
| 624 | |
| 625 | Exporting from Kernel code |
| 626 | -------------------------- |
| 627 | Kernel code can explicitly manage exports of GPIOs which have already been |
| 628 | requested using gpio_request(): |
| 629 | |
| 630 | /* export the GPIO to userspace */ |
| 631 | int gpio_export(unsigned gpio, bool direction_may_change); |
| 632 | |
| 633 | /* reverse gpio_export() */ |
| 634 | void gpio_unexport(); |
| 635 | |
Jani Nikula | a4177ee | 2009-09-22 16:46:33 -0700 | [diff] [blame] | 636 | /* create a sysfs link to an exported GPIO node */ |
| 637 | int gpio_export_link(struct device *dev, const char *name, |
| 638 | unsigned gpio) |
| 639 | |
Jani Nikula | 0769746 | 2009-12-15 16:46:20 -0800 | [diff] [blame] | 640 | /* change the polarity of a GPIO node in sysfs */ |
| 641 | int gpio_sysfs_set_active_low(unsigned gpio, int value); |
Jani Nikula | a4177ee | 2009-09-22 16:46:33 -0700 | [diff] [blame] | 642 | |
David Brownell | d8f388d8 | 2008-07-25 01:46:07 -0700 | [diff] [blame] | 643 | After a kernel driver requests a GPIO, it may only be made available in |
| 644 | the sysfs interface by gpio_export(). The driver can control whether the |
| 645 | signal direction may change. This helps drivers prevent userspace code |
| 646 | from accidentally clobbering important system state. |
| 647 | |
| 648 | This explicit exporting can help with debugging (by making some kinds |
| 649 | of experiments easier), or can provide an always-there interface that's |
| 650 | suitable for documenting as part of a board support package. |
Jani Nikula | a4177ee | 2009-09-22 16:46:33 -0700 | [diff] [blame] | 651 | |
| 652 | After the GPIO has been exported, gpio_export_link() allows creating |
| 653 | symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can |
| 654 | use this to provide the interface under their own device in sysfs with |
| 655 | a descriptive name. |
Jani Nikula | 0769746 | 2009-12-15 16:46:20 -0800 | [diff] [blame] | 656 | |
| 657 | Drivers can use gpio_sysfs_set_active_low() to hide GPIO line polarity |
| 658 | differences between boards from user space. This only affects the |
| 659 | sysfs interface. Polarity change can be done both before and after |
| 660 | gpio_export(), and previously enabled poll(2) support for either |
| 661 | rising or falling edge will be reconfigured to follow this setting. |