driver-api/gpio/consumer.rst

8 Guidelines for GPIOs consumers
13 obtain and use GPIOs are available by including the following file::
21 - Simple compile coverage with e.g. COMPILE_TEST - it does not matter that
25 - Truly optional GPIOLIB support - where the driver does not really make use
26   of the GPIOs on certain compile-time configurations for certain systems, but
27   will use it under other compile-time configurations. In this case the
35 All the functions that work with the descriptor-based GPIO interface are
42 Obtaining and Disposing GPIOs
45 With the descriptor-based interface, GPIOs are identified with an opaque,
46 non-forgeable handler that must be obtained through a call to one of the
54 If a function is implemented by using several GPIOs together (e.g. a simple LED
62 see Documentation/driver-api/gpio/board.rst
87 with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned
94 instead of -ENOENT if no GPIO has been assigned to the requested function::
108 -ENOSYS return codes.  System integrators should however be careful to enable
111 For a function using multiple GPIOs all of those can be obtained with one call::
127 The following function returns NULL instead of -ENOENT if no GPIOs have been
134 Device-managed variants of these functions are also defined::
165 For an array of GPIOs this function can be used::
173 The device-managed variants are, unsurprisingly::
180 Using GPIOs
184 -----------------
186 direction-setting flags have been given to gpiod_get*(), this is done by
195 for spinlock-safe GPIOs it is OK to use them before tasking is enabled, as part
198 For output GPIOs, the value provided becomes the initial output value. This
207 Be aware that there is no default direction for GPIOs. Therefore, **using a GPIO
212 Spinlock-Safe GPIO Access
213 -------------------------
215 don't need to sleep, and can safely be done from inside hard (non-threaded) IRQ
218 Use the following calls to access GPIOs from an atomic context::
226 open-drain signaling and output latencies.
231 Also, using these calls for GPIOs that can't safely be accessed without sleeping
236 --------------------------
240 sleeping, which can't be done from inside IRQ handlers.
242 Platforms that support this type of GPIO distinguish them from other GPIOs by
247 To access such GPIOs, a different set of accessors is defined::
252 Accessing such GPIOs requires a context which may sleep, for example a threaded
253 IRQ handler, and those accessors must be used instead of spinlock-safe
256 Other than the fact that these accessors might sleep, and will work on GPIOs
258 spinlock-safe calls.
264 ---------------------------------------
300 but it should be avoided as much as possible, especially by system-agnostic drivers
306 -------------------------
311 The following set of calls ignore the active-low or open drain property of a GPIO and
330 Access multiple GPIOs with a single function call
331 -------------------------------------------------
332 The following functions get or set the values of an array of GPIOs::
368 The array can be an arbitrary set of GPIOs. The functions will try to access
369 GPIOs belonging to the same bank or chip simultaneously if supported by the
371 can be expected. If simultaneous access is not possible the GPIOs will be
376 	* array_size	- the number of array elements
377 	* desc_array	- an array of GPIO descriptors
378 	* array_info	- optional information obtained from gpiod_get_array()
379 	* value_bitmap	- a bitmap to store the GPIOs' values (get) or
380           a bitmap of values to assign to the GPIOs (set)
384 matches the desired group of GPIOs, those GPIOs can be accessed by simply using
388 	gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc,
389 			      my_gpio_descs->info, my_gpio_value_bitmap);
397 Note that for optimal performance GPIOs belonging to the same chip should be
414 GPIOs mapped to IRQs
415 --------------------
416 GPIO lines can quite often be used as IRQs. You can get the IRQ number
421 It will return an IRQ number, or a negative errno code if the mapping can't be
422 done (most likely because that particular GPIO cannot be used as IRQ). It is an
424 gpiod_direction_input(), or to use an IRQ number that didn't originally come
427 Non-error values returned from gpiod_to_irq() can be passed to request_irq() or
428 free_irq(). They will often be stored into IRQ resources for platform devices,
429 by the board-specific initialization code. Note that IRQ trigger options are
430 part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are system wakeup
434 GPIOs and ACPI
437 On ACPI systems, GPIOs are described by GpioIo()/GpioInt() resources listed by
439 connection IDs (names) for GPIOs, so it is necessary to use an additional
444 GPIOs described by the GpioIo()/GpioInt() resources in _CRS.  If that is the
449 For details refer to Documentation/firmware-guide/acpi/gpio-properties.rst
454 Many kernel subsystems and drivers still handle GPIOs using the legacy
455 integer-based interface. It is strongly recommended to update these to the new
458 and vice-versa::