Documentation: gpio: Move gpiod_* consumer documentation to driver-api

Move gpio/consumer.txt to driver-api/gpio/consumer.rst and make sure it
builds cleanly as ReST.

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

2 files changed, 0 insertions, 440 deletions

diff --git a/Documentation/gpio/00-INDEX b/Documentation/gpio/00-INDEX
index 64cf61245861..f960fc00a3ef 100644
--- a/Documentation/gpio/00-INDEX
+++ b/Documentation/gpio/00-INDEX
@@ -1,7 +1,5 @@
 00-INDEX
 	- This file
-consumer.txt
-	- How to obtain and use GPIOs in a driver
 drivers-on-gpio.txt:
 	- Drivers in other subsystems that can use GPIO to provide more
 	  complex functionality.
diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt
deleted file mode 100644
index d53e5b5cfc9c..000000000000
--- a/Documentation/gpio/consumer.txt
+++ /dev/null
@@ -1,438 +0,0 @@
-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.