summaryrefslogtreecommitdiff
path: root/Documentation/driver-api/gpio/consumer.rst
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/driver-api/gpio/consumer.rst')
-rw-r--r--Documentation/driver-api/gpio/consumer.rst24
1 files changed, 13 insertions, 11 deletions
diff --git a/Documentation/driver-api/gpio/consumer.rst b/Documentation/driver-api/gpio/consumer.rst
index 47869ca8ccf0..bb3366047fad 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -2,9 +2,7 @@
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.
+This document describes the consumer interface of the GPIO framework.
Guidelines for GPIOs consumers
@@ -29,6 +27,10 @@ warnings. These stubs are used for two use cases:
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.
+ Combining truly optional GPIOLIB usage with calls to
+ ``[devm_]gpiod_get_optional()`` is a *bad idea*, and will result in weird
+ error messages. Use the ordinary getter functions with optional GPIOLIB:
+ some open coding of error handling should be expected when you do this.
All the functions that work with the descriptor-based GPIO interface are
prefixed with ``gpiod_``. The ``gpio_`` prefix is used for the legacy
@@ -78,7 +80,7 @@ whether the line is configured active high or active low (see
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
+(see board.rst), 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
@@ -114,7 +116,7 @@ For a function using multiple GPIOs all of those can be obtained with one call::
This function returns a struct gpio_descs which contains an array of
descriptors. It also contains a pointer to a gpiolib private structure which,
-if passed back to get/set array functions, may speed up I/O proocessing::
+if passed back to get/set array functions, may speed up I/O processing::
struct gpio_descs {
struct gpio_array *info;
@@ -218,9 +220,9 @@ 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
+The values are boolean, zero for inactive, nonzero for active. 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
@@ -270,14 +272,14 @@ 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.)
+care. (For details read about open drain in driver.rst.)
With this, all the gpiod_set_(array)_value_xxx() functions interpret the
-parameter "value" as "asserted" ("1") or "de-asserted" ("0"). The physical line
+parameter "value" as "active" ("1") or "inactive" ("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
+gpiod_set_(array)_value_xxx() passes "active" ("1"), the physical line level
will be driven low.
To summarize::