driver-api/gpio/consumer.rst

6 it describes the new descriptor-based interface. For a description of the
7 deprecated integer-based GPIO interface please refer to gpio-legacy.txt.
10 Guidelines for GPIOs consumers
15 obtain and use GPIOs are available by including the following file:
23 - Simple compile coverage with e.g. COMPILE_TEST - it does not matter that
27 - Truly optional GPIOLIB support - where the driver does not really make use
28   of the GPIOs on certain compile-time configurations for certain systems, but
29   will use it under other compile-time configurations. In this case the
33 All the functions that work with the descriptor-based GPIO interface are
40 Obtaining and Disposing GPIOs
43 With the descriptor-based interface, GPIOs are identified with an opaque,
44 non-forgeable handler that must be obtained through a call to one of the
52 If a function is implemented by using several GPIOs together (e.g. a simple LED
60 see Documentation/driver-api/gpio/board.rst
81 with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned
88 instead of -ENOENT if no GPIO has been assigned to the requested function::
102 -ENOSYS return codes.  System integrators should however be careful to enable
105 For a function using multiple GPIOs all of those can be obtained with one call::
121 The following function returns NULL instead of -ENOENT if no GPIOs have been
128 Device-managed variants of these functions are also defined::
159 For an array of GPIOs this function can be used::
167 The device-managed variants are, unsurprisingly::
174 Using GPIOs
178 -----------------
180 direction-setting flags have been given to gpiod_get*(), this is done by
189 for spinlock-safe GPIOs it is OK to use them before tasking is enabled, as part
192 For output GPIOs, the value provided becomes the initial output value. This
201 Be aware that there is no default direction for GPIOs. Therefore, **using a GPIO
206 Spinlock-Safe GPIO Access
207 -------------------------
209 don't need to sleep, and can safely be done from inside hard (non-threaded) IRQ
212 Use the following calls to access GPIOs from an atomic context::
220 open-drain signaling and output latencies.
225 Also, using these calls for GPIOs that can't safely be accessed without sleeping
230 --------------------------
234 sleeping, which can't be done from inside IRQ handlers.
236 Platforms that support this type of GPIO distinguish them from other GPIOs by
241 To access such GPIOs, a different set of accessors is defined::
246 Accessing such GPIOs requires a context which may sleep, for example a threaded
247 IRQ handler, and those accessors must be used instead of spinlock-safe
250 Other than the fact that these accessors might sleep, and will work on GPIOs
252 spinlock-safe calls.
256 ---------------------------------------
270 parameter "value" as "asserted" ("1") or "de-asserted" ("0"). The physical line
292 but it should be avoided as much as possible, especially by system-agnostic drivers
298 -------------------------
303 The following set of calls ignore the active-low or open drain property of a GPIO and
320 Access multiple GPIOs with a single function call
321 -------------------------------------------------
322 The following functions get or set the values of an array of GPIOs::
358 The array can be an arbitrary set of GPIOs. The functions will try to access
359 GPIOs belonging to the same bank or chip simultaneously if supported by the
361 can be expected. If simultaneous access is not possible the GPIOs will be
365 	* array_size	- the number of array elements
366 	* desc_array	- an array of GPIO descriptors
367 	* array_info	- optional information obtained from gpiod_get_array()
368 	* value_bitmap	- a bitmap to store the GPIOs' values (get) or
369 			  a bitmap of values to assign to the GPIOs (set)
373 matches the desired group of GPIOs, those GPIOs can be accessed by simply using
377 	gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc,
378 			      my_gpio_descs->info, my_gpio_value_bitmap);
386 Note that for optimal performance GPIOs belonging to the same chip should be
403 GPIOs mapped to IRQs
404 --------------------
405 GPIO lines can quite often be used as IRQs. You can get the IRQ number
410 It will return an IRQ number, or a negative errno code if the mapping can't be
411 done (most likely because that particular GPIO cannot be used as IRQ). It is an
413 gpiod_direction_input(), or to use an IRQ number that didn't originally come
416 Non-error values returned from gpiod_to_irq() can be passed to request_irq() or
417 free_irq(). They will often be stored into IRQ resources for platform devices,
418 by the board-specific initialization code. Note that IRQ trigger options are
419 part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are system wakeup
423 GPIOs and ACPI
426 On ACPI systems, GPIOs are described by GpioIo()/GpioInt() resources listed by
428 connection IDs (names) for GPIOs, so it is necessary to use an additional
433 GPIOs described by the GpioIo()/GpioInt() resources in _CRS.  If that is the
438 For details refer to Documentation/firmware-guide/acpi/gpio-properties.rst
443 Many kernel subsystems still handle GPIOs using the legacy integer-based
445 descriptor-based API, the following two functions allow you to convert a GPIO
446 descriptor into the GPIO integer namespace and vice-versa::