blob: 90d0f6aba7a6848a3043ff7a7de3913118a98461 [file] [log] [blame]
Alexandre Courbotfd8e1982013-11-16 21:34:21 +09001GPIO Descriptor Driver Interface
2================================
3
4This document serves as a guide for GPIO chip drivers writers. Note that it
5describes the new descriptor-based interface. For a description of the
6deprecated integer-based GPIO interface please refer to gpio-legacy.txt.
7
8Each GPIO controller driver needs to include the following header, which defines
9the structures used to define a GPIO driver:
10
11 #include <linux/gpio/driver.h>
12
13
14Internal Representation of GPIOs
15================================
16
17Inside a GPIO driver, individual GPIOs are identified by their hardware number,
18which is a unique number between 0 and n, n being the number of GPIOs managed by
19the chip. This number is purely internal: the hardware number of a particular
20GPIO descriptor is never made visible outside of the driver.
21
22On top of this internal number, each GPIO also need to have a global number in
23the integer GPIO namespace so that it can be used with the legacy GPIO
24interface. Each chip must thus have a "base" number (which can be automatically
25assigned), and for each GPIO the global number will be (base + hardware number).
26Although the integer representation is considered deprecated, it still has many
27users and thus needs to be maintained.
28
29So for example one platform could use numbers 32-159 for GPIOs, with a
30controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
31numbers 0..63 with one set of GPIO controllers, 64-79 with another type of GPIO
32controller, and on one particular board 80-95 with an FPGA. The numbers need not
33be contiguous; either of those platforms could also use numbers 2000-2063 to
34identify GPIOs in a bank of I2C GPIO expanders.
35
36
37Controller Drivers: gpio_chip
38=============================
39
40In the gpiolib framework each GPIO controller is packaged as a "struct
41gpio_chip" (see linux/gpio/driver.h for its complete definition) with members
42common to each controller of that type:
43
44 - methods to establish GPIO direction
45 - methods used to access GPIO values
46 - method to return the IRQ number associated to a given GPIO
47 - flag saying whether calls to its methods may sleep
48 - optional debugfs dump method (showing extra state like pullup config)
49 - optional base number (will be automatically assigned if omitted)
50 - label for diagnostics and GPIOs mapping using platform data
51
52The code implementing a gpio_chip should support multiple instances of the
53controller, possibly using the driver model. That code will configure each
54gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be rare;
55use gpiochip_remove() when it is unavoidable.
56
57Most often a gpio_chip is part of an instance-specific structure with state not
58exposed by the GPIO interfaces, such as addressing, power management, and more.
59Chips such as codecs will have complex non-GPIO state.
60
61Any debugfs dump method should normally ignore signals which haven't been
62requested as GPIOs. They can use gpiochip_is_requested(), which returns either
63NULL or the label associated with that GPIO when it was requested.
64
Linus Walleij99adc052014-01-22 15:00:55 +010065
66GPIO drivers providing IRQs
67---------------------------
68It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
69most often cascaded off a parent interrupt controller, and in some special
70cases the GPIO logic is melded with a SoC's primary interrupt controller.
71
72The IRQ portions of the GPIO block are implemented using an irqchip, using
73the header <linux/irq.h>. So basically such a driver is utilizing two sub-
74systems simultaneously: gpio and irq.
75
Linus Walleij90887db2014-04-09 14:36:32 +020076GPIO irqchips usually fall in one of two categories:
77
78* CHAINED GPIO irqchips: these are usually the type that is embedded on
79 an SoC. This means that there is a fast IRQ handler for the GPIOs that
80 gets called in a chain from the parent IRQ handler, most typically the
81 system interrupt controller. This means the GPIO irqchip is registered
82 using irq_set_chained_handler() or the corresponding
83 gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip
84 handler will be called immediately from the parent irqchip, while
85 holding the IRQs disabled. The GPIO irqchip will then end up calling
86 something like this sequence in its interrupt handler:
87
88 static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
89 chained_irq_enter(...);
90 generic_handle_irq(...);
91 chained_irq_exit(...);
92
93 Chained GPIO irqchips typically can NOT set the .can_sleep flag on
94 struct gpio_chip, as everything happens directly in the callbacks.
95
96* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
97 other GPIO irqchip residing on the other side of a sleeping bus. Of course
98 such drivers that need slow bus traffic to read out IRQ status and similar,
99 traffic which may in turn incur other IRQs to happen, cannot be handled
100 in a quick IRQ handler with IRQs disabled. Instead they need to spawn a
101 thread and then mask the parent IRQ line until the interrupt is handled
102 by the driver. The hallmark of this driver is to call something like
103 this in its interrupt handler:
104
105 static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
106 ...
107 handle_nested_irq(irq);
108
109 The hallmark of threaded GPIO irqchips is that they set the .can_sleep
110 flag on struct gpio_chip to true, indicating that this chip may sleep
111 when accessing the GPIOs.
112
113To help out in handling the set-up and management of GPIO irqchips and the
114associated irqdomain and resource allocation callbacks, the gpiolib has
115some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
116symbol:
117
118* gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass
119 the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
120 need to embed the gpio_chip in its state container and obtain a pointer
121 to the container using container_of().
122 (See Documentation/driver-model/design-patterns.txt)
123
124* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
125 gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
126 data. (Notice handler data, since the irqchip data is likely used by the
Linus Walleij3f97d5fc2014-09-26 14:19:52 +0200127 parent irqchip!) This is for the chained type of chip. This is also used
128 to set up a nested irqchip if NULL is passed as handler.
Linus Walleij90887db2014-04-09 14:36:32 +0200129
130To use the helpers please keep the following in mind:
131
132- Make sure to assign all relevant members of the struct gpio_chip so that
133 the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
134 properly.
135
Linus Walleij99adc052014-01-22 15:00:55 +0100136It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
137if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
138irq_chip are orthogonal, and offering their services independent of each
139other.
140
141gpiod_to_irq() is just a convenience function to figure out the IRQ for a
142certain GPIO line and should not be relied upon to have been called before
143the IRQ is used.
144
145So always prepare the hardware and make it ready for action in respective
146callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
147been called first.
148
149This orthogonality leads to ambiguities that we need to solve: if there is
150competition inside the subsystem which side is using the resource (a certain
151GPIO line and register for example) it needs to deny certain operations and
152keep track of usage inside of the gpiolib subsystem. This is why the API
153below exists.
154
155
Alexandre Courbotfd8e1982013-11-16 21:34:21 +0900156Locking IRQ usage
157-----------------
158Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
159to mark the GPIO as being used as an IRQ:
160
Alexandre Courbote3a2e872014-10-23 17:27:07 +0900161 int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
Alexandre Courbotfd8e1982013-11-16 21:34:21 +0900162
163This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
164is released:
165
Alexandre Courbote3a2e872014-10-23 17:27:07 +0900166 void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
Linus Walleij99adc052014-01-22 15:00:55 +0100167
168When implementing an irqchip inside a GPIO driver, these two functions should
169typically be called in the .startup() and .shutdown() callbacks from the
170irqchip.
Guenter Roeckf7d4ad92014-07-22 08:01:01 -0700171
172
173Requesting self-owned GPIO pins
174-------------------------------
175
176Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
177descriptors through the gpiolib API. Using gpio_request() for this purpose
178does not help since it pins the module to the kernel forever (it calls
179try_module_get()). A GPIO driver can use the following functions instead
180to request and free descriptors without being pinned to the kernel forever.
181
Alexandre Courbotabdc08a2014-08-19 10:06:09 -0700182 struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
183 const char *label)
Guenter Roeckf7d4ad92014-07-22 08:01:01 -0700184
185 void gpiochip_free_own_desc(struct gpio_desc *desc)
186
187Descriptors requested with gpiochip_request_own_desc() must be released with
188gpiochip_free_own_desc().
189
190These functions must be used with care since they do not affect module use
191count. Do not use the functions to request gpio descriptors not owned by the
192calling driver.