diff options
author | Linus Walleij <linus.walleij@linaro.org> | 2014-01-22 09:00:55 -0500 |
---|---|---|
committer | Linus Walleij <linus.walleij@linaro.org> | 2014-02-03 03:11:57 -0500 |
commit | 99adc0594864ebbae4478c5d85d84930894ea098 (patch) | |
tree | eb1a1b0a008a384da7febb03247b92fde8191418 /Documentation/gpio/driver.txt | |
parent | 38dbfb59d1175ef458d006556061adeaa8751b72 (diff) |
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/driver.txt')
-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 | |||
62 | requested as GPIOs. They can use gpiochip_is_requested(), which returns either | 62 | requested as GPIOs. They can use gpiochip_is_requested(), which returns either |
63 | NULL or the label associated with that GPIO when it was requested. | 63 | NULL or the label associated with that GPIO when it was requested. |
64 | 64 | ||
65 | |||
66 | GPIO drivers providing IRQs | ||
67 | --------------------------- | ||
68 | It is custom that GPIO drivers (GPIO chips) are also providing interrupts, | ||
69 | most often cascaded off a parent interrupt controller, and in some special | ||
70 | cases the GPIO logic is melded with a SoC's primary interrupt controller. | ||
71 | |||
72 | The IRQ portions of the GPIO block are implemented using an irqchip, using | ||
73 | the header <linux/irq.h>. So basically such a driver is utilizing two sub- | ||
74 | systems simultaneously: gpio and irq. | ||
75 | |||
76 | It is legal for any IRQ consumer to request an IRQ from any irqchip no matter | ||
77 | if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and | ||
78 | irq_chip are orthogonal, and offering their services independent of each | ||
79 | other. | ||
80 | |||
81 | gpiod_to_irq() is just a convenience function to figure out the IRQ for a | ||
82 | certain GPIO line and should not be relied upon to have been called before | ||
83 | the IRQ is used. | ||
84 | |||
85 | So always prepare the hardware and make it ready for action in respective | ||
86 | callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having | ||
87 | been called first. | ||
88 | |||
89 | This orthogonality leads to ambiguities that we need to solve: if there is | ||
90 | competition inside the subsystem which side is using the resource (a certain | ||
91 | GPIO line and register for example) it needs to deny certain operations and | ||
92 | keep track of usage inside of the gpiolib subsystem. This is why the API | ||
93 | below exists. | ||
94 | |||
95 | |||
65 | Locking IRQ usage | 96 | Locking IRQ usage |
66 | ----------------- | 97 | ----------------- |
67 | Input GPIOs can be used as IRQ signals. When this happens, a driver is requested | 98 | 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 | |||
73 | is released: | 104 | is released: |
74 | 105 | ||
75 | void gpiod_unlock_as_irq(struct gpio_desc *desc) | 106 | void gpiod_unlock_as_irq(struct gpio_desc *desc) |
107 | |||
108 | When implementing an irqchip inside a GPIO driver, these two functions should | ||
109 | typically be called in the .startup() and .shutdown() callbacks from the | ||
110 | irqchip. | ||