Lines Matching +full:a +full:- +full:gpio
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
21 of a general purpose I/O. On the other hand a LED driver line may be used as a
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
25 number, sometime also referred to as ``offset``, which is a unique number
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
39 interface. Each chip must thus have a "base" number (which can be automatically
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
45 controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
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
70 The code implementing a gpio_chip should support multiple instances of the
73 a GPIO controller should be rare; use gpiochip_remove() when it is unavoidable.
75 Often a gpio_chip is part of an instance-specific structure with states not
76 exposed by the GPIO interfaces, such as addressing, power management, and more.
77 Chips such as audio codecs will have complex non-GPIO states.
81 NULL or the label associated with that GPIO line when it was requested.
83 Realtime considerations: the GPIO driver should not use spinlock_t or any
85 and direction control callbacks) if it is expected to call GPIO APIs from
90 GPIO electrical configuration
91 -----------------------------
93 GPIO lines can be configured for several electrical modes of operation by using
96 - Debouncing
97 - Single-ended modes (open drain/open source)
98 - Pull up and pull down resistor enablement
103 semantics as the generic pin control drivers. This is not a coincidence: it is
106 ending up in the pin control back-end "behind" the GPIO controller, usually
108 listed GPIO configurations.
110 If a pin controller back-end is used, the GPIO controller or hardware
111 description needs to provide "GPIO ranges" mapping the GPIO line offsets to pin
112 numbers on the pin controller so they can properly cross-reference each other.
115 GPIO lines with debounce support
116 --------------------------------
118 Debouncing is a configuration set to a pin indicating that it is connected to
119 a mechanical switch or button, or similar that may bounce. Bouncing means the
124 Debouncing in practice involves setting up a timer when something happens on
125 the line, wait a little while and then sample the line again, so see if it
126 still has the same value (low or high). This could also be repeated by a clever
127 state machine, waiting for a line to become stable. In either case, it sets
128 a certain number of milliseconds for debouncing, or just "on/off" if that time
132 GPIO lines with open drain/source support
133 -----------------------------------------
137 is not open, it will present a high-impedance (tristate) to the external rail::
142 ||--- out +--- out
143 in ----|| |/
144 ||--+ in ----|
148 This configuration is normally used as a way to achieve one of two things:
150 - Level-shifting: to reach a logical level higher than that of the silicon
153 - Inverse wire-OR on an I/O line, for example a GPIO line, making it possible
155 to the same line is simultaneously driving it high. A special case of this
156 is driving the SCL and SDA lines of an I2C bus, which is by definition a
157 wire-OR bus.
159 Both use cases require that the line be equipped with a pull-up resistor. This
163 The level on the line will go as high as the VDD on the pull-up resistor, which
164 may be higher than the level supported by the transistor, achieving a
165 level-shift to the higher VDD.
167 Integrated electronics often have an output driver stage in the form of a CMOS
168 "totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
169 the line high and one of them drives the line low. This is called a push-pull
170 output. The "totem-pole" looks like so::
174 OD ||--+
175 +--/ ---o|| P-MOS-FET
176 | ||--+
177 IN --+ +----- out
178 | ||--+
179 +--/ ----|| N-MOS-FET
180 OS ||--+
184 The desired output signal (e.g. coming directly from some GPIO output register)
186 a push-pull circuit.
189 P-MOS or N-MOS transistor right after the split of the input. As you can see,
190 either transistor will go totally numb if this switch is open. The totem-pole
192 high or low respectively. That is usually how software-controlled open
195 Some GPIO hardware come in open drain / open source configuration. Some are
196 hard-wired lines that will only support open drain or open source no matter
197 what: there is only one transistor there. Some are software-configurable:
198 by flipping a bit in a register the output can be configured as open drain
202 By disabling the P-MOS transistor, the output can be driven between GND and
203 high impedance (open drain), and by disabling the N-MOS transistor, the output
205 a pull-up resistor is needed on the outgoing rail to complete the circuit, and
206 in the second case, a pull-down resistor is needed on the rail.
208 Hardware that supports open drain or open source or both, can implement a
209 special callback in the gpio_chip: .set_config() that takes a generic
211 open source or push-pull. This will happen in response to the
215 If this state can not be configured in hardware, i.e. if the GPIO hardware does
216 not support open drain/open source in hardware, the GPIO library will instead
217 use a trick: when a line is set as output, if the line is flagged as open
229 GPIO lines with pull up/down resistor support
230 ---------------------------------------------
232 A GPIO line can support pull-up/down using the .set_config() callback. This
233 means that a pull up or pull-down resistor is available on the output of the
234 GPIO line, and this resistor is software controlled.
236 In discrete designs, a pull-up or pull-down resistor is simply soldered on
243 switch a bit in a register enabling or disabling pull-up or pull-down.
245 If the GPIO line supports shunting in different resistance values for the
246 pull-up or pull-down resistor, the GPIO chip callback .set_config() will not
247 suffice. For these complex use cases, a combined GPIO chip and pin controller
248 need to be implemented, as the pin config interface of a pin controller
250 different pull-up or pull-down resistance values.
253 GPIO drivers providing IRQs
256 It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
257 most often cascaded off a parent interrupt controller, and in some special
258 cases the GPIO logic is melded with a SoC's primary interrupt controller.
260 The IRQ portions of the GPIO block are implemented using an irq_chip, using
261 the header <linux/irq.h>. So this combined driver is utilizing two sub-
262 systems simultaneously: gpio and irq.
265 is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
269 gpiod_to_irq() is just a convenience function to figure out the IRQ for a
270 certain GPIO line and should not be relied upon to have been called before
274 callbacks from the GPIO and irq_chip APIs. Do not rely on gpiod_to_irq() having
277 We can divide GPIO irqchips in two broad categories:
279 - CASCADED INTERRUPT CHIPS: this means that the GPIO chip has one common
280 interrupt output line, which is triggered by any enabled GPIO line on that
284 inside the GPIO controller to figure out which line fired it. The irqchip
287 by clearing some bit (sometime implicitly, by just reading a status
292 - HIERARCHICAL INTERRUPT CHIPS: this means that each GPIO line has a dedicated
293 irq line to a parent interrupt controller one level up. There is no need
294 to inquire the GPIO hardware to figure out which line has fired, but it
298 Realtime considerations: a realtime compliant GPIO driver should not use
302 - spinlock_t should be replaced with raw_spinlock_t.[1]
303 - If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
308 Cascaded GPIO irqchips
309 ----------------------
311 Cascaded GPIO irqchips usually fall in one of three categories:
313 - CHAINED CASCADED GPIO IRQCHIPS: these are usually the type that is embedded on
314 an SoC. This means that there is a fast IRQ flow handler for the GPIOs that
315 gets called in a chain from the parent IRQ handler, most typically the
316 system interrupt controller. This means that the GPIO irqchip handler will
318 disabled. The GPIO irqchip will then end up calling something like this
326 Chained GPIO irqchips typically can NOT set the .can_sleep flag on
331 threaded on -RT. As a result, spinlock_t or any sleepable APIs (like PM
332 runtime) can't be used in a chained IRQ handler.
334 If required (and if it can't be converted to the nested threaded GPIO irqchip,
335 see below) a chained IRQ handler can be converted to generic irq handler and
336 this way it will become a threaded IRQ handler on -RT and a hard IRQ handler
337 on non-RT (for example, see [3]).
341 forced to a thread. The "fake?" raw lock can be used to work around this
347 raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags);
348 generic_handle_irq(irq_find_mapping(bank->chip.irq.domain, bit));
349 raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags);
351 - GENERIC CHAINED GPIO IRQCHIPS: these are the same as "CHAINED GPIO irqchips",
352 but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
354 The GPIO irqchip will then end up calling something like this sequence in
358 for each detected GPIO IRQ
361 Realtime considerations: this kind of handlers will be forced threaded on -RT,
363 with IRQ enabled and the same work-around as for "CHAINED GPIO irqchips" can
366 - NESTED THREADED GPIO IRQCHIPS: these are off-chip GPIO expanders and any
367 other GPIO irqchip residing on the other side of a sleeping bus such as I2C
372 handled in a quick IRQ handler with IRQs disabled. Instead they need to spawn
373 a thread and then mask the parent IRQ line until the interrupt is handled
381 The hallmark of threaded GPIO irqchips is that they set the .can_sleep
389 Infrastructure helpers for GPIO irqchips
390 ----------------------------------------
392 To help out in handling the set-up and management of GPIO irqchips and the
396 provided. A big portion of overhead code will be managed by gpiolib,
397 under the assumption that your interrupts are 1-to-1-mapped to the
398 GPIO line index:
400 .. csv-table::
401 :header: GPIO line offset, Hardware IRQ
407 ngpio-1, ngpio-1
410 If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask
417 same time as setting up the rest of the GPIO functionality. The following
418 is a typical example of a chained cascaded interrupt handler using
422 .. code-block:: c
470 /* Provide the gpio resource callbacks */
478 /* Get a pointer to the gpio_irq_chip */
479 girq = &g->gc.irq;
481 girq->parent_handler = ftgpio_gpio_irq_handler;
482 girq->num_parents = 1;
483 girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
485 if (!girq->parents)
486 return -ENOMEM;
487 girq->default_type = IRQ_TYPE_NONE;
488 girq->handler = handle_bad_irq;
489 girq->parents[0] = irq;
491 return devm_gpiochip_add_data(dev, &g->gc, g);
496 .. code-block:: c
544 /* Provide the gpio resource callbacks */
553 IRQF_ONESHOT, "my-chip", g);
557 /* Get a pointer to the gpio_irq_chip */
558 girq = &g->gc.irq;
561 girq->parent_handler = NULL;
562 girq->num_parents = 0;
563 girq->parents = NULL;
564 girq->default_type = IRQ_TYPE_NONE;
565 girq->handler = handle_bad_irq;
567 return devm_gpiochip_add_data(dev, &g->gc, g);
570 In this case the typical set-up will look like this:
572 .. code-block:: c
624 /* Provide the gpio resource callbacks */
631 /* Get a pointer to the gpio_irq_chip */
632 girq = &g->gc.irq;
634 girq->default_type = IRQ_TYPE_NONE;
635 girq->handler = handle_bad_irq;
636 girq->fwnode = g->fwnode;
637 girq->parent_domain = parent;
638 girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq;
640 return devm_gpiochip_add_data(dev, &g->gc, g);
642 As you can see pretty similar, but you do not supply a parent handler for
643 the IRQ, instead a parent irqdomain, an fwnode for the hardware and
644 a function .child_to_parent_hwirq() that has the purpose of looking up
645 the parent hardware irq from a child (i.e. this gpio chip) hardware irq.
649 If there is a need to exclude certain GPIO lines from the IRQ domain handled by
652 .irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
653 bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
659 - Make sure to assign all relevant members of the struct gpio_chip so that
663 - Nominally set gpio_irq_chip.handler to handle_bad_irq. Then, if your irqchip
670 -----------------
672 Since GPIO and irq_chip are orthogonal, we can get conflicts between different
673 use cases. For example a GPIO line used for IRQs should be an input line,
674 it does not make sense to fire interrupts on an output GPIO.
677 resource (a certain GPIO line and register for example) it needs to deny
680 Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
681 to mark the GPIO as being used as an IRQ::
685 This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
690 When implementing an irqchip inside a GPIO driver, these two functions should
699 ---------------------------
701 In some (fringe) use cases, a driver may be using a GPIO line as input for IRQs,
706 When a GPIO is used as an IRQ signal, then gpiolib also needs to know if
712 This allows drivers to drive the GPIO as an output while the IRQ is
713 disabled. When the IRQ is enabled again, a driver should call::
717 When implementing an irqchip inside a GPIO driver, these two functions should
726 Real-Time compliance for GPIO IRQ chips
727 ---------------------------------------
729 Any provider of irqchips needs to be carefully tailored to support Real-Time
730 preemption. It is desirable that all irqchips in the GPIO subsystem keep this
731 in mind and do the proper testing to assure they are real time-enabled.
735 The following is a checklist to follow when preparing a driver for real-time
738 - ensure spinlock_t is not used as part irq_chip implementation
739 - ensure that sleepable APIs are not used as part irq_chip implementation
742 - Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
744 - Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
745 apply corresponding work-around
746 - Chained GPIO irqchips: get rid of the chained IRQ handler and use generic irq
748 - regmap_mmio: it is possible to disable internal locking in regmap by setting
749 .disable_locking and handling the locking in the GPIO driver
750 - Test your driver with the appropriate in-kernel real-time test cases for both
753 * [1] http://www.spinics.net/lists/linux-omap/msg120425.html
754 * [2] https://lore.kernel.org/r/1443209283-20781-2-git-send-email-grygorii.strashko@ti.com
755 * [3] https://lore.kernel.org/r/1443209283-20781-3-git-send-email-grygorii.strashko@ti.com
758 Requesting self-owned GPIO pins
761 Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
762 descriptors through the gpiolib API. A GPIO driver can use the following
776 count. Do not use the functions to request gpio descriptors not owned by the