driver-api/gpio/driver.rst

2 GPIO Driver Interface
5 This document serves as a guide for writers of GPIO chip drivers.
7 Each GPIO controller driver needs to include the following header, which defines
8 the structures used to define a GPIO driver::
10 	#include <linux/gpio/driver.h>
16 A GPIO chip handles one or more GPIO lines. To be considered a GPIO chip, the
18 line is not general purpose, it is not GPIO and should not be handled by a
19 GPIO chip. The use case is the indicative: certain lines in a system may be
20 called GPIO but serve a very particular purpose thus not meeting the criteria
22 GPIO and should therefore still be handled by a GPIO chip driver.
24 Inside a GPIO driver, individual GPIO lines are identified by their hardware
26 between 0 and n-1, n being the number of GPIOs managed by the chip.
28 The hardware GPIO number should be something intuitive to the hardware, for
29 example if a system uses a memory-mapped set of I/O-registers where 32 GPIO
30 lines are handled by one bit per line in a 32-bit register, it makes sense to
34 This number is purely internal: the hardware number of a particular GPIO
37 On top of this internal number, each GPIO line also needs to have a global
38 number in the integer GPIO namespace so that it can be used with the legacy GPIO
40 assigned), and for each GPIO line the global number will be (base + hardware
44 So for example one platform could use global numbers 32-159 for GPIOs, with a
46 global numbers 0..63 with one set of GPIO controllers, 64-79 with another type
47 of GPIO controller, and on one particular board 80-95 with an FPGA. The legacy
49 2000-2063 to identify GPIO lines in a bank of I2C GPIO expanders.
55 In the gpiolib framework each GPIO controller is packaged as a "struct
56 gpio_chip" (see <linux/gpio/driver.h> for its complete definition) with members
60  - methods to establish GPIO line direction
61  - methods used to access GPIO line values
62  - method to set electrical configuration for a given GPIO line
63  - method to return the IRQ number associated to a given GPIO line
64  - flag saying whether calls to its methods may sleep
65  - optional line names array to identify lines
66  - optional debugfs dump method (showing extra state information)
67  - optional base number (will be automatically assigned if omitted)
68  - optional label for diagnostics and GPIO chip mapping using platform data
73 devm_gpiochip_add_data().  Removing a GPIO controller should be rare; use
76 Often a gpio_chip is part of an instance-specific structure with states not
77 exposed by the GPIO interfaces, such as addressing, power management, and more.
78 Chips such as audio codecs will have complex non-GPIO states.
82 NULL or the label associated with that GPIO line when it was requested.
84 Realtime considerations: the GPIO driver should not use spinlock_t or any
86 and direction control callbacks) if it is expected to call GPIO APIs from
91 GPIO electrical configuration
92 -----------------------------
94 GPIO lines can be configured for several electrical modes of operation by using
97 - Debouncing
98 - Single-ended modes (open drain/open source)
99 - Pull up and pull down resistor enablement
107 ending up in the pin control back-end "behind" the GPIO controller, usually
109 listed GPIO configurations.
111 If a pin controller back-end is used, the GPIO controller or hardware
112 description needs to provide "GPIO ranges" mapping the GPIO line offsets to pin
113 numbers on the pin controller so they can properly cross-reference each other.
116 GPIO lines with debounce support
117 --------------------------------
133 GPIO lines with open drain/source support
134 -----------------------------------------
136 Open drain (CMOS) or open collector (TTL) means the line is not actively driven
137 high: instead you provide the drain/collector as output, so when the transistor
138 is not open, it will present a high-impedance (tristate) to the external rail::
143             ||--- out              +--- out
144      in ----||                   |/
145             ||--+         in ----|
151 - Level-shifting: to reach a logical level higher than that of the silicon
154 - Inverse wire-OR on an I/O line, for example a GPIO line, making it possible
158   wire-OR bus.
160 Both use cases require that the line be equipped with a pull-up resistor. This
164 The level on the line will go as high as the VDD on the pull-up resistor, which
166 level-shift to the higher VDD.
169 "totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
170 the line high and one of them drives the line low. This is called a push-pull
171 output. The "totem-pole" looks like so::
175             OD    ||--+
176          +--/ ---o||     P-MOS-FET
177          |        ||--+
178     IN --+            +----- out
179          |        ||--+
180          +--/ ----||     N-MOS-FET
181             OS    ||--+
185 The desired output signal (e.g. coming directly from some GPIO output register)
187 a push-pull circuit.
190 P-MOS or N-MOS transistor right after the split of the input. As you can see,
191 either transistor will go totally numb if this switch is open. The totem-pole
193 high or low respectively. That is usually how software-controlled open
194 drain/source works.
196 Some GPIO hardware come in open drain / open source configuration. Some are
197 hard-wired lines that will only support open drain or open source no matter
198 what: there is only one transistor there. Some are software-configurable:
199 by flipping a bit in a register the output can be configured as open drain
200 or open source, in practice by flicking open the switches labeled "OD" and "OS"
203 By disabling the P-MOS transistor, the output can be driven between GND and
204 high impedance (open drain), and by disabling the N-MOS transistor, the output
205 can be driven between VDD and high impedance (open source). In the first case,
206 a pull-up resistor is needed on the outgoing rail to complete the circuit, and
207 in the second case, a pull-down resistor is needed on the rail.
209 Hardware that supports open drain or open source or both, can implement a
211 pinconf packed value telling whether to configure the line as open drain,
212 open source or push-pull. This will happen in response to the
216 If this state can not be configured in hardware, i.e. if the GPIO hardware does
217 not support open drain/open source in hardware, the GPIO library will instead
218 use a trick: when a line is set as output, if the line is flagged as open
219 drain, and the IN output value is low, it will be driven low as usual. But
222 achieveing an "open drain emulation" of sorts: electrically the behaviour will
226 For open source configuration the same principle is used, just that instead
230 GPIO lines with pull up/down resistor support
231 ---------------------------------------------
233 A GPIO line can support pull-up/down using the .set_config() callback. This
234 means that a pull up or pull-down resistor is available on the output of the
235 GPIO line, and this resistor is software controlled.
237 In discrete designs, a pull-up or pull-down resistor is simply soldered on
240 configured as open drain or open source (see the section above).
244 switch a bit in a register enabling or disabling pull-up or pull-down.
246 If the GPIO line supports shunting in different resistance values for the
247 pull-up or pull-down resistor, the GPIO chip callback .set_config() will not
248 suffice. For these complex use cases, a combined GPIO chip and pin controller
251 different pull-up or pull-down resistance values.
254 GPIO drivers providing IRQs
257 It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
259 cases the GPIO logic is melded with a SoC's primary interrupt controller.
261 The IRQ portions of the GPIO block are implemented using an irq_chip, using
262 the header <linux/irq.h>. So this combined driver is utilizing two sub-
263 systems simultaneously: gpio and irq.
266 is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
271 certain GPIO line and should not be relied upon to have been called before
275 callbacks from the GPIO and irq_chip APIs. Do not rely on gpiod_to_irq() having
278 We can divide GPIO irqchips in two broad categories:
280 - CASCADED INTERRUPT CHIPS: this means that the GPIO chip has one common
281   interrupt output line, which is triggered by any enabled GPIO line on that
285   inside the GPIO controller to figure out which line fired it. The irqchip
293 - HIERARCHICAL INTERRUPT CHIPS: this means that each GPIO line has a dedicated
295   to inquire the GPIO hardware to figure out which line has fired, but it
299 Realtime considerations: a realtime compliant GPIO driver should not use
303 - spinlock_t should be replaced with raw_spinlock_t.[1]
304 - If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
309 Cascaded GPIO irqchips
310 ----------------------
312 Cascaded GPIO irqchips usually fall in one of three categories:
314 - CHAINED CASCADED GPIO IRQCHIPS: these are usually the type that is embedded on
317   system interrupt controller. This means that the GPIO irqchip handler will
319   disabled. The GPIO irqchip will then end up calling something like this
327   Chained GPIO irqchips typically can NOT set the .can_sleep flag on
332   threaded on -RT. As a result, spinlock_t or any sleepable APIs (like PM
335   If required (and if it can't be converted to the nested threaded GPIO irqchip,
337   this way it will become a threaded IRQ handler on -RT and a hard IRQ handler
338   on non-RT (for example, see [3]).
348         raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags);
349         generic_handle_irq(irq_find_mapping(bank->chip.irq.domain, bit));
350         raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags);
352 - GENERIC CHAINED GPIO IRQCHIPS: these are the same as "CHAINED GPIO irqchips",
353   but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
355   The GPIO irqchip will then end up calling something like this sequence in
359         for each detected GPIO IRQ
362   Realtime considerations: this kind of handlers will be forced threaded on -RT,
364   with IRQ enabled and the same work-around as for "CHAINED GPIO irqchips" can
367 - NESTED THREADED GPIO IRQCHIPS: these are off-chip GPIO expanders and any
368   other GPIO irqchip residing on the other side of a sleeping bus such as I2C
382   The hallmark of threaded GPIO irqchips is that they set the .can_sleep
390 Infrastructure helpers for GPIO irqchips
391 ----------------------------------------
393 To help out in handling the set-up and management of GPIO irqchips and the
398 under the assumption that your interrupts are 1-to-1-mapped to the
399 GPIO line index:
401 .. csv-table::
402     :header: GPIO line offset, Hardware IRQ
408     ngpio-1, ngpio-1
411 If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask
418 same time as setting up the rest of the GPIO functionality. The following
421 .. code-block:: c
434   g->irq.name = "my_gpio_irq";
435   g->irq.irq_ack = my_gpio_ack_irq;
436   g->irq.irq_mask = my_gpio_mask_irq;
437   g->irq.irq_unmask = my_gpio_unmask_irq;
438   g->irq.irq_set_type = my_gpio_set_irq_type;
441   girq = &g->gc.irq;
442   girq->chip = &g->irq;
443   girq->parent_handler = ftgpio_gpio_irq_handler;
444   girq->num_parents = 1;
445   girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
447   if (!girq->parents)
448       return -ENOMEM;
449   girq->default_type = IRQ_TYPE_NONE;
450   girq->handler = handle_bad_irq;
451   girq->parents[0] = irq;
453   return devm_gpiochip_add_data(dev, &g->gc, g);
456 In this case the typical set-up will look like this:
458 .. code-block:: c
472   g->irq.name = "my_gpio_irq";
473   g->irq.irq_ack = my_gpio_ack_irq;
474   g->irq.irq_mask = my_gpio_mask_irq;
475   g->irq.irq_unmask = my_gpio_unmask_irq;
476   g->irq.irq_set_type = my_gpio_set_irq_type;
479   girq = &g->gc.irq;
480   girq->chip = &g->irq;
481   girq->default_type = IRQ_TYPE_NONE;
482   girq->handler = handle_bad_irq;
483   girq->fwnode = g->fwnode;
484   girq->parent_domain = parent;
485   girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq;
487   return devm_gpiochip_add_data(dev, &g->gc, g);
492 the parent hardware irq from a child (i.e. this gpio chip) hardware irq.
499 - DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a
503   (See Documentation/driver-api/driver-model/design-patterns.rst)
505 - gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip,
510 - gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a
515 If there is a need to exclude certain GPIO lines from the IRQ domain handled by
518 .irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
519 bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
525 - Make sure to assign all relevant members of the struct gpio_chip so that
529 - Nominally set all handlers to handle_bad_irq() in the setup call and pass
531   expected for GPIO driver that irqchip .set_type() callback will be called
532   before using/enabling each GPIO IRQ. Then set the handler to
539 -----------------
541 Since GPIO and irq_chip are orthogonal, we can get conflicts between different
542 use cases. For example a GPIO line used for IRQs should be an input line,
543 it does not make sense to fire interrupts on an output GPIO.
546 resource (a certain GPIO line and register for example) it needs to deny
550 to mark the GPIO as being used as an IRQ::
554 This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
559 When implementing an irqchip inside a GPIO driver, these two functions should
568 ---------------------------
570 In some (fringe) use cases, a driver may be using a GPIO line as input for IRQs,
575 When a GPIO is used as an IRQ signal, then gpiolib also needs to know if
581 This allows drivers to drive the GPIO as an output while the IRQ is
586 When implementing an irqchip inside a GPIO driver, these two functions should
594 Real-Time compliance for GPIO IRQ chips
595 ---------------------------------------
597 Any provider of irqchips needs to be carefully tailored to support Real-Time
598 preemption. It is desirable that all irqchips in the GPIO subsystem keep this
599 in mind and do the proper testing to assure they are real time-enabled.
603 The following is a checklist to follow when preparing a driver for real-time
606 - ensure spinlock_t is not used as part irq_chip implementation
607 - ensure that sleepable APIs are not used as part irq_chip implementation
610 - Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
612 - Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
613   apply corresponding work-around
614 - Chained GPIO irqchips: get rid of the chained IRQ handler and use generic irq
616 - regmap_mmio: it is possible to disable internal locking in regmap by setting
617   .disable_locking and handling the locking in the GPIO driver
618 - Test your driver with the appropriate in-kernel real-time test cases for both
621 * [1] http://www.spinics.net/lists/linux-omap/msg120425.html
626 Requesting self-owned GPIO pins
629 Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
630 descriptors through the gpiolib API. A GPIO driver can use the following
644 count. Do not use the functions to request gpio descriptors not owned by the