3f97d5fcf9
To unify how we connect cascaded IRQ chips to parent IRQs, if NULL us passed as handler to the gpiochip_set_chained_irqchip() function, assume the chips is nested rather than chained, and we still get the parent set up correctly by way of this function call. Alter the drivers for tc3589x and stmpe to use this to set up their chained handlers as a demonstration of the usage. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
193 lines
8.5 KiB
Plaintext
193 lines
8.5 KiB
Plaintext
GPIO Descriptor Driver Interface
|
|
================================
|
|
|
|
This document serves as a guide for GPIO chip drivers writers. 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.
|
|
|
|
Each GPIO controller driver needs to include the following header, which defines
|
|
the structures used to define a GPIO driver:
|
|
|
|
#include <linux/gpio/driver.h>
|
|
|
|
|
|
Internal Representation of GPIOs
|
|
================================
|
|
|
|
Inside a GPIO driver, individual GPIOs are identified by their hardware number,
|
|
which is a unique number between 0 and n, n being the number of GPIOs managed by
|
|
the chip. This number is purely internal: the hardware number of a particular
|
|
GPIO descriptor is never made visible outside of the driver.
|
|
|
|
On top of this internal number, each GPIO also need to have a global number in
|
|
the integer GPIO namespace so that it can be used with the legacy GPIO
|
|
interface. Each chip must thus have a "base" number (which can be automatically
|
|
assigned), and for each GPIO the global number will be (base + hardware number).
|
|
Although the integer representation is considered deprecated, it still has many
|
|
users and thus needs to be maintained.
|
|
|
|
So for example one platform could use numbers 32-159 for GPIOs, with a
|
|
controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
|
|
numbers 0..63 with one set of GPIO controllers, 64-79 with another type of GPIO
|
|
controller, and on one particular board 80-95 with an FPGA. The numbers need not
|
|
be contiguous; either of those platforms could also use numbers 2000-2063 to
|
|
identify GPIOs in a bank of I2C GPIO expanders.
|
|
|
|
|
|
Controller Drivers: gpio_chip
|
|
=============================
|
|
|
|
In the gpiolib framework each GPIO controller is packaged as a "struct
|
|
gpio_chip" (see linux/gpio/driver.h for its complete definition) with members
|
|
common to each controller of that type:
|
|
|
|
- methods to establish GPIO direction
|
|
- methods used to access GPIO values
|
|
- method to return the IRQ number associated to a given GPIO
|
|
- flag saying whether calls to its methods may sleep
|
|
- optional debugfs dump method (showing extra state like pullup config)
|
|
- optional base number (will be automatically assigned if omitted)
|
|
- label for diagnostics and GPIOs mapping using platform data
|
|
|
|
The code implementing a gpio_chip should support multiple instances of the
|
|
controller, possibly using the driver model. That code will configure each
|
|
gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be rare;
|
|
use gpiochip_remove() when it is unavoidable.
|
|
|
|
Most often a gpio_chip is part of an instance-specific structure with state not
|
|
exposed by the GPIO interfaces, such as addressing, power management, and more.
|
|
Chips such as codecs will have complex non-GPIO state.
|
|
|
|
Any debugfs dump method should normally ignore signals which haven't been
|
|
requested as GPIOs. They can use gpiochip_is_requested(), which returns either
|
|
NULL or the label associated with that GPIO when it was requested.
|
|
|
|
|
|
GPIO drivers providing IRQs
|
|
---------------------------
|
|
It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
|
|
most often cascaded off a parent interrupt controller, and in some special
|
|
cases the GPIO logic is melded with a SoC's primary interrupt controller.
|
|
|
|
The IRQ portions of the GPIO block are implemented using an irqchip, using
|
|
the header <linux/irq.h>. So basically such a driver is utilizing two sub-
|
|
systems simultaneously: gpio and irq.
|
|
|
|
GPIO irqchips usually fall in one of two categories:
|
|
|
|
* CHAINED GPIO irqchips: these are usually the type that is embedded on
|
|
an SoC. This means that there is a fast IRQ handler for the GPIOs that
|
|
gets called in a chain from the parent IRQ handler, most typically the
|
|
system interrupt controller. This means the GPIO irqchip is registered
|
|
using irq_set_chained_handler() or the corresponding
|
|
gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip
|
|
handler will be called immediately from the parent irqchip, while
|
|
holding the IRQs disabled. The GPIO irqchip will then end up calling
|
|
something like this sequence in its interrupt handler:
|
|
|
|
static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
|
|
chained_irq_enter(...);
|
|
generic_handle_irq(...);
|
|
chained_irq_exit(...);
|
|
|
|
Chained GPIO irqchips typically can NOT set the .can_sleep flag on
|
|
struct gpio_chip, as everything happens directly in the callbacks.
|
|
|
|
* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
|
|
other GPIO irqchip residing on the other side of a sleeping bus. Of course
|
|
such drivers that need slow bus traffic to read out IRQ status and similar,
|
|
traffic which may in turn incur other IRQs to happen, cannot be handled
|
|
in a quick IRQ handler with IRQs disabled. Instead they need to spawn a
|
|
thread and then mask the parent IRQ line until the interrupt is handled
|
|
by the driver. The hallmark of this driver is to call something like
|
|
this in its interrupt handler:
|
|
|
|
static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
|
|
...
|
|
handle_nested_irq(irq);
|
|
|
|
The hallmark of threaded GPIO irqchips is that they set the .can_sleep
|
|
flag on struct gpio_chip to true, indicating that this chip may sleep
|
|
when accessing the GPIOs.
|
|
|
|
To help out in handling the set-up and management of GPIO irqchips and the
|
|
associated irqdomain and resource allocation callbacks, the gpiolib has
|
|
some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
|
|
symbol:
|
|
|
|
* gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass
|
|
the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
|
|
need to embed the gpio_chip in its state container and obtain a pointer
|
|
to the container using container_of().
|
|
(See Documentation/driver-model/design-patterns.txt)
|
|
|
|
* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
|
|
gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
|
|
data. (Notice handler data, since the irqchip data is likely used by the
|
|
parent irqchip!) This is for the chained type of chip. This is also used
|
|
to set up a nested irqchip if NULL is passed as handler.
|
|
|
|
To use the helpers please keep the following in mind:
|
|
|
|
- Make sure to assign all relevant members of the struct gpio_chip so that
|
|
the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
|
|
properly.
|
|
|
|
It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
|
|
if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
|
|
irq_chip are orthogonal, and offering their services independent of each
|
|
other.
|
|
|
|
gpiod_to_irq() is just a convenience function to figure out the IRQ for a
|
|
certain GPIO line and should not be relied upon to have been called before
|
|
the IRQ is used.
|
|
|
|
So always prepare the hardware and make it ready for action in respective
|
|
callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
|
|
been called first.
|
|
|
|
This orthogonality leads to ambiguities that we need to solve: if there is
|
|
competition inside the subsystem which side is using the resource (a certain
|
|
GPIO line and register for example) it needs to deny certain operations and
|
|
keep track of usage inside of the gpiolib subsystem. This is why the API
|
|
below exists.
|
|
|
|
|
|
Locking IRQ usage
|
|
-----------------
|
|
Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
|
|
to mark the GPIO as being used as an IRQ:
|
|
|
|
int gpio_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
|
|
|
|
This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
|
|
is released:
|
|
|
|
void gpio_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
|
|
|
|
When implementing an irqchip inside a GPIO driver, these two functions should
|
|
typically be called in the .startup() and .shutdown() callbacks from the
|
|
irqchip.
|
|
|
|
|
|
Requesting self-owned GPIO pins
|
|
-------------------------------
|
|
|
|
Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
|
|
descriptors through the gpiolib API. Using gpio_request() for this purpose
|
|
does not help since it pins the module to the kernel forever (it calls
|
|
try_module_get()). A GPIO driver can use the following functions instead
|
|
to request and free descriptors without being pinned to the kernel forever.
|
|
|
|
struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
|
|
const char *label)
|
|
|
|
void gpiochip_free_own_desc(struct gpio_desc *desc)
|
|
|
|
Descriptors requested with gpiochip_request_own_desc() must be released with
|
|
gpiochip_free_own_desc().
|
|
|
|
These functions must be used with care since they do not affect module use
|
|
count. Do not use the functions to request gpio descriptors not owned by the
|
|
calling driver.
|