Lines Matching +full:irq +full:- +full:push +full:- +full:pull
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
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.
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.
87 atomic context on realtime kernels (inside hard IRQ handlers and similar
92 -----------------------------
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
111 If a pin controller back-end is used, the GPIO controller or hardware
113 numbers on the pin controller so they can properly cross-reference each other.
117 --------------------------------
134 -----------------------------------------
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 ||--+
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
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:
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
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.
212 open source or push-pull. This will happen in response to the
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
237 In discrete designs, a pull-up or pull-down resistor is simply soldered on
242 The .set_config() callback can only turn pull up or down on and off, and will
244 switch a bit in a register enabling or disabling pull-up or pull-down.
247 pull-up or pull-down resistor, the GPIO chip callback .set_config() will not
251 different pull-up or pull-down resistance values.
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.
265 It is legal for any IRQ consumer to request an IRQ from any irqchip even if it
266 is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
270 gpiod_to_irq() is just a convenience function to figure out the IRQ for a
272 the IRQ is used.
280 - CASCADED INTERRUPT CHIPS: this means that the GPIO chip has one common
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
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 ----------------------
314 - CHAINED CASCADED GPIO IRQCHIPS: these are usually the type that is embedded on
315 an SoC. This means that there is a fast IRQ flow handler for the GPIOs that
316 gets called in a chain from the parent IRQ handler, most typically the
322 static irqreturn_t foo_gpio_irq(int irq, void *data)
331 Realtime considerations: Note that chained IRQ handlers will not be forced
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.
336 see below) a chained IRQ handler can be converted to generic irq handler and
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]).
340 The generic_handle_irq() is expected to be called with IRQ disabled,
341 so the IRQ core will complain if it is called from an IRQ handler which is
346 static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
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
354 performed by generic IRQ handler which is configured using request_irq().
358 static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
359 for each detected GPIO IRQ
362 Realtime considerations: this kind of handlers will be forced threaded on -RT,
363 and as result the IRQ core will complain that generic_handle_irq() is called
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
371 Of course such drivers that need slow bus traffic to read out IRQ status and
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
378 static irqreturn_t foo_gpio_irq(int irq, void *data)
380 handle_nested_irq(irq);
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
401 .. csv-table::
402 :header: GPIO line offset, Hardware IRQ
408 ngpio-1, ngpio-1
422 .. code-block:: c
427 struct irq_chip irq;
430 int irq; /* from platform etc */
435 g->irq.name = "my_gpio_irq";
436 g->irq.irq_ack = my_gpio_ack_irq;
437 g->irq.irq_mask = my_gpio_mask_irq;
438 g->irq.irq_unmask = my_gpio_unmask_irq;
439 g->irq.irq_set_type = my_gpio_set_irq_type;
442 girq = &g->gc.irq;
443 girq->chip = &g->irq;
444 girq->parent_handler = ftgpio_gpio_irq_handler;
445 girq->num_parents = 1;
446 girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
448 if (!girq->parents)
449 return -ENOMEM;
450 girq->default_type = IRQ_TYPE_NONE;
451 girq->handler = handle_bad_irq;
452 girq->parents[0] = irq;
454 return devm_gpiochip_add_data(dev, &g->gc, g);
459 .. code-block:: c
464 struct irq_chip irq;
467 int irq; /* from platform etc */
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;
478 ret = devm_request_threaded_irq(dev, irq, NULL,
479 irq_thread_fn, IRQF_ONESHOT, "my-chip", g);
484 girq = &g->gc.irq;
485 girq->chip = &g->irq;
486 /* This will let us handle the parent IRQ in the driver */
487 girq->parent_handler = NULL;
488 girq->num_parents = 0;
489 girq->parents = NULL;
490 girq->default_type = IRQ_TYPE_NONE;
491 girq->handler = handle_bad_irq;
493 return devm_gpiochip_add_data(dev, &g->gc, g);
496 In this case the typical set-up will look like this:
498 .. code-block:: c
503 struct irq_chip irq;
507 int irq; /* from platform etc */
512 g->irq.name = "my_gpio_irq";
513 g->irq.irq_ack = my_gpio_ack_irq;
514 g->irq.irq_mask = my_gpio_mask_irq;
515 g->irq.irq_unmask = my_gpio_unmask_irq;
516 g->irq.irq_set_type = my_gpio_set_irq_type;
519 girq = &g->gc.irq;
520 girq->chip = &g->irq;
521 girq->default_type = IRQ_TYPE_NONE;
522 girq->handler = handle_bad_irq;
523 girq->fwnode = g->fwnode;
524 girq->parent_domain = parent;
525 girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq;
527 return devm_gpiochip_add_data(dev, &g->gc, g);
530 the IRQ, instead a parent irqdomain, an fwnode for the hardware and
532 the parent hardware irq from a child (i.e. this gpio chip) hardware irq.
536 If there is a need to exclude certain GPIO lines from the IRQ domain handled by
537 these helpers, we can set .irq.need_valid_mask of the gpiochip before
539 .irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
540 bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
546 - Make sure to assign all relevant members of the struct gpio_chip so that
550 - Nominally set gpio_irq_chip.handler to handle_bad_irq. Then, if your irqchip
556 Locking IRQ usage
557 -----------------
567 Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
568 to mark the GPIO as being used as an IRQ::
572 This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
586 ---------------------------
593 When a GPIO is used as an IRQ signal, then gpiolib also needs to know if
594 the IRQ is enabled or disabled. In order to inform gpiolib about this,
599 This allows drivers to drive the GPIO as an output while the IRQ is
600 disabled. When the IRQ is enabled again, a driver should call::
612 Real-Time compliance for GPIO IRQ chips
613 ---------------------------------------
615 Any provider of irqchips needs to be carefully tailored to support Real-Time
617 in mind and do the proper testing to assure they are real time-enabled.
621 The following is a checklist to follow when preparing a driver for real-time
624 - ensure spinlock_t is not used as part irq_chip implementation
625 - ensure that sleepable APIs are not used as part irq_chip implementation
628 - Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
629 from the chained IRQ handler
630 - Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
631 apply corresponding work-around
632 - Chained GPIO irqchips: get rid of the chained IRQ handler and use generic irq
634 - regmap_mmio: it is possible to disable internal locking in regmap by setting
636 - Test your driver with the appropriate in-kernel real-time test cases for both
639 * [1] http://www.spinics.net/lists/linux-omap/msg120425.html
640 * [2] https://lore.kernel.org/r/1443209283-20781-2-git-send-email-grygorii.strashko@ti.com
641 * [3] https://lore.kernel.org/r/1443209283-20781-3-git-send-email-grygorii.strashko@ti.com
644 Requesting self-owned GPIO pins