| ================================== |
| GPIO Descriptor Consumer Interface |
| ================================== |
| |
| This document describes the consumer interface of the GPIO framework. Note that |
| it describes the new descriptor-based interface. For a description of the |
| deprecated integer-based GPIO interface please refer to gpio-legacy.txt. |
| |
| |
| Guidelines for GPIOs consumers |
| ============================== |
| |
| Drivers that can't work without standard GPIO calls should have Kconfig entries |
| that depend on GPIOLIB or select GPIOLIB. The functions that allow a driver to |
| obtain and use GPIOs are available by including the following file: |
| |
| #include <linux/gpio/consumer.h> |
| |
| There are static inline stubs for all functions in the header file in the case |
| where GPIOLIB is disabled. When these stubs are called they will emit |
| warnings. These stubs are used for two use cases: |
| |
| - Simple compile coverage with e.g. COMPILE_TEST - it does not matter that |
| the current platform does not enable or select GPIOLIB because we are not |
| going to execute the system anyway. |
| |
| - Truly optional GPIOLIB support - where the driver does not really make use |
| of the GPIOs on certain compile-time configurations for certain systems, but |
| will use it under other compile-time configurations. In this case the |
| consumer must make sure not to call into these functions, or the user will |
| be met with console warnings that may be perceived as intimidating. |
| |
| All the functions that work with the descriptor-based GPIO interface are |
| prefixed with ``gpiod_``. The ``gpio_`` prefix is used for the legacy |
| interface. No other function in the kernel should use these prefixes. The use |
| of the legacy functions is strongly discouraged, new code should use |
| <linux/gpio/consumer.h> and descriptors exclusively. |
| |
| |
| Obtaining and Disposing GPIOs |
| ============================= |
| |
| With the descriptor-based interface, GPIOs are identified with an opaque, |
| non-forgeable handler that must be obtained through a call to one of the |
| gpiod_get() functions. Like many other kernel subsystems, gpiod_get() takes the |
| device that will use the GPIO and the function the requested GPIO is supposed to |
| fulfill:: |
| |
| struct gpio_desc *gpiod_get(struct device *dev, const char *con_id, |
| enum gpiod_flags flags) |
| |
| If a function is implemented by using several GPIOs together (e.g. a simple LED |
| device that displays digits), an additional index argument can be specified:: |
| |
| struct gpio_desc *gpiod_get_index(struct device *dev, |
| const char *con_id, unsigned int idx, |
| enum gpiod_flags flags) |
| |
| For a more detailed description of the con_id parameter in the DeviceTree case |
| see Documentation/driver-api/gpio/board.rst |
| |
| The flags parameter is used to optionally specify a direction and initial value |
| for the GPIO. Values can be: |
| |
| * GPIOD_ASIS or 0 to not initialize the GPIO at all. The direction must be set |
| later with one of the dedicated functions. |
| * GPIOD_IN to initialize the GPIO as input. |
| * GPIOD_OUT_LOW to initialize the GPIO as output with a value of 0. |
| * GPIOD_OUT_HIGH to initialize the GPIO as output with a value of 1. |
| * GPIOD_OUT_LOW_OPEN_DRAIN same as GPIOD_OUT_LOW but also enforce the line |
| to be electrically used with open drain. |
| * GPIOD_OUT_HIGH_OPEN_DRAIN same as GPIOD_OUT_HIGH but also enforce the line |
| to be electrically used with open drain. |
| |
| The two last flags are used for use cases where open drain is mandatory, such |
| as I2C: if the line is not already configured as open drain in the mappings |
| (see board.txt), then open drain will be enforced anyway and a warning will be |
| printed that the board configuration needs to be updated to match the use case. |
| |
| Both functions return either a valid GPIO descriptor, or an error code checkable |
| with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned |
| if and only if no GPIO has been assigned to the device/function/index triplet, |
| other error codes are used for cases where a GPIO has been assigned but an error |
| occurred while trying to acquire it. This is useful to discriminate between mere |
| errors and an absence of GPIO for optional GPIO parameters. For the common |
| pattern where a GPIO is optional, the gpiod_get_optional() and |
| gpiod_get_index_optional() functions can be used. These functions return NULL |
| instead of -ENOENT if no GPIO has been assigned to the requested function:: |
| |
| struct gpio_desc *gpiod_get_optional(struct device *dev, |
| const char *con_id, |
| enum gpiod_flags flags) |
| |
| struct gpio_desc *gpiod_get_index_optional(struct device *dev, |
| const char *con_id, |
| unsigned int index, |
| enum gpiod_flags flags) |
| |
| Note that gpio_get*_optional() functions (and their managed variants), unlike |
| the rest of gpiolib API, also return NULL when gpiolib support is disabled. |
| This is helpful to driver authors, since they do not need to special case |
| -ENOSYS return codes. System integrators should however be careful to enable |
| gpiolib on systems that need it. |
| |
| For a function using multiple GPIOs all of those can be obtained with one call:: |
| |
| struct gpio_descs *gpiod_get_array(struct device *dev, |
| const char *con_id, |
| enum gpiod_flags flags) |
| |
| This function returns a struct gpio_descs which contains an array of |
| descriptors:: |
| |
| struct gpio_descs { |
| unsigned int ndescs; |
| struct gpio_desc *desc[]; |
| } |
| |
| The following function returns NULL instead of -ENOENT if no GPIOs have been |
| assigned to the requested function:: |
| |
| struct gpio_descs *gpiod_get_array_optional(struct device *dev, |
| const char *con_id, |
| enum gpiod_flags flags) |
| |
| Device-managed variants of these functions are also defined:: |
| |
| struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id, |
| enum gpiod_flags flags) |
| |
| struct gpio_desc *devm_gpiod_get_index(struct device *dev, |
| const char *con_id, |
| unsigned int idx, |
| enum gpiod_flags flags) |
| |
| struct gpio_desc *devm_gpiod_get_optional(struct device *dev, |
| const char *con_id, |
| enum gpiod_flags flags) |
| |
| struct gpio_desc *devm_gpiod_get_index_optional(struct device *dev, |
| const char *con_id, |
| unsigned int index, |
| enum gpiod_flags flags) |
| |
| struct gpio_descs *devm_gpiod_get_array(struct device *dev, |
| const char *con_id, |
| enum gpiod_flags flags) |
| |
| struct gpio_descs *devm_gpiod_get_array_optional(struct device *dev, |
| const char *con_id, |
| enum gpiod_flags flags) |
| |
| A GPIO descriptor can be disposed of using the gpiod_put() function:: |
| |
| void gpiod_put(struct gpio_desc *desc) |
| |
| For an array of GPIOs this function can be used:: |
| |
| void gpiod_put_array(struct gpio_descs *descs) |
| |
| It is strictly forbidden to use a descriptor after calling these functions. |
| It is also not allowed to individually release descriptors (using gpiod_put()) |
| from an array acquired with gpiod_get_array(). |
| |
| The device-managed variants are, unsurprisingly:: |
| |
| void devm_gpiod_put(struct device *dev, struct gpio_desc *desc) |
| |
| void devm_gpiod_put_array(struct device *dev, struct gpio_descs *descs) |
| |
| |
| Using GPIOs |
| =========== |
| |
| Setting Direction |
| ----------------- |
| The first thing a driver must do with a GPIO is setting its direction. If no |
| direction-setting flags have been given to gpiod_get*(), this is done by |
| invoking one of the gpiod_direction_*() functions:: |
| |
| int gpiod_direction_input(struct gpio_desc *desc) |
| int gpiod_direction_output(struct gpio_desc *desc, int value) |
| |
| The return value is zero for success, else a negative errno. It should be |
| checked, since the get/set calls don't return errors and since misconfiguration |
| is possible. You should normally issue these calls from a task context. However, |
| for spinlock-safe GPIOs it is OK to use them before tasking is enabled, as part |
| of early board setup. |
| |
| For output GPIOs, the value provided becomes the initial output value. This |
| helps avoid signal glitching during system startup. |
| |
| A driver can also query the current direction of a GPIO:: |
| |
| int gpiod_get_direction(const struct gpio_desc *desc) |
| |
| This function returns 0 for output, 1 for input, or an error code in case of error. |
| |
| Be aware that there is no default direction for GPIOs. Therefore, **using a GPIO |
| without setting its direction first is illegal and will result in undefined |
| behavior!** |
| |
| |
| Spinlock-Safe GPIO Access |
| ------------------------- |
| Most GPIO controllers can be accessed with memory read/write instructions. Those |
| don't need to sleep, and can safely be done from inside hard (non-threaded) IRQ |
| handlers and similar contexts. |
| |
| Use the following calls to access GPIOs from an atomic context:: |
| |
| int gpiod_get_value(const struct gpio_desc *desc); |
| void gpiod_set_value(struct gpio_desc *desc, int value); |
| |
| The values are boolean, zero for low, nonzero for high. When reading the value |
| of an output pin, the value returned should be what's seen on the pin. That |
| won't always match the specified output value, because of issues including |
| open-drain signaling and output latencies. |
| |
| The get/set calls do not return errors because "invalid GPIO" should have been |
| reported earlier from gpiod_direction_*(). However, note that not all platforms |
| can read the value of output pins; those that can't should always return zero. |
| Also, using these calls for GPIOs that can't safely be accessed without sleeping |
| (see below) is an error. |
| |
| |
| GPIO Access That May Sleep |
| -------------------------- |
| Some GPIO controllers must be accessed using message based buses like I2C or |
| SPI. Commands to read or write those GPIO values require waiting to get to the |
| head of a queue to transmit a command and get its response. This requires |
| sleeping, which can't be done from inside IRQ handlers. |
| |
| Platforms that support this type of GPIO distinguish them from other GPIOs by |
| returning nonzero from this call:: |
| |
| int gpiod_cansleep(const struct gpio_desc *desc) |
| |
| To access such GPIOs, a different set of accessors is defined:: |
| |
| int gpiod_get_value_cansleep(const struct gpio_desc *desc) |
| void gpiod_set_value_cansleep(struct gpio_desc *desc, int value) |
| |
| Accessing such GPIOs requires a context which may sleep, for example a threaded |
| IRQ handler, and those accessors must be used instead of spinlock-safe |
| accessors without the cansleep() name suffix. |
| |
| Other than the fact that these accessors might sleep, and will work on GPIOs |
| that can't be accessed from hardIRQ handlers, these calls act the same as the |
| spinlock-safe calls. |
| |
| |
| The active low and open drain semantics |
| --------------------------------------- |
| As a consumer should not have to care about the physical line level, all of the |
| gpiod_set_value_xxx() or gpiod_set_array_value_xxx() functions operate with |
| the *logical* value. With this they take the active low property into account. |
| This means that they check whether the GPIO is configured to be active low, |
| and if so, they manipulate the passed value before the physical line level is |
| driven. |
| |
| The same is applicable for open drain or open source output lines: those do not |
| actively drive their output high (open drain) or low (open source), they just |
| switch their output to a high impedance value. The consumer should not need to |
| care. (For details read about open drain in driver.txt.) |
| |
| With this, all the gpiod_set_(array)_value_xxx() functions interpret the |
| parameter "value" as "asserted" ("1") or "de-asserted" ("0"). The physical line |
| level will be driven accordingly. |
| |
| As an example, if the active low property for a dedicated GPIO is set, and the |
| gpiod_set_(array)_value_xxx() passes "asserted" ("1"), the physical line level |
| will be driven low. |
| |
| To summarize:: |
| |
| Function (example) line property physical line |
| gpiod_set_raw_value(desc, 0); don't care low |
| gpiod_set_raw_value(desc, 1); don't care high |
| gpiod_set_value(desc, 0); default (active high) low |
| gpiod_set_value(desc, 1); default (active high) high |
| gpiod_set_value(desc, 0); active low high |
| gpiod_set_value(desc, 1); active low low |
| gpiod_set_value(desc, 0); default (active high) low |
| gpiod_set_value(desc, 1); default (active high) high |
| gpiod_set_value(desc, 0); open drain low |
| gpiod_set_value(desc, 1); open drain high impedance |
| gpiod_set_value(desc, 0); open source high impedance |
| gpiod_set_value(desc, 1); open source high |
| |
| It is possible to override these semantics using the set_raw/get_raw functions |
| but it should be avoided as much as possible, especially by system-agnostic drivers |
| which should not need to care about the actual physical line level and worry about |
| the logical value instead. |
| |
| |
| Accessing raw GPIO values |
| ------------------------- |
| Consumers exist that need to manage the logical state of a GPIO line, i.e. the value |
| their device will actually receive, no matter what lies between it and the GPIO |
| line. |
| |
| The following set of calls ignore the active-low or open drain property of a GPIO and |
| work on the raw line value:: |
| |
| int gpiod_get_raw_value(const struct gpio_desc *desc) |
| void gpiod_set_raw_value(struct gpio_desc *desc, int value) |
| int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc) |
| void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value) |
| int gpiod_direction_output_raw(struct gpio_desc *desc, int value) |
| |
| The active low state of a GPIO can also be queried using the following call:: |
| |
| int gpiod_is_active_low(const struct gpio_desc *desc) |
| |
| Note that these functions should only be used with great moderation; a driver |
| should not have to care about the physical line level or open drain semantics. |
| |
| |
| Access multiple GPIOs with a single function call |
| ------------------------------------------------- |
| The following functions get or set the values of an array of GPIOs:: |
| |
| int gpiod_get_array_value(unsigned int array_size, |
| struct gpio_desc **desc_array, |
| int *value_array); |
| int gpiod_get_raw_array_value(unsigned int array_size, |
| struct gpio_desc **desc_array, |
| int *value_array); |
| int gpiod_get_array_value_cansleep(unsigned int array_size, |
| struct gpio_desc **desc_array, |
| int *value_array); |
| int gpiod_get_raw_array_value_cansleep(unsigned int array_size, |
| struct gpio_desc **desc_array, |
| int *value_array); |
| |
| void gpiod_set_array_value(unsigned int array_size, |
| struct gpio_desc **desc_array, |
| int *value_array) |
| void gpiod_set_raw_array_value(unsigned int array_size, |
| struct gpio_desc **desc_array, |
| int *value_array) |
| void gpiod_set_array_value_cansleep(unsigned int array_size, |
| struct gpio_desc **desc_array, |
| int *value_array) |
| void gpiod_set_raw_array_value_cansleep(unsigned int array_size, |
| struct gpio_desc **desc_array, |
| int *value_array) |
| |
| The array can be an arbitrary set of GPIOs. The functions will try to access |
| GPIOs belonging to the same bank or chip simultaneously if supported by the |
| corresponding chip driver. In that case a significantly improved performance |
| can be expected. If simultaneous access is not possible the GPIOs will be |
| accessed sequentially. |
| |
| The functions take three arguments: |
| * array_size - the number of array elements |
| * desc_array - an array of GPIO descriptors |
| * value_array - an array to store the GPIOs' values (get) or |
| an array of values to assign to the GPIOs (set) |
| |
| The descriptor array can be obtained using the gpiod_get_array() function |
| or one of its variants. If the group of descriptors returned by that function |
| matches the desired group of GPIOs, those GPIOs can be accessed by simply using |
| the struct gpio_descs returned by gpiod_get_array():: |
| |
| struct gpio_descs *my_gpio_descs = gpiod_get_array(...); |
| gpiod_set_array_value(my_gpio_descs->ndescs, my_gpio_descs->desc, |
| my_gpio_values); |
| |
| It is also possible to access a completely arbitrary array of descriptors. The |
| descriptors may be obtained using any combination of gpiod_get() and |
| gpiod_get_array(). Afterwards the array of descriptors has to be setup |
| manually before it can be passed to one of the above functions. |
| |
| Note that for optimal performance GPIOs belonging to the same chip should be |
| contiguous within the array of descriptors. |
| |
| The return value of gpiod_get_array_value() and its variants is 0 on success |
| or negative on error. Note the difference to gpiod_get_value(), which returns |
| 0 or 1 on success to convey the GPIO value. With the array functions, the GPIO |
| values are stored in value_array rather than passed back as return value. |
| |
| |
| GPIOs mapped to IRQs |
| -------------------- |
| GPIO lines can quite often be used as IRQs. You can get the IRQ number |
| corresponding to a given GPIO using the following call:: |
| |
| int gpiod_to_irq(const struct gpio_desc *desc) |
| |
| It will return an IRQ number, or a negative errno code if the mapping can't be |
| done (most likely because that particular GPIO cannot be used as IRQ). It is an |
| unchecked error to use a GPIO that wasn't set up as an input using |
| gpiod_direction_input(), or to use an IRQ number that didn't originally come |
| from gpiod_to_irq(). gpiod_to_irq() is not allowed to sleep. |
| |
| Non-error values returned from gpiod_to_irq() can be passed to request_irq() or |
| free_irq(). They will often be stored into IRQ resources for platform devices, |
| by the board-specific initialization code. Note that IRQ trigger options are |
| part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are system wakeup |
| capabilities. |
| |
| |
| GPIOs and ACPI |
| ============== |
| |
| On ACPI systems, GPIOs are described by GpioIo()/GpioInt() resources listed by |
| the _CRS configuration objects of devices. Those resources do not provide |
| connection IDs (names) for GPIOs, so it is necessary to use an additional |
| mechanism for this purpose. |
| |
| Systems compliant with ACPI 5.1 or newer may provide a _DSD configuration object |
| which, among other things, may be used to provide connection IDs for specific |
| GPIOs described by the GpioIo()/GpioInt() resources in _CRS. If that is the |
| case, it will be handled by the GPIO subsystem automatically. However, if the |
| _DSD is not present, the mappings between GpioIo()/GpioInt() resources and GPIO |
| connection IDs need to be provided by device drivers. |
| |
| For details refer to Documentation/acpi/gpio-properties.txt |
| |
| |
| Interacting With the Legacy GPIO Subsystem |
| ========================================== |
| Many kernel subsystems still handle GPIOs using the legacy integer-based |
| interface. Although it is strongly encouraged to upgrade them to the safer |
| descriptor-based API, the following two functions allow you to convert a GPIO |
| descriptor into the GPIO integer namespace and vice-versa:: |
| |
| int desc_to_gpio(const struct gpio_desc *desc) |
| struct gpio_desc *gpio_to_desc(unsigned gpio) |
| |
| The GPIO number returned by desc_to_gpio() can be safely used as long as the |
| GPIO descriptor has not been freed. All the same, a GPIO number passed to |
| gpio_to_desc() must have been properly acquired, and usage of the returned GPIO |
| descriptor is only possible after the GPIO number has been released. |
| |
| Freeing a GPIO obtained by one API with the other API is forbidden and an |
| unchecked error. |