diff options
author | Linus Walleij <linus.walleij@linaro.org> | 2014-01-22 15:00:55 +0100 |
---|---|---|
committer | Linus Walleij <linus.walleij@linaro.org> | 2014-02-03 09:11:57 +0100 |
commit | 99adc0594864ebbae4478c5d85d84930894ea098 (patch) | |
tree | eb1a1b0a008a384da7febb03247b92fde8191418 /Documentation/gpio | |
parent | Linus 3.14-rc1 (diff) | |
download | linux-99adc0594864ebbae4478c5d85d84930894ea098.tar.xz linux-99adc0594864ebbae4478c5d85d84930894ea098.zip |
gpio: document how to make combined GPIO+irqchip drivers
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>
Diffstat (limited to 'Documentation/gpio')
-rw-r--r-- | Documentation/gpio/driver.txt | 35 |
1 files changed, 35 insertions, 0 deletions
diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index 9da0bfa74781..f73cc7b5dc85 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -62,6 +62,37 @@ 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 @@ -73,3 +104,7 @@ 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. |