mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-21 18:07:21 +07:00
adbf02998b
Update a slew of documentation files with the latest changes in the API/ABI. Again stress that sysfs is deprecated. Add all new flags and clean up and move some text. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
439 lines
18 KiB
Plaintext
439 lines
18 KiB
Plaintext
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/gpio/board.txt
|
|
|
|
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.
|