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