Lines Matching +full:irq +full:- +full:push +full:- +full:pull
6 describes the new descriptor-based interface. For a description of the
7 deprecated integer-based GPIO interface please refer to gpio-legacy.txt.
30 So for example one platform could use numbers 32-159 for GPIOs, with a
32 numbers 0..63 with one set of GPIO controllers, 64-79 with another type of GPIO
33 controller, and on one particular board 80-95 with an FPGA. The numbers need not
34 be contiguous; either of those platforms could also use numbers 2000-2063 to
45 - methods to establish GPIO line direction
46 - methods used to access GPIO line values
47 - method to set electrical configuration for a given GPIO line
48 - method to return the IRQ number associated to a given GPIO line
49 - flag saying whether calls to its methods may sleep
50 - optional line names array to identify lines
51 - optional debugfs dump method (showing extra state like pullup config)
52 - optional base number (will be automatically assigned if omitted)
53 - optional label for diagnostics and GPIO chip mapping using platform data
61 Often a gpio_chip is part of an instance-specific structure with states not
63 Chips such as audio codecs will have complex non-GPIO states.
72 on -RT (inside hard IRQ handlers and similar contexts). Normally this should
77 -----------------------------
81 single-ended modes (open drain/open source). These settings are described
88 ending up in the pin control back-end "behind" the GPIO controller, usually
92 If a pin controller back-end is used, the GPIO controller or hardware
94 numbers on the pin controller so they can properly cross-reference each other.
98 ---------------------------
115 ------------------------------------
119 is not open, it will present a high-impedance (tristate) to the external rail::
124 ||--- out +--- out
125 in ----|| |/
126 ||--+ in ----|
132 - Level-shifting: to reach a logical level higher than that of the silicon
135 - inverse wire-OR on an I/O line, for example a GPIO line, making it possible
139 wire-OR bus.
141 Both usecases require that the line be equipped with a pull-up resistor. This
145 The level on the line will go as high as the VDD on the pull-up resistor, which
147 level-shift to the higher VDD.
150 "totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
151 the line high and one of them drives the line low. This is called a push-pull
152 output. The "totem-pole" looks like so::
156 OD ||--+
157 +--/ ---o|| P-MOS-FET
158 | ||--+
159 IN --+ +----- out
160 | ||--+
161 +--/ ----|| N-MOS-FET
162 OS ||--+
168 a push-pull circuit.
171 P-MOS or N-MOS transistor right after the split of the input. As you can see,
172 either transistor will go totally numb if this switch is open. The totem-pole
174 high or low respectively. That is usually how software-controlled open
178 hard-wired lines that will only support open drain or open source no matter
179 what: there is only one transistor there. Some are software-configurable:
184 By disabling the P-MOS transistor, the output can be driven between GND and
185 high impedance (open drain), and by disabling the N-MOS transistor, the output
187 a pull-up resistor is needed on the outgoing rail to complete the circuit, and
188 in the second case, a pull-down resistor is needed on the rail.
193 open source or push-pull. This will happen in response to the
212 ---------------------------
217 The IRQ portions of the GPIO block are implemented using an irqchip, using
218 the header <linux/irq.h>. So basically such a driver is utilizing two sub-
219 systems simultaneously: gpio and irq.
232 an SoC. This means that there is a fast IRQ flow handler for the GPIOs that
233 gets called in a chain from the parent IRQ handler, most typically the
239 static irqreturn_t foo_gpio_irq(int irq, void *data)
248 RT_FULL: Note, chained IRQ handlers will not be forced threaded on -RT.
250 in chained IRQ handler.
252 a chained IRQ handler can be converted to generic irq handler and this way
253 it will be a threaded IRQ handler on -RT and a hard IRQ handler on non-RT
255 Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled,
256 so the IRQ core will complain if it is called from an IRQ handler which is
260 static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
262 raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags);
263 generic_handle_irq(irq_find_mapping(bank->chip.irq.domain, bit));
264 raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags);
267 but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
268 performed by generic IRQ handler which is configured using request_irq().
272 static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
273 for each detected GPIO IRQ
276 RT_FULL: Such kind of handlers will be forced threaded on -RT, as result IRQ
277 core will complain that generic_handle_irq() is called with IRQ enabled and
280 * NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
282 such drivers that need slow bus traffic to read out IRQ status and similar,
284 in a quick IRQ handler with IRQs disabled. Instead they need to spawn a
285 thread and then mask the parent IRQ line until the interrupt is handled
289 static irqreturn_t foo_gpio_irq(int irq, void *data)
291 handle_nested_irq(irq);
297 To help out in handling the set-up and management of GPIO irqchips and the
303 the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
306 (See Documentation/driver-model/design-patterns.txt)
311 * gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
312 gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
316 * gpiochip_set_nested_irqchip(): sets up a nested irq handler for a
317 gpio_chip from a parent IRQ. As the parent IRQ has usually been
319 mark all the child IRQs as having the other IRQ as parent.
321 If there is a need to exclude certain GPIOs from the IRQ domain, you can
322 set .irq.need_valid_mask of the gpiochip before gpiochip_add_data() is
323 called. This allocates an .irq.valid_mask with as many bits set as there
330 - Make sure to assign all relevant members of the struct gpio_chip so that
334 - Nominally set all handlers to handle_bad_irq() in the setup call and pass
337 before using/enabling GPIO IRQ. Then set the handler to handle_level_irq()
341 It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
342 if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
346 gpiod_to_irq() is just a convenience function to figure out the IRQ for a
348 the IRQ is used.
361 Locking IRQ usage
362 -----------------
363 Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
364 to mark the GPIO as being used as an IRQ::
368 This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
380 Real-Time compliance for GPIO IRQ chips
381 ---------------------------------------
385 in mind and do the proper testing to assure they are real time-enabled.
388 time-compliance:
390 - ensure spinlock_t is not used as part irq_chip implementation;
391 - ensure that sleepable APIs are not used as part irq_chip implementation.
394 - Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
395 from chained IRQ handler;
396 - Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
398 - Chained GPIO irqchips: get rid of chained IRQ handler and use generic irq
400 - regmap_mmio: Sry, but you are in trouble :( if MMIO regmap is used as for
401 GPIO IRQ chip implementation;
402 - Test your driver with the appropriate in-kernel real time test cases for both
406 Requesting self-owned GPIO pins
407 -------------------------------
427 * [1] http://www.spinics.net/lists/linux-omap/msg120425.html