]>
Commit | Line | Data |
---|---|---|
fd8e198c AC |
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 | |
a621c99a LW |
13 | that depend on GPIOLIB or select GPIOLIB. The functions that allow a driver to |
14 | obtain and use GPIOs are available by including the following file: | |
fd8e198c AC |
15 | |
16 | #include <linux/gpio/consumer.h> | |
17 | ||
a621c99a LW |
18 | There are static inline stubs for all functions in the header file in the case |
19 | where GPIOLIB is disabled. When these stubs are called they will emit | |
20 | warnings. These stubs are used for two use cases: | |
21 | ||
22 | - Simple compile coverage with e.g. COMPILE_TEST - it does not matter that | |
23 | the current platform does not enable or select GPIOLIB because we are not | |
24 | going to execute the system anyway. | |
25 | ||
26 | - Truly optional GPIOLIB support - where the driver does not really make use | |
27 | of the GPIOs on certain compile-time configurations for certain systems, but | |
28 | will use it under other compile-time configurations. In this case the | |
29 | consumer must make sure not to call into these functions, or the user will | |
30 | be met with console warnings that may be perceived as intimidating. | |
31 | ||
fd8e198c AC |
32 | All the functions that work with the descriptor-based GPIO interface are |
33 | prefixed with gpiod_. The gpio_ prefix is used for the legacy interface. No | |
a621c99a LW |
34 | other function in the kernel should use these prefixes. The use of the legacy |
35 | functions is strongly discouraged, new code should use <linux/gpio/consumer.h> | |
36 | and descriptors exclusively. | |
fd8e198c AC |
37 | |
38 | ||
39 | Obtaining and Disposing GPIOs | |
40 | ============================= | |
41 | ||
42 | With the descriptor-based interface, GPIOs are identified with an opaque, | |
43 | non-forgeable handler that must be obtained through a call to one of the | |
44 | gpiod_get() functions. Like many other kernel subsystems, gpiod_get() takes the | |
45 | device that will use the GPIO and the function the requested GPIO is supposed to | |
46 | fulfill: | |
47 | ||
39b2bbe3 AC |
48 | struct gpio_desc *gpiod_get(struct device *dev, const char *con_id, |
49 | enum gpiod_flags flags) | |
fd8e198c AC |
50 | |
51 | If a function is implemented by using several GPIOs together (e.g. a simple LED | |
52 | device that displays digits), an additional index argument can be specified: | |
53 | ||
54 | struct gpio_desc *gpiod_get_index(struct device *dev, | |
39b2bbe3 AC |
55 | const char *con_id, unsigned int idx, |
56 | enum gpiod_flags flags) | |
57 | ||
87e77e46 DB |
58 | For a more detailed description of the con_id parameter in the DeviceTree case |
59 | see Documentation/gpio/board.txt | |
60 | ||
39b2bbe3 AC |
61 | The flags parameter is used to optionally specify a direction and initial value |
62 | for the GPIO. Values can be: | |
63 | ||
64 | * GPIOD_ASIS or 0 to not initialize the GPIO at all. The direction must be set | |
65 | later with one of the dedicated functions. | |
66 | * GPIOD_IN to initialize the GPIO as input. | |
67 | * GPIOD_OUT_LOW to initialize the GPIO as output with a value of 0. | |
68 | * GPIOD_OUT_HIGH to initialize the GPIO as output with a value of 1. | |
fd8e198c AC |
69 | |
70 | Both functions return either a valid GPIO descriptor, or an error code checkable | |
2a3cf6a3 AC |
71 | with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned |
72 | if and only if no GPIO has been assigned to the device/function/index triplet, | |
73 | other error codes are used for cases where a GPIO has been assigned but an error | |
c98be0c9 | 74 | occurred while trying to acquire it. This is useful to discriminate between mere |
1b11a9b9 AC |
75 | errors and an absence of GPIO for optional GPIO parameters. For the common |
76 | pattern where a GPIO is optional, the gpiod_get_optional() and | |
77 | gpiod_get_index_optional() functions can be used. These functions return NULL | |
78 | instead of -ENOENT if no GPIO has been assigned to the requested function: | |
79 | ||
1b11a9b9 AC |
80 | struct gpio_desc *gpiod_get_optional(struct device *dev, |
81 | const char *con_id, | |
82 | enum gpiod_flags flags) | |
83 | ||
84 | struct gpio_desc *gpiod_get_index_optional(struct device *dev, | |
85 | const char *con_id, | |
86 | unsigned int index, | |
87 | enum gpiod_flags flags) | |
fd8e198c | 88 | |
22c40367 DT |
89 | Note that gpio_get*_optional() functions (and their managed variants), unlike |
90 | the rest of gpiolib API, also return NULL when gpiolib support is disabled. | |
91 | This is helpful to driver authors, since they do not need to special case | |
92 | -ENOSYS return codes. System integrators should however be careful to enable | |
93 | gpiolib on systems that need it. | |
94 | ||
66858527 RI |
95 | For a function using multiple GPIOs all of those can be obtained with one call: |
96 | ||
97 | struct gpio_descs *gpiod_get_array(struct device *dev, | |
98 | const char *con_id, | |
99 | enum gpiod_flags flags) | |
100 | ||
101 | This function returns a struct gpio_descs which contains an array of | |
102 | descriptors: | |
103 | ||
104 | struct gpio_descs { | |
105 | unsigned int ndescs; | |
106 | struct gpio_desc *desc[]; | |
107 | } | |
108 | ||
109 | The following function returns NULL instead of -ENOENT if no GPIOs have been | |
110 | assigned to the requested function: | |
111 | ||
112 | struct gpio_descs *gpiod_get_array_optional(struct device *dev, | |
113 | const char *con_id, | |
114 | enum gpiod_flags flags) | |
115 | ||
fd8e198c AC |
116 | Device-managed variants of these functions are also defined: |
117 | ||
39b2bbe3 AC |
118 | struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id, |
119 | enum gpiod_flags flags) | |
fd8e198c AC |
120 | |
121 | struct gpio_desc *devm_gpiod_get_index(struct device *dev, | |
122 | const char *con_id, | |
39b2bbe3 AC |
123 | unsigned int idx, |
124 | enum gpiod_flags flags) | |
fd8e198c | 125 | |
1b11a9b9 AC |
126 | struct gpio_desc *devm_gpiod_get_optional(struct device *dev, |
127 | const char *con_id, | |
128 | enum gpiod_flags flags) | |
129 | ||
331758ee | 130 | struct gpio_desc *devm_gpiod_get_index_optional(struct device *dev, |
1b11a9b9 AC |
131 | const char *con_id, |
132 | unsigned int index, | |
133 | enum gpiod_flags flags) | |
134 | ||
331758ee RI |
135 | struct gpio_descs *devm_gpiod_get_array(struct device *dev, |
136 | const char *con_id, | |
137 | enum gpiod_flags flags) | |
138 | ||
139 | struct gpio_descs *devm_gpiod_get_array_optional(struct device *dev, | |
140 | const char *con_id, | |
141 | enum gpiod_flags flags) | |
142 | ||
fd8e198c AC |
143 | A GPIO descriptor can be disposed of using the gpiod_put() function: |
144 | ||
145 | void gpiod_put(struct gpio_desc *desc) | |
146 | ||
66858527 RI |
147 | For an array of GPIOs this function can be used: |
148 | ||
149 | void gpiod_put_array(struct gpio_descs *descs) | |
150 | ||
151 | It is strictly forbidden to use a descriptor after calling these functions. | |
152 | It is also not allowed to individually release descriptors (using gpiod_put()) | |
153 | from an array acquired with gpiod_get_array(). | |
154 | ||
331758ee | 155 | The device-managed variants are, unsurprisingly: |
fd8e198c AC |
156 | |
157 | void devm_gpiod_put(struct device *dev, struct gpio_desc *desc) | |
158 | ||
331758ee RI |
159 | void devm_gpiod_put_array(struct device *dev, struct gpio_descs *descs) |
160 | ||
fd8e198c AC |
161 | |
162 | Using GPIOs | |
163 | =========== | |
164 | ||
165 | Setting Direction | |
166 | ----------------- | |
39b2bbe3 AC |
167 | The first thing a driver must do with a GPIO is setting its direction. If no |
168 | direction-setting flags have been given to gpiod_get*(), this is done by | |
169 | invoking one of the gpiod_direction_*() functions: | |
fd8e198c AC |
170 | |
171 | int gpiod_direction_input(struct gpio_desc *desc) | |
172 | int gpiod_direction_output(struct gpio_desc *desc, int value) | |
173 | ||
174 | The return value is zero for success, else a negative errno. It should be | |
175 | checked, since the get/set calls don't return errors and since misconfiguration | |
176 | is possible. You should normally issue these calls from a task context. However, | |
177 | for spinlock-safe GPIOs it is OK to use them before tasking is enabled, as part | |
178 | of early board setup. | |
179 | ||
180 | For output GPIOs, the value provided becomes the initial output value. This | |
181 | helps avoid signal glitching during system startup. | |
182 | ||
183 | A driver can also query the current direction of a GPIO: | |
184 | ||
185 | int gpiod_get_direction(const struct gpio_desc *desc) | |
186 | ||
187 | This function will return either GPIOF_DIR_IN or GPIOF_DIR_OUT. | |
188 | ||
189 | Be aware that there is no default direction for GPIOs. Therefore, **using a GPIO | |
190 | without setting its direction first is illegal and will result in undefined | |
191 | behavior!** | |
192 | ||
193 | ||
194 | Spinlock-Safe GPIO Access | |
195 | ------------------------- | |
196 | Most GPIO controllers can be accessed with memory read/write instructions. Those | |
197 | don't need to sleep, and can safely be done from inside hard (non-threaded) IRQ | |
198 | handlers and similar contexts. | |
199 | ||
200 | Use the following calls to access GPIOs from an atomic context: | |
201 | ||
202 | int gpiod_get_value(const struct gpio_desc *desc); | |
203 | void gpiod_set_value(struct gpio_desc *desc, int value); | |
204 | ||
205 | The values are boolean, zero for low, nonzero for high. When reading the value | |
206 | of an output pin, the value returned should be what's seen on the pin. That | |
207 | won't always match the specified output value, because of issues including | |
208 | open-drain signaling and output latencies. | |
209 | ||
210 | The get/set calls do not return errors because "invalid GPIO" should have been | |
211 | reported earlier from gpiod_direction_*(). However, note that not all platforms | |
212 | can read the value of output pins; those that can't should always return zero. | |
213 | Also, using these calls for GPIOs that can't safely be accessed without sleeping | |
214 | (see below) is an error. | |
215 | ||
216 | ||
217 | GPIO Access That May Sleep | |
218 | -------------------------- | |
219 | Some GPIO controllers must be accessed using message based buses like I2C or | |
220 | SPI. Commands to read or write those GPIO values require waiting to get to the | |
221 | head of a queue to transmit a command and get its response. This requires | |
222 | sleeping, which can't be done from inside IRQ handlers. | |
223 | ||
224 | Platforms that support this type of GPIO distinguish them from other GPIOs by | |
225 | returning nonzero from this call: | |
226 | ||
227 | int gpiod_cansleep(const struct gpio_desc *desc) | |
228 | ||
229 | To access such GPIOs, a different set of accessors is defined: | |
230 | ||
231 | int gpiod_get_value_cansleep(const struct gpio_desc *desc) | |
232 | void gpiod_set_value_cansleep(struct gpio_desc *desc, int value) | |
233 | ||
234 | Accessing such GPIOs requires a context which may sleep, for example a threaded | |
235 | IRQ handler, and those accessors must be used instead of spinlock-safe | |
236 | accessors without the cansleep() name suffix. | |
237 | ||
238 | Other than the fact that these accessors might sleep, and will work on GPIOs | |
239 | that can't be accessed from hardIRQ handlers, these calls act the same as the | |
240 | spinlock-safe calls. | |
241 | ||
242 | ||
243 | Active-low State and Raw GPIO Values | |
244 | ------------------------------------ | |
245 | Device drivers like to manage the logical state of a GPIO, i.e. the value their | |
246 | device will actually receive, no matter what lies between it and the GPIO line. | |
247 | In some cases, it might make sense to control the actual GPIO line value. The | |
248 | following set of calls ignore the active-low property of a GPIO and work on the | |
249 | raw line value: | |
250 | ||
251 | int gpiod_get_raw_value(const struct gpio_desc *desc) | |
252 | void gpiod_set_raw_value(struct gpio_desc *desc, int value) | |
253 | int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc) | |
254 | void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value) | |
ef70bbe1 | 255 | int gpiod_direction_output_raw(struct gpio_desc *desc, int value) |
fd8e198c AC |
256 | |
257 | The active-low state of a GPIO can also be queried using the following call: | |
258 | ||
259 | int gpiod_is_active_low(const struct gpio_desc *desc) | |
260 | ||
261 | Note that these functions should only be used with great moderation ; a driver | |
262 | should not have to care about the physical line level. | |
263 | ||
5f424243 | 264 | |
ac49fbd1 DB |
265 | The active-low property |
266 | ----------------------- | |
267 | ||
268 | As a driver should not have to care about the physical line level, all of the | |
269 | gpiod_set_value_xxx() or gpiod_set_array_value_xxx() functions operate with | |
270 | the *logical* value. With this they take the active-low property into account. | |
271 | This means that they check whether the GPIO is configured to be active-low, | |
272 | and if so, they manipulate the passed value before the physical line level is | |
273 | driven. | |
274 | ||
275 | With this, all the gpiod_set_(array)_value_xxx() functions interpret the | |
276 | parameter "value" as "active" ("1") or "inactive" ("0"). The physical line | |
277 | level will be driven accordingly. | |
278 | ||
279 | As an example, if the active-low property for a dedicated GPIO is set, and the | |
280 | gpiod_set_(array)_value_xxx() passes "active" ("1"), the physical line level | |
281 | will be driven low. | |
282 | ||
283 | To summarize: | |
284 | ||
547d4c10 | 285 | Function (example) active-low property physical line |
ac49fbd1 DB |
286 | gpiod_set_raw_value(desc, 0); don't care low |
287 | gpiod_set_raw_value(desc, 1); don't care high | |
288 | gpiod_set_value(desc, 0); default (active-high) low | |
289 | gpiod_set_value(desc, 1); default (active-high) high | |
290 | gpiod_set_value(desc, 0); active-low high | |
291 | gpiod_set_value(desc, 1); active-low low | |
292 | ||
293 | Please note again that the set_raw/get_raw functions should be avoided as much | |
294 | as possible, especially by drivers which should not care about the actual | |
295 | physical line level and worry about the logical value instead. | |
296 | ||
297 | ||
eec1d566 LW |
298 | Access multiple GPIOs with a single function call |
299 | ------------------------------------------------- | |
300 | The following functions get or set the values of an array of GPIOs: | |
301 | ||
302 | int gpiod_get_array_value(unsigned int array_size, | |
303 | struct gpio_desc **desc_array, | |
304 | int *value_array); | |
305 | int gpiod_get_raw_array_value(unsigned int array_size, | |
306 | struct gpio_desc **desc_array, | |
307 | int *value_array); | |
308 | int gpiod_get_array_value_cansleep(unsigned int array_size, | |
309 | struct gpio_desc **desc_array, | |
310 | int *value_array); | |
311 | int gpiod_get_raw_array_value_cansleep(unsigned int array_size, | |
312 | struct gpio_desc **desc_array, | |
313 | int *value_array); | |
5f424243 | 314 | |
e2bfba41 RI |
315 | void gpiod_set_array_value(unsigned int array_size, |
316 | struct gpio_desc **desc_array, | |
317 | int *value_array) | |
318 | void gpiod_set_raw_array_value(unsigned int array_size, | |
319 | struct gpio_desc **desc_array, | |
320 | int *value_array) | |
321 | void gpiod_set_array_value_cansleep(unsigned int array_size, | |
322 | struct gpio_desc **desc_array, | |
323 | int *value_array) | |
324 | void gpiod_set_raw_array_value_cansleep(unsigned int array_size, | |
325 | struct gpio_desc **desc_array, | |
326 | int *value_array) | |
5f424243 | 327 | |
eec1d566 | 328 | The array can be an arbitrary set of GPIOs. The functions will try to access |
5f424243 RI |
329 | GPIOs belonging to the same bank or chip simultaneously if supported by the |
330 | corresponding chip driver. In that case a significantly improved performance | |
eec1d566 LW |
331 | can be expected. If simultaneous access is not possible the GPIOs will be |
332 | accessed sequentially. | |
de3b6965 | 333 | |
eec1d566 | 334 | The functions take three arguments: |
de3b6965 RI |
335 | * array_size - the number of array elements |
336 | * desc_array - an array of GPIO descriptors | |
eec1d566 LW |
337 | * value_array - an array to store the GPIOs' values (get) or |
338 | an array of values to assign to the GPIOs (set) | |
de3b6965 RI |
339 | |
340 | The descriptor array can be obtained using the gpiod_get_array() function | |
341 | or one of its variants. If the group of descriptors returned by that function | |
eec1d566 | 342 | matches the desired group of GPIOs, those GPIOs can be accessed by simply using |
de3b6965 RI |
343 | the struct gpio_descs returned by gpiod_get_array(): |
344 | ||
345 | struct gpio_descs *my_gpio_descs = gpiod_get_array(...); | |
e2bfba41 RI |
346 | gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc, |
347 | my_gpio_values); | |
de3b6965 | 348 | |
eec1d566 | 349 | It is also possible to access a completely arbitrary array of descriptors. The |
de3b6965 RI |
350 | descriptors may be obtained using any combination of gpiod_get() and |
351 | gpiod_get_array(). Afterwards the array of descriptors has to be setup | |
eec1d566 | 352 | manually before it can be passed to one of the above functions. |
de3b6965 | 353 | |
5f424243 RI |
354 | Note that for optimal performance GPIOs belonging to the same chip should be |
355 | contiguous within the array of descriptors. | |
356 | ||
eec1d566 LW |
357 | The return value of gpiod_get_array_value() and its variants is 0 on success |
358 | or negative on error. Note the difference to gpiod_get_value(), which returns | |
359 | 0 or 1 on success to convey the GPIO value. With the array functions, the GPIO | |
360 | values are stored in value_array rather than passed back as return value. | |
361 | ||
5f424243 | 362 | |
fd8e198c AC |
363 | GPIOs mapped to IRQs |
364 | -------------------- | |
365 | GPIO lines can quite often be used as IRQs. You can get the IRQ number | |
366 | corresponding to a given GPIO using the following call: | |
367 | ||
368 | int gpiod_to_irq(const struct gpio_desc *desc) | |
369 | ||
cbfa2c52 | 370 | It will return an IRQ number, or a negative errno code if the mapping can't be |
fd8e198c AC |
371 | done (most likely because that particular GPIO cannot be used as IRQ). It is an |
372 | unchecked error to use a GPIO that wasn't set up as an input using | |
373 | gpiod_direction_input(), or to use an IRQ number that didn't originally come | |
374 | from gpiod_to_irq(). gpiod_to_irq() is not allowed to sleep. | |
375 | ||
376 | Non-error values returned from gpiod_to_irq() can be passed to request_irq() or | |
377 | free_irq(). They will often be stored into IRQ resources for platform devices, | |
378 | by the board-specific initialization code. Note that IRQ trigger options are | |
379 | part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are system wakeup | |
380 | capabilities. | |
381 | ||
382 | ||
e36d453e RW |
383 | GPIOs and ACPI |
384 | ============== | |
385 | ||
386 | On ACPI systems, GPIOs are described by GpioIo()/GpioInt() resources listed by | |
387 | the _CRS configuration objects of devices. Those resources do not provide | |
388 | connection IDs (names) for GPIOs, so it is necessary to use an additional | |
389 | mechanism for this purpose. | |
390 | ||
391 | Systems compliant with ACPI 5.1 or newer may provide a _DSD configuration object | |
392 | which, among other things, may be used to provide connection IDs for specific | |
393 | GPIOs described by the GpioIo()/GpioInt() resources in _CRS. If that is the | |
394 | case, it will be handled by the GPIO subsystem automatically. However, if the | |
395 | _DSD is not present, the mappings between GpioIo()/GpioInt() resources and GPIO | |
396 | connection IDs need to be provided by device drivers. | |
397 | ||
398 | For details refer to Documentation/acpi/gpio-properties.txt | |
399 | ||
400 | ||
fd8e198c AC |
401 | Interacting With the Legacy GPIO Subsystem |
402 | ========================================== | |
403 | Many kernel subsystems still handle GPIOs using the legacy integer-based | |
404 | interface. Although it is strongly encouraged to upgrade them to the safer | |
405 | descriptor-based API, the following two functions allow you to convert a GPIO | |
406 | descriptor into the GPIO integer namespace and vice-versa: | |
407 | ||
408 | int desc_to_gpio(const struct gpio_desc *desc) | |
409 | struct gpio_desc *gpio_to_desc(unsigned gpio) | |
410 | ||
411 | The GPIO number returned by desc_to_gpio() can be safely used as long as the | |
412 | GPIO descriptor has not been freed. All the same, a GPIO number passed to | |
413 | gpio_to_desc() must have been properly acquired, and usage of the returned GPIO | |
414 | descriptor is only possible after the GPIO number has been released. | |
415 | ||
416 | Freeing a GPIO obtained by one API with the other API is forbidden and an | |
417 | unchecked error. |