driver-api/gpio/driver.rst

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
21 of a general purpose I/O. On the other hand a LED driver line may be used as a
26 between 0 and n-1, n being the number of GPIOs managed by the chip.
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
31 use hardware offsets 0..31 for these, corresponding to bits 0..31 in the
35 line is never made visible outside of the driver.
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
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
76 Often a gpio_chip is part of an instance-specific structure with states not
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.
85 sleepable APIs (like PM runtime) in its gpio_chip implementation (.get/.set
92 -----------------------------
97 - Debouncing
98 - Single-ended modes (open drain/open source)
99 - Pull up and pull down resistor enablement
106 which will result in pinctrl_gpio_set_config() being called and eventually
107 ending up in the pin control back-end "behind" the GPIO controller, usually
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.
117 --------------------------------
121 line is pulled high/low quickly at very short intervals for mechanical
122 reasons. This can result in the value being unstable or irqs firing repeatedly
123 unless the line is debounced.
125 Debouncing in practice involves setting up a timer when something happens on
126 the line, wait a little while and then sample the line again, so see if it
128 state machine, waiting for a line to become stable. In either case, it sets
134 -----------------------------------------
136 Open drain (CMOS) or open collector (TTL) means the line is not actively driven
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
155   for any driving stage on the line to drive it low even if any other output
156   to the same line is simultaneously driving it high. A special case of this
158   wire-OR bus.
160 Both use cases require that the line be equipped with a pull-up resistor. This
161 resistor will make the line tend to high level unless one of the transistors on
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.
168 Integrated electronics often have an output driver stage in the form of a CMOS
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    ||--+
186 arrives at IN. The switches named "OD" and "OS" are normally closed, creating
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
192 is then halved and give high impedance instead of actively driving the line
193 high or low respectively. That is usually how software-controlled open
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"
201 in the drawing above.
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.
210 special callback in the gpio_chip: .set_config() that takes a generic
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
213 GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag set in the machine file, or coming
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
220 if the IN output value is set to high, it will instead *NOT* be driven high,
224 when switching the mode of the line.
227 of actively driving the line low, it is set to input.
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
238 the circuit board. This is not something we deal with or model in software. The
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
251 different pull-up or pull-down resistance values.
258 most often cascaded off a parent interrupt controller, and in some special
262 the header <linux/irq.h>. So this combined driver is utilizing two sub-
271 certain GPIO line and should not be relied upon to have been called before
274 Always prepare the hardware and make it ready for action in respective
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
282   chip. The interrupt output line will then be routed to an parent interrupt
283   controller one level up, in the most simple case the systems primary
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
294   irq line to a parent interrupt controller one level up. There is no need
295   to inquire the GPIO hardware to figure out which line has fired, but it
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()
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
316   gets called in a chain from the parent IRQ handler, most typically the
320   sequence in its interrupt handler::
328   struct gpio_chip, as everything happens directly in the callbacks: no
332   threaded on -RT. As a result, spinlock_t or any sleepable APIs (like PM
333   runtime) can't be used in a chained IRQ handler.
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",
355   The GPIO irqchip will then end up calling something like this sequence in
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
372   similar, traffic which may in turn incur other IRQs to happen, cannot be
373   handled in a quick IRQ handler with IRQs disabled. Instead they need to spawn
374   a thread and then mask the parent IRQ line until the interrupt is handled
376   this in its interrupt handler::
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
412 and the flag need_valid_mask in gpio_irq_chip can be used to mask off some
415 The preferred way to set up the helpers is to fill in the
423 .. code-block:: c
480   girq = &g->gc.irq;
482   girq->parent_handler = ftgpio_gpio_irq_handler;
483   girq->num_parents = 1;
484   girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
486   if (!girq->parents)
487       return -ENOMEM;
488   girq->default_type = IRQ_TYPE_NONE;
489   girq->handler = handle_bad_irq;
490   girq->parents[0] = irq;
492   return devm_gpiochip_add_data(dev, &g->gc, g);
497 .. code-block:: c
554 		irq_thread_fn, IRQF_ONESHOT, "my-chip", g);
559   girq = &g->gc.irq;
561   /* This will let us handle the parent IRQ in the driver */
562   girq->parent_handler = NULL;
563   girq->num_parents = 0;
564   girq->parents = NULL;
565   girq->default_type = IRQ_TYPE_NONE;
566   girq->handler = handle_bad_irq;
568   return devm_gpiochip_add_data(dev, &g->gc, g);
571 In this case the typical set-up will look like this:
573 .. code-block:: c
633   girq = &g->gc.irq;
635   girq->default_type = IRQ_TYPE_NONE;
636   girq->handler = handle_bad_irq;
637   girq->fwnode = g->fwnode;
638   girq->parent_domain = parent;
639   girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq;
641   return devm_gpiochip_add_data(dev, &g->gc, g);
647 As always it is good to look at examples in the kernel tree for advice
653 .irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
654 bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
655 from this mask. The mask can be filled in the init_valid_mask() callback
658 To use the helpers please keep the following in mind:
660 - Make sure to assign all relevant members of the struct gpio_chip so that
664 - Nominally set gpio_irq_chip.handler to handle_bad_irq. Then, if your irqchip
666   in the irqchip .set_type() callback depending on what your controller
671 -----------------
674 use cases. For example a GPIO line used for IRQs should be an input line,
678 resource (a certain GPIO line and register for example) it needs to deny
686 This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
692 typically be called in the .startup() and .shutdown() callbacks from the
700 ---------------------------
702 In some (fringe) use cases, a driver may be using a GPIO line as input for IRQs,
703 but occasionally switch that line over to drive output and then back to being
708 the IRQ is enabled or disabled. In order to inform gpiolib about this,
719 typically be called in the .irq_disable() and .irq_enable() callbacks from the
727 Real-Time compliance for GPIO IRQ chips
728 ---------------------------------------
730 Any provider of irqchips needs to be carefully tailored to support Real-Time
731 preemption. It is desirable that all irqchips in the GPIO subsystem keep this
732 in mind and do the proper testing to assure they are real time-enabled.
734 So, pay attention on above realtime considerations in the documentation.
736 The following is a checklist to follow when preparing a driver for real-time
739 - ensure spinlock_t is not used as part irq_chip implementation
740 - ensure that sleepable APIs are not used as part irq_chip implementation
743 - Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
745 - Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
746   apply corresponding work-around
747 - Chained GPIO irqchips: get rid of the chained IRQ handler and use generic irq
749 - regmap_mmio: it is possible to disable internal locking in regmap by setting
750   .disable_locking and handling the locking in the GPIO driver
751 - Test your driver with the appropriate in-kernel real-time test cases for both
754 * [1] http://www.spinics.net/lists/linux-omap/msg120425.html
755 * [2] https://lore.kernel.org/r/1443209283-20781-2-git-send-email-grygorii.strashko@ti.com
756 * [3] https://lore.kernel.org/r/1443209283-20781-3-git-send-email-grygorii.strashko@ti.com
759 Requesting self-owned GPIO pins