Lines Matching +full:in +full:- +full:gpios
8 Guidelines for GPIOs consumers
13 obtain and use GPIOs are available by including the following file::
17 There are static inline stubs for all functions in the header file in the case
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
31 ``[devm_]gpiod_get_optional()`` is a *bad idea*, and will result in weird
35 All the functions that work with the descriptor-based GPIO interface are
37 interface. No other function in the kernel should use these prefixes. The use
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
61 For a more detailed description of the con_id parameter in the DeviceTree case
62 see Documentation/driver-api/gpio/board.rst
82 as I2C: if the line is not already configured as open drain in the mappings
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
205 This function returns 0 for output, 1 for input, or an error code in case of error.
207 Be aware that there is no default direction for GPIOs. Therefore, **using a GPIO
208 without setting its direction first is illegal and will result in undefined
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 --------------------------
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 ---------------------------------------
275 care. (For details read about open drain in driver.rst.)
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
370 corresponding chip driver. In that case a significantly improved performance
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);
394 manually before it can be passed to one of the above functions. In that case,
397 Note that for optimal performance GPIOs belonging to the same chip should be
411 values are stored in value_array rather than passed back as return value.
414 GPIOs mapped to IRQs
415 --------------------
427 Non-error values returned from gpiod_to_irq() can be passed to request_irq() or
429 by the board-specific initialization code. Note that IRQ trigger options are
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::