blob: 6cb35a78eff4c5c50073a2cdb4dac603a3a16b79 [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
Grygorii Strashkoc307b002015-10-20 17:22:15 +030065RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs
66(like PM runtime) in its gpio_chip implementation (.get/.set and direction
67control callbacks) if it is expected to call GPIO APIs from atomic context
68on -RT (inside hard IRQ handlers and similar contexts). Normally this should
69not be required.
Linus Walleij99adc052014-01-22 15:00:55 +010070
Linus Walleij6b5029d2016-04-05 16:49:57 +020071
72GPIOs with open drain/source support
73------------------------------------
74
75Open drain (CMOS) or open collector (TTL) means the line is not actively driven
76high: instead you provide the drain/collector as output, so when the transistor
77is not open, it will present a high-impedance (tristate) to the external rail.
78
79
80 CMOS CONFIGURATION TTL CONFIGURATION
81
82 ||--- out +--- out
83 in ----|| |/
84 ||--+ in ----|
85 | |\
86 GND GND
87
88This configuration is normally used as a way to achieve one of two things:
89
90- Level-shifting: to reach a logical level higher than that of the silicon
91 where the output resides.
92
93- inverse wire-OR on an I/O line, for example a GPIO line, making it possible
94 for any driving stage on the line to drive it low even if any other output
95 to the same line is simultaneously driving it high. A special case of this
96 is driving the SCL and SCA lines of an I2C bus, which is by definition a
97 wire-OR bus.
98
99Both usecases require that the line be equipped with a pull-up resistor. This
100resistor will make the line tend to high level unless one of the transistors on
101the rail actively pulls it down.
102
Linus Walleij451938d2016-04-27 10:23:44 +0200103The level on the line will go as high as the VDD on the pull-up resistor, which
104may be higher than the level supported by the transistor, achieveing a
105level-shift to the higher VDD.
106
Linus Walleij6b5029d2016-04-05 16:49:57 +0200107Integrated electronics often have an output driver stage in the form of a CMOS
108"totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
109the line high and one of them drives the line low. This is called a push-pull
110output. The "totem-pole" looks like so:
111
112 VDD
113 |
114 OD ||--+
115 +--/ ---o|| P-MOS-FET
116 | ||--+
Linus Walleij451938d2016-04-27 10:23:44 +0200117IN --+ +----- out
Linus Walleij6b5029d2016-04-05 16:49:57 +0200118 | ||--+
119 +--/ ----|| N-MOS-FET
120 OS ||--+
121 |
122 GND
123
Linus Walleij451938d2016-04-27 10:23:44 +0200124The desired output signal (e.g. coming directly from some GPIO output register)
125arrives at IN. The switches named "OD" and "OS" are normally closed, creating
126a push-pull circuit.
127
128Consider the little "switches" named "OD" and "OS" that enable/disable the
Linus Walleij6b5029d2016-04-05 16:49:57 +0200129P-MOS or N-MOS transistor right after the split of the input. As you can see,
130either transistor will go totally numb if this switch is open. The totem-pole
131is then halved and give high impedance instead of actively driving the line
132high or low respectively. That is usually how software-controlled open
133drain/source works.
134
135Some GPIO hardware come in open drain / open source configuration. Some are
136hard-wired lines that will only support open drain or open source no matter
137what: there is only one transistor there. Some are software-configurable:
138by flipping a bit in a register the output can be configured as open drain
Linus Walleij451938d2016-04-27 10:23:44 +0200139or open source, in practice by flicking open the switches labeled "OD" and "OS"
140in the drawing above.
Linus Walleij6b5029d2016-04-05 16:49:57 +0200141
142By disabling the P-MOS transistor, the output can be driven between GND and
143high impedance (open drain), and by disabling the N-MOS transistor, the output
144can be driven between VDD and high impedance (open source). In the first case,
145a pull-up resistor is needed on the outgoing rail to complete the circuit, and
146in the second case, a pull-down resistor is needed on the rail.
147
148Hardware that supports open drain or open source or both, can implement a
149special callback in the gpio_chip: .set_single_ended() that takes an enum flag
150telling whether to configure the line as open drain, open source or push-pull.
151This will happen in response to the GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag
152set in the machine file, or coming from other hardware descriptions.
153
154If this state can not be configured in hardware, i.e. if the GPIO hardware does
155not support open drain/open source in hardware, the GPIO library will instead
156use a trick: when a line is set as output, if the line is flagged as open
Linus Walleij451938d2016-04-27 10:23:44 +0200157drain, and the IN output value is low, it will be driven low as usual. But
158if the IN output value is set to high, it will instead *NOT* be driven high,
Linus Walleij6b5029d2016-04-05 16:49:57 +0200159instead it will be switched to input, as input mode is high impedance, thus
160achieveing an "open drain emulation" of sorts: electrically the behaviour will
161be identical, with the exception of possible hardware glitches when switching
162the mode of the line.
163
164For open source configuration the same principle is used, just that instead
165of actively driving the line low, it is set to input.
166
167
Linus Walleij99adc052014-01-22 15:00:55 +0100168GPIO drivers providing IRQs
169---------------------------
170It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
171most often cascaded off a parent interrupt controller, and in some special
172cases the GPIO logic is melded with a SoC's primary interrupt controller.
173
174The IRQ portions of the GPIO block are implemented using an irqchip, using
175the header <linux/irq.h>. So basically such a driver is utilizing two sub-
176systems simultaneously: gpio and irq.
177
Grygorii Strashkoc307b002015-10-20 17:22:15 +0300178RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs
179(like PM runtime) as part of its irq_chip implementation on -RT.
180- spinlock_t should be replaced with raw_spinlock_t [1].
181- If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
182 and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks
183 on an irqchip. Create the callbacks if needed [2].
184
Linus Walleij90887db2014-04-09 14:36:32 +0200185GPIO irqchips usually fall in one of two categories:
186
187* CHAINED GPIO irqchips: these are usually the type that is embedded on
188 an SoC. This means that there is a fast IRQ handler for the GPIOs that
189 gets called in a chain from the parent IRQ handler, most typically the
190 system interrupt controller. This means the GPIO irqchip is registered
191 using irq_set_chained_handler() or the corresponding
192 gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip
193 handler will be called immediately from the parent irqchip, while
194 holding the IRQs disabled. The GPIO irqchip will then end up calling
195 something like this sequence in its interrupt handler:
196
197 static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
198 chained_irq_enter(...);
199 generic_handle_irq(...);
200 chained_irq_exit(...);
201
202 Chained GPIO irqchips typically can NOT set the .can_sleep flag on
203 struct gpio_chip, as everything happens directly in the callbacks.
204
Grygorii Strashkoc307b002015-10-20 17:22:15 +0300205 RT_FULL: Note, chained IRQ handlers will not be forced threaded on -RT.
206 As result, spinlock_t or any sleepable APIs (like PM runtime) can't be used
207 in chained IRQ handler.
208 if required (and if it can't be converted to the nested threaded GPIO irqchip)
209 - chained IRQ handler can be converted to generic irq handler and this way
210 it will be threaded IRQ handler on -RT and hard IRQ handler on non-RT
211 (for example, see [3]).
212 Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled,
Masanari Iida547d4c12015-11-16 20:00:35 +0900213 so IRQ core will complain if it will be called from IRQ handler which is
214 forced thread. The "fake?" raw lock can be used to W/A this problem:
Grygorii Strashkoc307b002015-10-20 17:22:15 +0300215
216 raw_spinlock_t wa_lock;
217 static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
218 unsigned long wa_lock_flags;
219 raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags);
220 generic_handle_irq(irq_find_mapping(bank->chip.irqdomain, bit));
221 raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags);
222
223* GENERIC CHAINED GPIO irqchips: these are the same as "CHAINED GPIO irqchips",
224 but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
225 performed by generic IRQ handler which is configured using request_irq().
226 The GPIO irqchip will then end up calling something like this sequence in
227 its interrupt handler:
228
229 static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
230 for each detected GPIO IRQ
231 generic_handle_irq(...);
232
233 RT_FULL: Such kind of handlers will be forced threaded on -RT, as result IRQ
234 core will complain that generic_handle_irq() is called with IRQ enabled and
235 the same W/A as for "CHAINED GPIO irqchips" can be applied.
236
Linus Walleij4aa50b82015-10-27 11:13:18 +0100237* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
238 other GPIO irqchip residing on the other side of a sleeping bus. Of course
239 such drivers that need slow bus traffic to read out IRQ status and similar,
240 traffic which may in turn incur other IRQs to happen, cannot be handled
241 in a quick IRQ handler with IRQs disabled. Instead they need to spawn a
242 thread and then mask the parent IRQ line until the interrupt is handled
243 by the driver. The hallmark of this driver is to call something like
244 this in its interrupt handler:
Linus Walleij90887db2014-04-09 14:36:32 +0200245
246 static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
247 ...
248 handle_nested_irq(irq);
249
Linus Walleij4aa50b82015-10-27 11:13:18 +0100250 The hallmark of threaded GPIO irqchips is that they set the .can_sleep
251 flag on struct gpio_chip to true, indicating that this chip may sleep
252 when accessing the GPIOs.
Linus Walleij90887db2014-04-09 14:36:32 +0200253
254To help out in handling the set-up and management of GPIO irqchips and the
255associated irqdomain and resource allocation callbacks, the gpiolib has
256some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
257symbol:
258
259* gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass
260 the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
261 need to embed the gpio_chip in its state container and obtain a pointer
262 to the container using container_of().
263 (See Documentation/driver-model/design-patterns.txt)
264
265* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
266 gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
267 data. (Notice handler data, since the irqchip data is likely used by the
Linus Walleij3f97d5fc2014-09-26 14:19:52 +0200268 parent irqchip!) This is for the chained type of chip. This is also used
Linus Walleij4aa50b82015-10-27 11:13:18 +0100269 to set up a nested irqchip if NULL is passed as handler.
Linus Walleij90887db2014-04-09 14:36:32 +0200270
271To use the helpers please keep the following in mind:
272
273- Make sure to assign all relevant members of the struct gpio_chip so that
274 the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
275 properly.
276
Grygorii Strashkoc307b002015-10-20 17:22:15 +0300277- Nominally set all handlers to handle_bad_irq() in the setup call and pass
278 handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is
279 expected for GPIO driver that irqchip .set_type() callback have to be called
280 before using/enabling GPIO IRQ. Then set the handler to handle_level_irq()
281 and/or handle_edge_irq() in the irqchip .set_type() callback depending on
282 what your controller supports.
283
Linus Walleij99adc052014-01-22 15:00:55 +0100284It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
285if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
286irq_chip are orthogonal, and offering their services independent of each
287other.
288
289gpiod_to_irq() is just a convenience function to figure out the IRQ for a
290certain GPIO line and should not be relied upon to have been called before
291the IRQ is used.
292
293So always prepare the hardware and make it ready for action in respective
294callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
295been called first.
296
297This orthogonality leads to ambiguities that we need to solve: if there is
298competition inside the subsystem which side is using the resource (a certain
299GPIO line and register for example) it needs to deny certain operations and
300keep track of usage inside of the gpiolib subsystem. This is why the API
301below exists.
302
303
Alexandre Courbotfd8e1982013-11-16 21:34:21 +0900304Locking IRQ usage
305-----------------
306Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
307to mark the GPIO as being used as an IRQ:
308
Alexandre Courbote3a2e872014-10-23 17:27:07 +0900309 int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
Alexandre Courbotfd8e1982013-11-16 21:34:21 +0900310
311This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
312is released:
313
Alexandre Courbote3a2e872014-10-23 17:27:07 +0900314 void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
Linus Walleij99adc052014-01-22 15:00:55 +0100315
316When implementing an irqchip inside a GPIO driver, these two functions should
317typically be called in the .startup() and .shutdown() callbacks from the
318irqchip.
Guenter Roeckf7d4ad92014-07-22 08:01:01 -0700319
Grygorii Strashkoc307b002015-10-20 17:22:15 +0300320Real-Time compliance for GPIO IRQ chips
321---------------------------------------
322
323Any provider of irqchips needs to be carefully tailored to support Real Time
Masanari Iida547d4c12015-11-16 20:00:35 +0900324preemption. It is desirable that all irqchips in the GPIO subsystem keep this
Grygorii Strashkoc307b002015-10-20 17:22:15 +0300325in mind and does the proper testing to assure they are real time-enabled.
326So, pay attention on above " RT_FULL:" notes, please.
327The following is a checklist to follow when preparing a driver for real
328time-compliance:
329
330- ensure spinlock_t is not used as part irq_chip implementation;
331- ensure that sleepable APIs are not used as part irq_chip implementation.
332 If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
333 and .irq_bus_unlock() callbacks;
334- Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
335 from chained IRQ handler;
336- Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
337 apply corresponding W/A;
338- Chained GPIO irqchips: get rid of chained IRQ handler and use generic irq
339 handler if possible :)
340- regmap_mmio: Sry, but you are in trouble :( if MMIO regmap is used as for
341 GPIO IRQ chip implementation;
342- Test your driver with the appropriate in-kernel real time test cases for both
343 level and edge IRQs.
344
Guenter Roeckf7d4ad92014-07-22 08:01:01 -0700345
346Requesting self-owned GPIO pins
347-------------------------------
348
349Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
350descriptors through the gpiolib API. Using gpio_request() for this purpose
351does not help since it pins the module to the kernel forever (it calls
352try_module_get()). A GPIO driver can use the following functions instead
353to request and free descriptors without being pinned to the kernel forever.
354
Alexandre Courbotabdc08a2014-08-19 10:06:09 -0700355 struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
356 const char *label)
Guenter Roeckf7d4ad92014-07-22 08:01:01 -0700357
358 void gpiochip_free_own_desc(struct gpio_desc *desc)
359
360Descriptors requested with gpiochip_request_own_desc() must be released with
361gpiochip_free_own_desc().
362
363These functions must be used with care since they do not affect module use
364count. Do not use the functions to request gpio descriptors not owned by the
365calling driver.
Grygorii Strashkoc307b002015-10-20 17:22:15 +0300366
367[1] http://www.spinics.net/lists/linux-omap/msg120425.html
368[2] https://lkml.org/lkml/2015/9/25/494
369[3] https://lkml.org/lkml/2015/9/25/495