mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-24 21:24:00 +08:00
99adc05948
Write a few words on how GPIO drivers supplying an irqchip should be written. Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
111 lines
4.8 KiB
Plaintext
111 lines
4.8 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.
|
|
|
|
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 gpiod_lock_as_irq(struct gpio_desc *desc)
|
|
|
|
This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
|
|
is released:
|
|
|
|
void gpiod_unlock_as_irq(struct gpio_desc *desc)
|
|
|
|
When implementing an irqchip inside a GPIO driver, these two functions should
|
|
typically be called in the .startup() and .shutdown() callbacks from the
|
|
irqchip.
|