GNU Linux-libre 5.15.72-gnu
[releases.git] / Documentation / driver-api / gpio / driver.rst
1 =====================
2 GPIO Driver Interface
3 =====================
4
5 This document serves as a guide for writers of GPIO chip drivers.
6
7 Each GPIO controller driver needs to include the following header, which defines
8 the structures used to define a GPIO driver::
9
10         #include <linux/gpio/driver.h>
11
12
13 Internal Representation of GPIOs
14 ================================
15
16 A GPIO chip handles one or more GPIO lines. To be considered a GPIO chip, the
17 lines must conform to the definition: General Purpose Input/Output. If 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.
23
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.
27
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
31 use hardware offsets 0..31 for these, corresponding to bits 0..31 in the
32 register.
33
34 This number is purely internal: the hardware number of a particular GPIO
35 line is never made visible outside of the driver.
36
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
41 number). Although the integer representation is considered deprecated, it still
42 has many users and thus needs to be maintained.
43
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
48 numbers need not be contiguous; either of those platforms could also use numbers
49 2000-2063 to identify GPIO lines in a bank of I2C GPIO expanders.
50
51
52 Controller Drivers: gpio_chip
53 =============================
54
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
57 common to each controller of that type, these should be assigned by the
58 driver code:
59
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
69
70 The code implementing a gpio_chip should support multiple instances of the
71 controller, preferably using the driver model. That code will configure each
72 gpio_chip and issue gpiochip_add(), gpiochip_add_data(), or
73 devm_gpiochip_add_data().  Removing a GPIO controller should be rare; use
74 gpiochip_remove() when it is unavoidable.
75
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.
79
80 Any debugfs dump method should normally ignore lines which haven't been
81 requested. They can use gpiochip_is_requested(), which returns either
82 NULL or the label associated with that GPIO line when it was requested.
83
84 Realtime considerations: the GPIO driver should not use spinlock_t or any
85 sleepable APIs (like PM runtime) in its gpio_chip implementation (.get/.set
86 and direction control callbacks) if it is expected to call GPIO APIs from
87 atomic context on realtime kernels (inside hard IRQ handlers and similar
88 contexts). Normally this should not be required.
89
90
91 GPIO electrical configuration
92 -----------------------------
93
94 GPIO lines can be configured for several electrical modes of operation by using
95 the .set_config() callback. Currently this API supports setting:
96
97 - Debouncing
98 - Single-ended modes (open drain/open source)
99 - Pull up and pull down resistor enablement
100
101 These settings are described below.
102
103 The .set_config() callback uses the same enumerators and configuration
104 semantics as the generic pin control drivers. This is not a coincidence: it is
105 possible to assign the .set_config() to the function gpiochip_generic_config()
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
108 closer to the actual pins. This way the pin controller can manage the below
109 listed GPIO configurations.
110
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.
114
115
116 GPIO lines with debounce support
117 --------------------------------
118
119 Debouncing is a configuration set to a pin indicating that it is connected to
120 a mechanical switch or button, or similar that may bounce. Bouncing means the
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 fireing repeatedly
123 unless the line is debounced.
124
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
127 still has the same value (low or high). This could also be repeated by a clever
128 state machine, waiting for a line to become stable. In either case, it sets
129 a certain number of milliseconds for debouncing, or just "on/off" if that time
130 is not configurable.
131
132
133 GPIO lines with open drain/source support
134 -----------------------------------------
135
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::
139
140
141    CMOS CONFIGURATION      TTL CONFIGURATION
142
143             ||--- out              +--- out
144      in ----||                   |/
145             ||--+         in ----|
146                 |                |\
147                GND                 GND
148
149 This configuration is normally used as a way to achieve one of two things:
150
151 - Level-shifting: to reach a logical level higher than that of the silicon
152   where the output resides.
153
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
157   is driving the SCL and SDA lines of an I2C bus, which is by definition a
158   wire-OR bus.
159
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
162 the rail actively pulls it down.
163
164 The level on the line will go as high as the VDD on the pull-up resistor, which
165 may be higher than the level supported by the transistor, achieving a
166 level-shift to the higher VDD.
167
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::
172
173                      VDD
174                       |
175             OD    ||--+
176          +--/ ---o||     P-MOS-FET
177          |        ||--+
178     IN --+            +----- out
179          |        ||--+
180          +--/ ----||     N-MOS-FET
181             OS    ||--+
182                       |
183                      GND
184
185 The desired output signal (e.g. coming directly from some GPIO output register)
186 arrives at IN. The switches named "OD" and "OS" are normally closed, creating
187 a push-pull circuit.
188
189 Consider the little "switches" named "OD" and "OS" that enable/disable the
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
194 drain/source works.
195
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.
202
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.
208
209 Hardware that supports open drain or open source or both, can implement a
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
214 from other hardware descriptions.
215
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,
221 instead it will be switched to input, as input mode is high impedance, thus
222 achieveing an "open drain emulation" of sorts: electrically the behaviour will
223 be identical, with the exception of possible hardware glitches when switching
224 the mode of the line.
225
226 For open source configuration the same principle is used, just that instead
227 of actively driving the line low, it is set to input.
228
229
230 GPIO lines with pull up/down resistor support
231 ---------------------------------------------
232
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.
236
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
239 most you will think about these lines is that they will very likely be
240 configured as open drain or open source (see the section above).
241
242 The .set_config() callback can only turn pull up or down on and off, and will
243 no have any semantic knowledge about the resistance used. It will only say
244 switch a bit in a register enabling or disabling pull-up or pull-down.
245
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
249 need to be implemented, as the pin config interface of a pin controller
250 supports more versatile control over electrical properties and can handle
251 different pull-up or pull-down resistance values.
252
253
254 GPIO drivers providing IRQs
255 ===========================
256
257 It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
258 most often cascaded off a parent interrupt controller, and in some special
259 cases the GPIO logic is melded with a SoC's primary interrupt controller.
260
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.
264
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
267 irq_chip are orthogonal, and offering their services independent of each
268 other.
269
270 gpiod_to_irq() is just a convenience function to figure out the IRQ for a
271 certain GPIO line and should not be relied upon to have been called before
272 the IRQ is used.
273
274 Always prepare the hardware and make it ready for action in respective
275 callbacks from the GPIO and irq_chip APIs. Do not rely on gpiod_to_irq() having
276 been called first.
277
278 We can divide GPIO irqchips in two broad categories:
279
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
284   interrupt controller. This is modeled by an irqchip that will inspect bits
285   inside the GPIO controller to figure out which line fired it. The irqchip
286   part of the driver needs to inspect registers to figure this out and it
287   will likely also need to acknowledge that it is handling the interrupt
288   by clearing some bit (sometime implicitly, by just reading a status
289   register) and it will often need to set up the configuration such as
290   edge sensitivity (rising or falling edge, or high/low level interrupt for
291   example).
292
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
296   may still be necessary to acknowledge the interrupt and set up configuration
297   such as edge sensitivity.
298
299 Realtime considerations: a realtime compliant GPIO driver should not use
300 spinlock_t or any sleepable APIs (like PM runtime) as part of its irqchip
301 implementation.
302
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()
305   and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks
306   on an irqchip. Create the callbacks if needed.[2]
307
308
309 Cascaded GPIO irqchips
310 ----------------------
311
312 Cascaded GPIO irqchips usually fall in one of three categories:
313
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
317   system interrupt controller. This means that the GPIO irqchip handler will
318   be called immediately from the parent irqchip, while holding the IRQs
319   disabled. The GPIO irqchip will then end up calling something like this
320   sequence in its interrupt handler::
321
322     static irqreturn_t foo_gpio_irq(int irq, void *data)
323         chained_irq_enter(...);
324         generic_handle_irq(...);
325         chained_irq_exit(...);
326
327   Chained GPIO irqchips typically can NOT set the .can_sleep flag on
328   struct gpio_chip, as everything happens directly in the callbacks: no
329   slow bus traffic like I2C can be used.
330
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.
334
335   If required (and if it can't be converted to the nested threaded GPIO irqchip,
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]).
339
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
342   forced to a thread. The "fake?" raw lock can be used to work around this
343   problem::
344
345     raw_spinlock_t wa_lock;
346     static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
347         unsigned long wa_lock_flags;
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);
351
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().
355   The GPIO irqchip will then end up calling something like this sequence in
356   its interrupt handler::
357
358     static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
359         for each detected GPIO IRQ
360             generic_handle_irq(...);
361
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
365   be applied.
366
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
369   or SPI.
370
371   Of course such drivers that need slow bus traffic to read out IRQ status and
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
375   by the driver. The hallmark of this driver is to call something like
376   this in its interrupt handler::
377
378     static irqreturn_t foo_gpio_irq(int irq, void *data)
379         ...
380         handle_nested_irq(irq);
381
382   The hallmark of threaded GPIO irqchips is that they set the .can_sleep
383   flag on struct gpio_chip to true, indicating that this chip may sleep
384   when accessing the GPIOs.
385
386   These kinds of irqchips are inherently realtime tolerant as they are
387   already set up to handle sleeping contexts.
388
389
390 Infrastructure helpers for GPIO irqchips
391 ----------------------------------------
392
393 To help out in handling the set-up and management of GPIO irqchips and the
394 associated irqdomain and resource allocation callbacks. These are activated
395 by selecting the Kconfig symbol GPIOLIB_IRQCHIP. If the symbol
396 IRQ_DOMAIN_HIERARCHY is also selected, hierarchical helpers will also be
397 provided. A big portion of overhead code will be managed by gpiolib,
398 under the assumption that your interrupts are 1-to-1-mapped to the
399 GPIO line index:
400
401 .. csv-table::
402     :header: GPIO line offset, Hardware IRQ
403
404     0,0
405     1,1
406     2,2
407     ...,...
408     ngpio-1, ngpio-1
409
410
411 If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask
412 and the flag need_valid_mask in gpio_irq_chip can be used to mask off some
413 lines as invalid for associating with IRQs.
414
415 The preferred way to set up the helpers is to fill in the
416 struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip.
417 If you do this, the additional irq_chip will be set up by gpiolib at the
418 same time as setting up the rest of the GPIO functionality. The following
419 is a typical example of a chained cascaded interrupt handler using
420 the gpio_irq_chip:
421
422 .. code-block:: c
423
424   /* Typical state container with dynamic irqchip */
425   struct my_gpio {
426       struct gpio_chip gc;
427       struct irq_chip irq;
428   };
429
430   int irq; /* from platform etc */
431   struct my_gpio *g;
432   struct gpio_irq_chip *girq;
433
434   /* Set up the irqchip dynamically */
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;
440
441   /* Get a pointer to the gpio_irq_chip */
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),
447                                GFP_KERNEL);
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;
453
454   return devm_gpiochip_add_data(dev, &g->gc, g);
455
456 The helper supports using threaded interrupts as well. Then you just request
457 the interrupt separately and go with it:
458
459 .. code-block:: c
460
461   /* Typical state container with dynamic irqchip */
462   struct my_gpio {
463       struct gpio_chip gc;
464       struct irq_chip irq;
465   };
466
467   int irq; /* from platform etc */
468   struct my_gpio *g;
469   struct gpio_irq_chip *girq;
470
471   /* Set up the irqchip dynamically */
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;
477
478   ret = devm_request_threaded_irq(dev, irq, NULL,
479                 irq_thread_fn, IRQF_ONESHOT, "my-chip", g);
480   if (ret < 0)
481         return ret;
482
483   /* Get a pointer to the gpio_irq_chip */
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;
492
493   return devm_gpiochip_add_data(dev, &g->gc, g);
494
495 The helper supports using hierarchical interrupt controllers as well.
496 In this case the typical set-up will look like this:
497
498 .. code-block:: c
499
500   /* Typical state container with dynamic irqchip */
501   struct my_gpio {
502       struct gpio_chip gc;
503       struct irq_chip irq;
504       struct fwnode_handle *fwnode;
505   };
506
507   int irq; /* from platform etc */
508   struct my_gpio *g;
509   struct gpio_irq_chip *girq;
510
511   /* Set up the irqchip dynamically */
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;
517
518   /* Get a pointer to the gpio_irq_chip */
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;
526
527   return devm_gpiochip_add_data(dev, &g->gc, g);
528
529 As you can see pretty similar, but you do not supply a parent handler for
530 the IRQ, instead a parent irqdomain, an fwnode for the hardware and
531 a funcion .child_to_parent_hwirq() that has the purpose of looking up
532 the parent hardware irq from a child (i.e. this gpio chip) hardware irq.
533 As always it is good to look at examples in the kernel tree for advice
534 on how to find the required pieces.
535
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
538 devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an
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
541 from this mask. The mask can be filled in the init_valid_mask() callback
542 that is part of the struct gpio_irq_chip.
543
544 To use the helpers please keep the following in mind:
545
546 - Make sure to assign all relevant members of the struct gpio_chip so that
547   the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
548   properly.
549
550 - Nominally set gpio_irq_chip.handler to handle_bad_irq. Then, if your irqchip
551   is cascaded, set the handler to handle_level_irq() and/or handle_edge_irq()
552   in the irqchip .set_type() callback depending on what your controller
553   supports and what is requested by the consumer.
554
555
556 Locking IRQ usage
557 -----------------
558
559 Since GPIO and irq_chip are orthogonal, we can get conflicts between different
560 use cases. For example a GPIO line used for IRQs should be an input line,
561 it does not make sense to fire interrupts on an output GPIO.
562
563 If there is competition inside the subsystem which side is using the
564 resource (a certain GPIO line and register for example) it needs to deny
565 certain operations and keep track of usage inside of the gpiolib subsystem.
566
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::
569
570         int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
571
572 This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
573 is released::
574
575         void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
576
577 When implementing an irqchip inside a GPIO driver, these two functions should
578 typically be called in the .startup() and .shutdown() callbacks from the
579 irqchip.
580
581 When using the gpiolib irqchip helpers, these callbacks are automatically
582 assigned.
583
584
585 Disabling and enabling IRQs
586 ---------------------------
587
588 In some (fringe) use cases, a driver may be using a GPIO line as input for IRQs,
589 but occasionally switch that line over to drive output and then back to being
590 an input with interrupts again. This happens on things like CEC (Consumer
591 Electronics Control).
592
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,
595 the irqchip driver should call::
596
597         void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset)
598
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::
601
602         void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset)
603
604 When implementing an irqchip inside a GPIO driver, these two functions should
605 typically be called in the .irq_disable() and .irq_enable() callbacks from the
606 irqchip.
607
608 When using the gpiolib irqchip helpers, these callbacks are automatically
609 assigned.
610
611
612 Real-Time compliance for GPIO IRQ chips
613 ---------------------------------------
614
615 Any provider of irqchips needs to be carefully tailored to support Real-Time
616 preemption. It is desirable that all irqchips in the GPIO subsystem keep this
617 in mind and do the proper testing to assure they are real time-enabled.
618
619 So, pay attention on above realtime considerations in the documentation.
620
621 The following is a checklist to follow when preparing a driver for real-time
622 compliance:
623
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
626   If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
627   and .irq_bus_unlock() callbacks
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
633   handler if possible
634 - regmap_mmio: it is possible to disable internal locking in regmap by setting
635   .disable_locking and handling the locking in the GPIO driver
636 - Test your driver with the appropriate in-kernel real-time test cases for both
637   level and edge IRQs
638
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
642
643
644 Requesting self-owned GPIO pins
645 ===============================
646
647 Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
648 descriptors through the gpiolib API. A GPIO driver can use the following
649 functions to request and free descriptors::
650
651         struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
652                                                     u16 hwnum,
653                                                     const char *label,
654                                                     enum gpiod_flags flags)
655
656         void gpiochip_free_own_desc(struct gpio_desc *desc)
657
658 Descriptors requested with gpiochip_request_own_desc() must be released with
659 gpiochip_free_own_desc().
660
661 These functions must be used with care since they do not affect module use
662 count. Do not use the functions to request gpio descriptors not owned by the
663 calling driver.