Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 1 | GPIO Descriptor Consumer Interface |
| 2 | ================================== |
| 3 | |
| 4 | This document describes the consumer interface of the GPIO framework. Note that |
| 5 | it describes the new descriptor-based interface. For a description of the |
| 6 | deprecated integer-based GPIO interface please refer to gpio-legacy.txt. |
| 7 | |
| 8 | |
| 9 | Guidelines for GPIOs consumers |
| 10 | ============================== |
| 11 | |
| 12 | Drivers that can't work without standard GPIO calls should have Kconfig entries |
| 13 | that depend on GPIOLIB. The functions that allow a driver to obtain and use |
| 14 | GPIOs are available by including the following file: |
| 15 | |
| 16 | #include <linux/gpio/consumer.h> |
| 17 | |
| 18 | All the functions that work with the descriptor-based GPIO interface are |
| 19 | prefixed with gpiod_. The gpio_ prefix is used for the legacy interface. No |
| 20 | other function in the kernel should use these prefixes. |
| 21 | |
| 22 | |
| 23 | Obtaining and Disposing GPIOs |
| 24 | ============================= |
| 25 | |
| 26 | With the descriptor-based interface, GPIOs are identified with an opaque, |
| 27 | non-forgeable handler that must be obtained through a call to one of the |
| 28 | gpiod_get() functions. Like many other kernel subsystems, gpiod_get() takes the |
| 29 | device that will use the GPIO and the function the requested GPIO is supposed to |
| 30 | fulfill: |
| 31 | |
Alexandre Courbot | 39b2bbe | 2014-07-25 23:38:36 +0900 | [diff] [blame] | 32 | struct gpio_desc *gpiod_get(struct device *dev, const char *con_id, |
| 33 | enum gpiod_flags flags) |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 34 | |
| 35 | If a function is implemented by using several GPIOs together (e.g. a simple LED |
| 36 | device that displays digits), an additional index argument can be specified: |
| 37 | |
| 38 | struct gpio_desc *gpiod_get_index(struct device *dev, |
Alexandre Courbot | 39b2bbe | 2014-07-25 23:38:36 +0900 | [diff] [blame] | 39 | const char *con_id, unsigned int idx, |
| 40 | enum gpiod_flags flags) |
| 41 | |
| 42 | The flags parameter is used to optionally specify a direction and initial value |
| 43 | for the GPIO. Values can be: |
| 44 | |
| 45 | * GPIOD_ASIS or 0 to not initialize the GPIO at all. The direction must be set |
| 46 | later with one of the dedicated functions. |
| 47 | * GPIOD_IN to initialize the GPIO as input. |
| 48 | * GPIOD_OUT_LOW to initialize the GPIO as output with a value of 0. |
| 49 | * GPIOD_OUT_HIGH to initialize the GPIO as output with a value of 1. |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 50 | |
| 51 | Both functions return either a valid GPIO descriptor, or an error code checkable |
Alexandre Courbot | 2a3cf6a | 2013-12-11 11:32:28 +0900 | [diff] [blame] | 52 | with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned |
| 53 | if and only if no GPIO has been assigned to the device/function/index triplet, |
| 54 | other error codes are used for cases where a GPIO has been assigned but an error |
Carlos Garcia | c98be0c | 2014-04-04 22:31:00 -0400 | [diff] [blame] | 55 | occurred while trying to acquire it. This is useful to discriminate between mere |
Alexandre Courbot | 1b11a9b | 2014-08-18 09:39:01 -0700 | [diff] [blame] | 56 | errors and an absence of GPIO for optional GPIO parameters. For the common |
| 57 | pattern where a GPIO is optional, the gpiod_get_optional() and |
| 58 | gpiod_get_index_optional() functions can be used. These functions return NULL |
| 59 | instead of -ENOENT if no GPIO has been assigned to the requested function: |
| 60 | |
| 61 | |
| 62 | struct gpio_desc *gpiod_get_optional(struct device *dev, |
| 63 | const char *con_id, |
| 64 | enum gpiod_flags flags) |
| 65 | |
| 66 | struct gpio_desc *gpiod_get_index_optional(struct device *dev, |
| 67 | const char *con_id, |
| 68 | unsigned int index, |
| 69 | enum gpiod_flags flags) |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 70 | |
| 71 | Device-managed variants of these functions are also defined: |
| 72 | |
Alexandre Courbot | 39b2bbe | 2014-07-25 23:38:36 +0900 | [diff] [blame] | 73 | struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id, |
| 74 | enum gpiod_flags flags) |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 75 | |
| 76 | struct gpio_desc *devm_gpiod_get_index(struct device *dev, |
| 77 | const char *con_id, |
Alexandre Courbot | 39b2bbe | 2014-07-25 23:38:36 +0900 | [diff] [blame] | 78 | unsigned int idx, |
| 79 | enum gpiod_flags flags) |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 80 | |
Alexandre Courbot | 1b11a9b | 2014-08-18 09:39:01 -0700 | [diff] [blame] | 81 | struct gpio_desc *devm_gpiod_get_optional(struct device *dev, |
| 82 | const char *con_id, |
| 83 | enum gpiod_flags flags) |
| 84 | |
| 85 | struct gpio_desc * devm_gpiod_get_index_optional(struct device *dev, |
| 86 | const char *con_id, |
| 87 | unsigned int index, |
| 88 | enum gpiod_flags flags) |
| 89 | |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 90 | A GPIO descriptor can be disposed of using the gpiod_put() function: |
| 91 | |
| 92 | void gpiod_put(struct gpio_desc *desc) |
| 93 | |
| 94 | It is strictly forbidden to use a descriptor after calling this function. The |
| 95 | device-managed variant is, unsurprisingly: |
| 96 | |
| 97 | void devm_gpiod_put(struct device *dev, struct gpio_desc *desc) |
| 98 | |
| 99 | |
| 100 | Using GPIOs |
| 101 | =========== |
| 102 | |
| 103 | Setting Direction |
| 104 | ----------------- |
Alexandre Courbot | 39b2bbe | 2014-07-25 23:38:36 +0900 | [diff] [blame] | 105 | The first thing a driver must do with a GPIO is setting its direction. If no |
| 106 | direction-setting flags have been given to gpiod_get*(), this is done by |
| 107 | invoking one of the gpiod_direction_*() functions: |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 108 | |
| 109 | int gpiod_direction_input(struct gpio_desc *desc) |
| 110 | int gpiod_direction_output(struct gpio_desc *desc, int value) |
| 111 | |
| 112 | The return value is zero for success, else a negative errno. It should be |
| 113 | checked, since the get/set calls don't return errors and since misconfiguration |
| 114 | is possible. You should normally issue these calls from a task context. However, |
| 115 | for spinlock-safe GPIOs it is OK to use them before tasking is enabled, as part |
| 116 | of early board setup. |
| 117 | |
| 118 | For output GPIOs, the value provided becomes the initial output value. This |
| 119 | helps avoid signal glitching during system startup. |
| 120 | |
| 121 | A driver can also query the current direction of a GPIO: |
| 122 | |
| 123 | int gpiod_get_direction(const struct gpio_desc *desc) |
| 124 | |
| 125 | This function will return either GPIOF_DIR_IN or GPIOF_DIR_OUT. |
| 126 | |
| 127 | Be aware that there is no default direction for GPIOs. Therefore, **using a GPIO |
| 128 | without setting its direction first is illegal and will result in undefined |
| 129 | behavior!** |
| 130 | |
| 131 | |
| 132 | Spinlock-Safe GPIO Access |
| 133 | ------------------------- |
| 134 | Most GPIO controllers can be accessed with memory read/write instructions. Those |
| 135 | don't need to sleep, and can safely be done from inside hard (non-threaded) IRQ |
| 136 | handlers and similar contexts. |
| 137 | |
| 138 | Use the following calls to access GPIOs from an atomic context: |
| 139 | |
| 140 | int gpiod_get_value(const struct gpio_desc *desc); |
| 141 | void gpiod_set_value(struct gpio_desc *desc, int value); |
| 142 | |
| 143 | The values are boolean, zero for low, nonzero for high. When reading the value |
| 144 | of an output pin, the value returned should be what's seen on the pin. That |
| 145 | won't always match the specified output value, because of issues including |
| 146 | open-drain signaling and output latencies. |
| 147 | |
| 148 | The get/set calls do not return errors because "invalid GPIO" should have been |
| 149 | reported earlier from gpiod_direction_*(). However, note that not all platforms |
| 150 | can read the value of output pins; those that can't should always return zero. |
| 151 | Also, using these calls for GPIOs that can't safely be accessed without sleeping |
| 152 | (see below) is an error. |
| 153 | |
| 154 | |
| 155 | GPIO Access That May Sleep |
| 156 | -------------------------- |
| 157 | Some GPIO controllers must be accessed using message based buses like I2C or |
| 158 | SPI. Commands to read or write those GPIO values require waiting to get to the |
| 159 | head of a queue to transmit a command and get its response. This requires |
| 160 | sleeping, which can't be done from inside IRQ handlers. |
| 161 | |
| 162 | Platforms that support this type of GPIO distinguish them from other GPIOs by |
| 163 | returning nonzero from this call: |
| 164 | |
| 165 | int gpiod_cansleep(const struct gpio_desc *desc) |
| 166 | |
| 167 | To access such GPIOs, a different set of accessors is defined: |
| 168 | |
| 169 | int gpiod_get_value_cansleep(const struct gpio_desc *desc) |
| 170 | void gpiod_set_value_cansleep(struct gpio_desc *desc, int value) |
| 171 | |
| 172 | Accessing such GPIOs requires a context which may sleep, for example a threaded |
| 173 | IRQ handler, and those accessors must be used instead of spinlock-safe |
| 174 | accessors without the cansleep() name suffix. |
| 175 | |
| 176 | Other than the fact that these accessors might sleep, and will work on GPIOs |
| 177 | that can't be accessed from hardIRQ handlers, these calls act the same as the |
| 178 | spinlock-safe calls. |
| 179 | |
| 180 | |
| 181 | Active-low State and Raw GPIO Values |
| 182 | ------------------------------------ |
| 183 | Device drivers like to manage the logical state of a GPIO, i.e. the value their |
| 184 | device will actually receive, no matter what lies between it and the GPIO line. |
| 185 | In some cases, it might make sense to control the actual GPIO line value. The |
| 186 | following set of calls ignore the active-low property of a GPIO and work on the |
| 187 | raw line value: |
| 188 | |
| 189 | int gpiod_get_raw_value(const struct gpio_desc *desc) |
| 190 | void gpiod_set_raw_value(struct gpio_desc *desc, int value) |
| 191 | int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc) |
| 192 | void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value) |
Philipp Zabel | ef70bbe | 2014-01-07 12:34:11 +0100 | [diff] [blame] | 193 | int gpiod_direction_output_raw(struct gpio_desc *desc, int value) |
Alexandre Courbot | fd8e198 | 2013-11-16 21:34:21 +0900 | [diff] [blame] | 194 | |
| 195 | The active-low state of a GPIO can also be queried using the following call: |
| 196 | |
| 197 | int gpiod_is_active_low(const struct gpio_desc *desc) |
| 198 | |
| 199 | Note that these functions should only be used with great moderation ; a driver |
| 200 | should not have to care about the physical line level. |
| 201 | |
| 202 | GPIOs mapped to IRQs |
| 203 | -------------------- |
| 204 | GPIO lines can quite often be used as IRQs. You can get the IRQ number |
| 205 | corresponding to a given GPIO using the following call: |
| 206 | |
| 207 | int gpiod_to_irq(const struct gpio_desc *desc) |
| 208 | |
| 209 | It will return an IRQ number, or an negative errno code if the mapping can't be |
| 210 | done (most likely because that particular GPIO cannot be used as IRQ). It is an |
| 211 | unchecked error to use a GPIO that wasn't set up as an input using |
| 212 | gpiod_direction_input(), or to use an IRQ number that didn't originally come |
| 213 | from gpiod_to_irq(). gpiod_to_irq() is not allowed to sleep. |
| 214 | |
| 215 | Non-error values returned from gpiod_to_irq() can be passed to request_irq() or |
| 216 | free_irq(). They will often be stored into IRQ resources for platform devices, |
| 217 | by the board-specific initialization code. Note that IRQ trigger options are |
| 218 | part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are system wakeup |
| 219 | capabilities. |
| 220 | |
| 221 | |
| 222 | Interacting With the Legacy GPIO Subsystem |
| 223 | ========================================== |
| 224 | Many kernel subsystems still handle GPIOs using the legacy integer-based |
| 225 | interface. Although it is strongly encouraged to upgrade them to the safer |
| 226 | descriptor-based API, the following two functions allow you to convert a GPIO |
| 227 | descriptor into the GPIO integer namespace and vice-versa: |
| 228 | |
| 229 | int desc_to_gpio(const struct gpio_desc *desc) |
| 230 | struct gpio_desc *gpio_to_desc(unsigned gpio) |
| 231 | |
| 232 | The GPIO number returned by desc_to_gpio() can be safely used as long as the |
| 233 | GPIO descriptor has not been freed. All the same, a GPIO number passed to |
| 234 | gpio_to_desc() must have been properly acquired, and usage of the returned GPIO |
| 235 | descriptor is only possible after the GPIO number has been released. |
| 236 | |
| 237 | Freeing a GPIO obtained by one API with the other API is forbidden and an |
| 238 | unchecked error. |