Loading...
1=====================
2GPIO Driver Interface
3=====================
4
5This document serves as a guide for writers of GPIO chip drivers.
6
7Each GPIO controller driver needs to include the following header, which defines
8the structures used to define a GPIO driver::
9
10 #include <linux/gpio/driver.h>
11
12
13Internal Representation of GPIOs
14================================
15
16A GPIO chip handles one or more GPIO lines. To be considered a GPIO chip, the
17lines must conform to the definition: General Purpose Input/Output. If the
18line is not general purpose, it is not GPIO and should not be handled by a
19GPIO chip. The use case is the indicative: certain lines in a system may be
20called GPIO but serve a very particular purpose thus not meeting the criteria
21of a general purpose I/O. On the other hand a LED driver line may be used as a
22GPIO and should therefore still be handled by a GPIO chip driver.
23
24Inside a GPIO driver, individual GPIO lines are identified by their hardware
25number, sometime also referred to as ``offset``, which is a unique number
26between 0 and n-1, n being the number of GPIOs managed by the chip.
27
28The hardware GPIO number should be something intuitive to the hardware, for
29example if a system uses a memory-mapped set of I/O-registers where 32 GPIO
30lines are handled by one bit per line in a 32-bit register, it makes sense to
31use hardware offsets 0..31 for these, corresponding to bits 0..31 in the
32register.
33
34This number is purely internal: the hardware number of a particular GPIO
35line is never made visible outside of the driver.
36
37On top of this internal number, each GPIO line also needs to have a global
38number in the integer GPIO namespace so that it can be used with the legacy GPIO
39interface. Each chip must thus have a "base" number (which can be automatically
40assigned), and for each GPIO line the global number will be (base + hardware
41number). Although the integer representation is considered deprecated, it still
42has many users and thus needs to be maintained.
43
44So for example one platform could use global numbers 32-159 for GPIOs, with a
45controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
46global numbers 0..63 with one set of GPIO controllers, 64-79 with another type
47of GPIO controller, and on one particular board 80-95 with an FPGA. The legacy
48numbers need not be contiguous; either of those platforms could also use numbers
492000-2063 to identify GPIO lines in a bank of I2C GPIO expanders.
50
51
52Controller Drivers: gpio_chip
53=============================
54
55In the gpiolib framework each GPIO controller is packaged as a "struct
56gpio_chip" (see <linux/gpio/driver.h> for its complete definition) with members
57common to each controller of that type, these should be assigned by the
58driver 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
70The code implementing a gpio_chip should support multiple instances of the
71controller, preferably using the driver model. That code will configure each
72gpio_chip and issue gpiochip_add(), gpiochip_add_data(), or
73devm_gpiochip_add_data(). Removing a GPIO controller should be rare; use
74gpiochip_remove() when it is unavoidable.
75
76Often a gpio_chip is part of an instance-specific structure with states not
77exposed by the GPIO interfaces, such as addressing, power management, and more.
78Chips such as audio codecs will have complex non-GPIO states.
79
80Any debugfs dump method should normally ignore lines which haven't been
81requested. They can use gpiochip_is_requested(), which returns either
82NULL or the label associated with that GPIO line when it was requested.
83
84Realtime considerations: the GPIO driver should not use spinlock_t or any
85sleepable APIs (like PM runtime) in its gpio_chip implementation (.get/.set
86and direction control callbacks) if it is expected to call GPIO APIs from
87atomic context on realtime kernels (inside hard IRQ handlers and similar
88contexts). Normally this should not be required.
89
90
91GPIO electrical configuration
92-----------------------------
93
94GPIO lines can be configured for several electrical modes of operation by using
95the .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
101These settings are described below.
102
103The .set_config() callback uses the same enumerators and configuration
104semantics as the generic pin control drivers. This is not a coincidence: it is
105possible to assign the .set_config() to the function gpiochip_generic_config()
106which will result in pinctrl_gpio_set_config() being called and eventually
107ending up in the pin control back-end "behind" the GPIO controller, usually
108closer to the actual pins. This way the pin controller can manage the below
109listed GPIO configurations.
110
111If a pin controller back-end is used, the GPIO controller or hardware
112description needs to provide "GPIO ranges" mapping the GPIO line offsets to pin
113numbers on the pin controller so they can properly cross-reference each other.
114
115
116GPIO lines with debounce support
117--------------------------------
118
119Debouncing is a configuration set to a pin indicating that it is connected to
120a mechanical switch or button, or similar that may bounce. Bouncing means the
121line is pulled high/low quickly at very short intervals for mechanical
122reasons. This can result in the value being unstable or irqs firing repeatedly
123unless the line is debounced.
124
125Debouncing in practice involves setting up a timer when something happens on
126the line, wait a little while and then sample the line again, so see if it
127still has the same value (low or high). This could also be repeated by a clever
128state machine, waiting for a line to become stable. In either case, it sets
129a certain number of milliseconds for debouncing, or just "on/off" if that time
130is not configurable.
131
132
133GPIO lines with open drain/source support
134-----------------------------------------
135
136Open drain (CMOS) or open collector (TTL) means the line is not actively driven
137high: instead you provide the drain/collector as output, so when the transistor
138is 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
149This 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
160Both use cases require that the line be equipped with a pull-up resistor. This
161resistor will make the line tend to high level unless one of the transistors on
162the rail actively pulls it down.
163
164The level on the line will go as high as the VDD on the pull-up resistor, which
165may be higher than the level supported by the transistor, achieving a
166level-shift to the higher VDD.
167
168Integrated 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
170the line high and one of them drives the line low. This is called a push-pull
171output. 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
185The desired output signal (e.g. coming directly from some GPIO output register)
186arrives at IN. The switches named "OD" and "OS" are normally closed, creating
187a push-pull circuit.
188
189Consider the little "switches" named "OD" and "OS" that enable/disable the
190P-MOS or N-MOS transistor right after the split of the input. As you can see,
191either transistor will go totally numb if this switch is open. The totem-pole
192is then halved and give high impedance instead of actively driving the line
193high or low respectively. That is usually how software-controlled open
194drain/source works.
195
196Some GPIO hardware come in open drain / open source configuration. Some are
197hard-wired lines that will only support open drain or open source no matter
198what: there is only one transistor there. Some are software-configurable:
199by flipping a bit in a register the output can be configured as open drain
200or open source, in practice by flicking open the switches labeled "OD" and "OS"
201in the drawing above.
202
203By disabling the P-MOS transistor, the output can be driven between GND and
204high impedance (open drain), and by disabling the N-MOS transistor, the output
205can be driven between VDD and high impedance (open source). In the first case,
206a pull-up resistor is needed on the outgoing rail to complete the circuit, and
207in the second case, a pull-down resistor is needed on the rail.
208
209Hardware that supports open drain or open source or both, can implement a
210special callback in the gpio_chip: .set_config() that takes a generic
211pinconf packed value telling whether to configure the line as open drain,
212open source or push-pull. This will happen in response to the
213GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag set in the machine file, or coming
214from other hardware descriptions.
215
216If this state can not be configured in hardware, i.e. if the GPIO hardware does
217not support open drain/open source in hardware, the GPIO library will instead
218use a trick: when a line is set as output, if the line is flagged as open
219drain, and the IN output value is low, it will be driven low as usual. But
220if the IN output value is set to high, it will instead *NOT* be driven high,
221instead it will be switched to input, as input mode is an equivalent to
222high impedance, thus achieving an "open drain emulation" of sorts: electrically
223the behaviour will be identical, with the exception of possible hardware glitches
224when switching the mode of the line.
225
226For open source configuration the same principle is used, just that instead
227of actively driving the line low, it is set to input.
228
229
230GPIO lines with pull up/down resistor support
231---------------------------------------------
232
233A GPIO line can support pull-up/down using the .set_config() callback. This
234means that a pull up or pull-down resistor is available on the output of the
235GPIO line, and this resistor is software controlled.
236
237In discrete designs, a pull-up or pull-down resistor is simply soldered on
238the circuit board. This is not something we deal with or model in software. The
239most you will think about these lines is that they will very likely be
240configured as open drain or open source (see the section above).
241
242The .set_config() callback can only turn pull up or down on and off, and will
243no have any semantic knowledge about the resistance used. It will only say
244switch a bit in a register enabling or disabling pull-up or pull-down.
245
246If the GPIO line supports shunting in different resistance values for the
247pull-up or pull-down resistor, the GPIO chip callback .set_config() will not
248suffice. For these complex use cases, a combined GPIO chip and pin controller
249need to be implemented, as the pin config interface of a pin controller
250supports more versatile control over electrical properties and can handle
251different pull-up or pull-down resistance values.
252
253
254GPIO drivers providing IRQs
255===========================
256
257It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
258most often cascaded off a parent interrupt controller, and in some special
259cases the GPIO logic is melded with a SoC's primary interrupt controller.
260
261The IRQ portions of the GPIO block are implemented using an irq_chip, using
262the header <linux/irq.h>. So this combined driver is utilizing two sub-
263systems simultaneously: gpio and irq.
264
265It is legal for any IRQ consumer to request an IRQ from any irqchip even if it
266is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
267irq_chip are orthogonal, and offering their services independent of each
268other.
269
270gpiod_to_irq() is just a convenience function to figure out the IRQ for a
271certain GPIO line and should not be relied upon to have been called before
272the IRQ is used.
273
274Always prepare the hardware and make it ready for action in respective
275callbacks from the GPIO and irq_chip APIs. Do not rely on gpiod_to_irq() having
276been called first.
277
278We 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
299Realtime considerations: a realtime compliant GPIO driver should not use
300spinlock_t or any sleepable APIs (like PM runtime) as part of its irqchip
301implementation.
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
309Cascaded GPIO irqchips
310----------------------
311
312Cascaded 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
390Infrastructure helpers for GPIO irqchips
391----------------------------------------
392
393To help out in handling the set-up and management of GPIO irqchips and the
394associated irqdomain and resource allocation callbacks. These are activated
395by selecting the Kconfig symbol GPIOLIB_IRQCHIP. If the symbol
396IRQ_DOMAIN_HIERARCHY is also selected, hierarchical helpers will also be
397provided. A big portion of overhead code will be managed by gpiolib,
398under the assumption that your interrupts are 1-to-1-mapped to the
399GPIO 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
411If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask
412and the flag need_valid_mask in gpio_irq_chip can be used to mask off some
413lines as invalid for associating with IRQs.
414
415The preferred way to set up the helpers is to fill in the
416struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip.
417If you do this, the additional irq_chip will be set up by gpiolib at the
418same time as setting up the rest of the GPIO functionality. The following
419is a typical example of a chained cascaded interrupt handler using
420the gpio_irq_chip. Note how the mask/unmask (or disable/enable) functions
421call into the core gpiolib code:
422
423.. code-block:: c
424
425 /* Typical state container */
426 struct my_gpio {
427 struct gpio_chip gc;
428 };
429
430 static void my_gpio_mask_irq(struct irq_data *d)
431 {
432 struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
433 irq_hw_number_t hwirq = irqd_to_hwirq(d);
434
435 /*
436 * Perform any necessary action to mask the interrupt,
437 * and then call into the core code to synchronise the
438 * state.
439 */
440
441 gpiochip_disable_irq(gc, hwirq);
442 }
443
444 static void my_gpio_unmask_irq(struct irq_data *d)
445 {
446 struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
447 irq_hw_number_t hwirq = irqd_to_hwirq(d);
448
449 gpiochip_enable_irq(gc, hwirq);
450
451 /*
452 * Perform any necessary action to unmask the interrupt,
453 * after having called into the core code to synchronise
454 * the state.
455 */
456 }
457
458 /*
459 * Statically populate the irqchip. Note that it is made const
460 * (further indicated by the IRQCHIP_IMMUTABLE flag), and that
461 * the GPIOCHIP_IRQ_RESOURCE_HELPER macro adds some extra
462 * callbacks to the structure.
463 */
464 static const struct irq_chip my_gpio_irq_chip = {
465 .name = "my_gpio_irq",
466 .irq_ack = my_gpio_ack_irq,
467 .irq_mask = my_gpio_mask_irq,
468 .irq_unmask = my_gpio_unmask_irq,
469 .irq_set_type = my_gpio_set_irq_type,
470 .flags = IRQCHIP_IMMUTABLE,
471 /* Provide the gpio resource callbacks */
472 GPIOCHIP_IRQ_RESOURCE_HELPERS,
473 };
474
475 int irq; /* from platform etc */
476 struct my_gpio *g;
477 struct gpio_irq_chip *girq;
478
479 /* Get a pointer to the gpio_irq_chip */
480 girq = &g->gc.irq;
481 gpio_irq_chip_set_chip(girq, &my_gpio_irq_chip);
482 girq->parent_handler = ftgpio_gpio_irq_handler;
483 girq->num_parents = 1;
484 girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
485 GFP_KERNEL);
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;
491
492 return devm_gpiochip_add_data(dev, &g->gc, g);
493
494The helper supports using threaded interrupts as well. Then you just request
495the interrupt separately and go with it:
496
497.. code-block:: c
498
499 /* Typical state container */
500 struct my_gpio {
501 struct gpio_chip gc;
502 };
503
504 static void my_gpio_mask_irq(struct irq_data *d)
505 {
506 struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
507 irq_hw_number_t hwirq = irqd_to_hwirq(d);
508
509 /*
510 * Perform any necessary action to mask the interrupt,
511 * and then call into the core code to synchronise the
512 * state.
513 */
514
515 gpiochip_disable_irq(gc, hwirq);
516 }
517
518 static void my_gpio_unmask_irq(struct irq_data *d)
519 {
520 struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
521 irq_hw_number_t hwirq = irqd_to_hwirq(d);
522
523 gpiochip_enable_irq(gc, hwirq);
524
525 /*
526 * Perform any necessary action to unmask the interrupt,
527 * after having called into the core code to synchronise
528 * the state.
529 */
530 }
531
532 /*
533 * Statically populate the irqchip. Note that it is made const
534 * (further indicated by the IRQCHIP_IMMUTABLE flag), and that
535 * the GPIOCHIP_IRQ_RESOURCE_HELPER macro adds some extra
536 * callbacks to the structure.
537 */
538 static const struct irq_chip my_gpio_irq_chip = {
539 .name = "my_gpio_irq",
540 .irq_ack = my_gpio_ack_irq,
541 .irq_mask = my_gpio_mask_irq,
542 .irq_unmask = my_gpio_unmask_irq,
543 .irq_set_type = my_gpio_set_irq_type,
544 .flags = IRQCHIP_IMMUTABLE,
545 /* Provide the gpio resource callbacks */
546 GPIOCHIP_IRQ_RESOURCE_HELPERS,
547 };
548
549 int irq; /* from platform etc */
550 struct my_gpio *g;
551 struct gpio_irq_chip *girq;
552
553 ret = devm_request_threaded_irq(dev, irq, NULL,
554 irq_thread_fn, IRQF_ONESHOT, "my-chip", g);
555 if (ret < 0)
556 return ret;
557
558 /* Get a pointer to the gpio_irq_chip */
559 girq = &g->gc.irq;
560 gpio_irq_chip_set_chip(girq, &my_gpio_irq_chip);
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;
567
568 return devm_gpiochip_add_data(dev, &g->gc, g);
569
570The helper supports using hierarchical interrupt controllers as well.
571In this case the typical set-up will look like this:
572
573.. code-block:: c
574
575 /* Typical state container with dynamic irqchip */
576 struct my_gpio {
577 struct gpio_chip gc;
578 struct fwnode_handle *fwnode;
579 };
580
581 static void my_gpio_mask_irq(struct irq_data *d)
582 {
583 struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
584 irq_hw_number_t hwirq = irqd_to_hwirq(d);
585
586 /*
587 * Perform any necessary action to mask the interrupt,
588 * and then call into the core code to synchronise the
589 * state.
590 */
591
592 gpiochip_disable_irq(gc, hwirq);
593 irq_mask_mask_parent(d);
594 }
595
596 static void my_gpio_unmask_irq(struct irq_data *d)
597 {
598 struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
599 irq_hw_number_t hwirq = irqd_to_hwirq(d);
600
601 gpiochip_enable_irq(gc, hwirq);
602
603 /*
604 * Perform any necessary action to unmask the interrupt,
605 * after having called into the core code to synchronise
606 * the state.
607 */
608
609 irq_mask_unmask_parent(d);
610 }
611
612 /*
613 * Statically populate the irqchip. Note that it is made const
614 * (further indicated by the IRQCHIP_IMMUTABLE flag), and that
615 * the GPIOCHIP_IRQ_RESOURCE_HELPER macro adds some extra
616 * callbacks to the structure.
617 */
618 static const struct irq_chip my_gpio_irq_chip = {
619 .name = "my_gpio_irq",
620 .irq_ack = my_gpio_ack_irq,
621 .irq_mask = my_gpio_mask_irq,
622 .irq_unmask = my_gpio_unmask_irq,
623 .irq_set_type = my_gpio_set_irq_type,
624 .flags = IRQCHIP_IMMUTABLE,
625 /* Provide the gpio resource callbacks */
626 GPIOCHIP_IRQ_RESOURCE_HELPERS,
627 };
628
629 struct my_gpio *g;
630 struct gpio_irq_chip *girq;
631
632 /* Get a pointer to the gpio_irq_chip */
633 girq = &g->gc.irq;
634 gpio_irq_chip_set_chip(girq, &my_gpio_irq_chip);
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;
640
641 return devm_gpiochip_add_data(dev, &g->gc, g);
642
643As you can see pretty similar, but you do not supply a parent handler for
644the IRQ, instead a parent irqdomain, an fwnode for the hardware and
645a function .child_to_parent_hwirq() that has the purpose of looking up
646the parent hardware irq from a child (i.e. this gpio chip) hardware irq.
647As always it is good to look at examples in the kernel tree for advice
648on how to find the required pieces.
649
650If there is a need to exclude certain GPIO lines from the IRQ domain handled by
651these helpers, we can set .irq.need_valid_mask of the gpiochip before
652devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an
653.irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
654bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
655from this mask. The mask can be filled in the init_valid_mask() callback
656that is part of the struct gpio_irq_chip.
657
658To use the helpers please keep the following in mind:
659
660- Make sure to assign all relevant members of the struct gpio_chip so that
661 the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
662 properly.
663
664- Nominally set gpio_irq_chip.handler to handle_bad_irq. Then, if your irqchip
665 is cascaded, set the handler to handle_level_irq() and/or handle_edge_irq()
666 in the irqchip .set_type() callback depending on what your controller
667 supports and what is requested by the consumer.
668
669
670Locking IRQ usage
671-----------------
672
673Since GPIO and irq_chip are orthogonal, we can get conflicts between different
674use cases. For example a GPIO line used for IRQs should be an input line,
675it does not make sense to fire interrupts on an output GPIO.
676
677If there is competition inside the subsystem which side is using the
678resource (a certain GPIO line and register for example) it needs to deny
679certain operations and keep track of usage inside of the gpiolib subsystem.
680
681Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
682to mark the GPIO as being used as an IRQ::
683
684 int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
685
686This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
687is released::
688
689 void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
690
691When implementing an irqchip inside a GPIO driver, these two functions should
692typically be called in the .startup() and .shutdown() callbacks from the
693irqchip.
694
695When using the gpiolib irqchip helpers, these callbacks are automatically
696assigned.
697
698
699Disabling and enabling IRQs
700---------------------------
701
702In some (fringe) use cases, a driver may be using a GPIO line as input for IRQs,
703but occasionally switch that line over to drive output and then back to being
704an input with interrupts again. This happens on things like CEC (Consumer
705Electronics Control).
706
707When a GPIO is used as an IRQ signal, then gpiolib also needs to know if
708the IRQ is enabled or disabled. In order to inform gpiolib about this,
709the irqchip driver should call::
710
711 void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset)
712
713This allows drivers to drive the GPIO as an output while the IRQ is
714disabled. When the IRQ is enabled again, a driver should call::
715
716 void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset)
717
718When implementing an irqchip inside a GPIO driver, these two functions should
719typically be called in the .irq_disable() and .irq_enable() callbacks from the
720irqchip.
721
722When IRQCHIP_IMMUTABLE is not advertised by the irqchip, these callbacks
723are automatically assigned. This behaviour is deprecated and on its way
724to be removed from the kernel.
725
726
727Real-Time compliance for GPIO IRQ chips
728---------------------------------------
729
730Any provider of irqchips needs to be carefully tailored to support Real-Time
731preemption. It is desirable that all irqchips in the GPIO subsystem keep this
732in mind and do the proper testing to assure they are real time-enabled.
733
734So, pay attention on above realtime considerations in the documentation.
735
736The following is a checklist to follow when preparing a driver for real-time
737compliance:
738
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
741 If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
742 and .irq_bus_unlock() callbacks
743- Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
744 from the chained IRQ handler
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
748 handler if possible
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
752 level and edge IRQs
753
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
757
758
759Requesting self-owned GPIO pins
760===============================
761
762Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
763descriptors through the gpiolib API. A GPIO driver can use the following
764functions to request and free descriptors::
765
766 struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
767 u16 hwnum,
768 const char *label,
769 enum gpiod_flags flags)
770
771 void gpiochip_free_own_desc(struct gpio_desc *desc)
772
773Descriptors requested with gpiochip_request_own_desc() must be released with
774gpiochip_free_own_desc().
775
776These functions must be used with care since they do not affect module use
777count. Do not use the functions to request gpio descriptors not owned by the
778calling driver.
1================================
2GPIO Descriptor Driver Interface
3================================
4
5This document serves as a guide for GPIO chip drivers writers. Note that it
6describes the new descriptor-based interface. For a description of the
7deprecated integer-based GPIO interface please refer to gpio-legacy.txt.
8
9Each GPIO controller driver needs to include the following header, which defines
10the structures used to define a GPIO driver:
11
12 #include <linux/gpio/driver.h>
13
14
15Internal Representation of GPIOs
16================================
17
18Inside a GPIO driver, individual GPIOs are identified by their hardware number,
19which is a unique number between 0 and n, n being the number of GPIOs managed by
20the chip. This number is purely internal: the hardware number of a particular
21GPIO descriptor is never made visible outside of the driver.
22
23On top of this internal number, each GPIO also need to have a global number in
24the integer GPIO namespace so that it can be used with the legacy GPIO
25interface. Each chip must thus have a "base" number (which can be automatically
26assigned), and for each GPIO the global number will be (base + hardware number).
27Although the integer representation is considered deprecated, it still has many
28users and thus needs to be maintained.
29
30So for example one platform could use numbers 32-159 for GPIOs, with a
31controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
32numbers 0..63 with one set of GPIO controllers, 64-79 with another type of GPIO
33controller, and on one particular board 80-95 with an FPGA. The numbers need not
34be contiguous; either of those platforms could also use numbers 2000-2063 to
35identify GPIOs in a bank of I2C GPIO expanders.
36
37
38Controller Drivers: gpio_chip
39=============================
40
41In the gpiolib framework each GPIO controller is packaged as a "struct
42gpio_chip" (see linux/gpio/driver.h for its complete definition) with members
43common to each controller of that type:
44
45 - methods to establish GPIO line direction
46 - methods used to access GPIO line values
47 - method to set electrical configuration to a 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
54
55The code implementing a gpio_chip should support multiple instances of the
56controller, possibly using the driver model. That code will configure each
57gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``.
58Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()``
59when it is unavoidable.
60
61Often a gpio_chip is part of an instance-specific structure with states not
62exposed by the GPIO interfaces, such as addressing, power management, and more.
63Chips such as audio codecs will have complex non-GPIO states.
64
65Any debugfs dump method should normally ignore signals which haven't been
66requested as GPIOs. They can use gpiochip_is_requested(), which returns either
67NULL or the label associated with that GPIO when it was requested.
68
69RT_FULL: the GPIO driver should not use spinlock_t or any sleepable APIs
70(like PM runtime) in its gpio_chip implementation (.get/.set and direction
71control callbacks) if it is expected to call GPIO APIs from atomic context
72on -RT (inside hard IRQ handlers and similar contexts). Normally this should
73not be required.
74
75
76GPIO electrical configuration
77-----------------------------
78
79GPIOs can be configured for several electrical modes of operation by using the
80.set_config() callback. Currently this API supports setting debouncing and
81single-ended modes (open drain/open source). These settings are described
82below.
83
84The .set_config() callback uses the same enumerators and configuration
85semantics as the generic pin control drivers. This is not a coincidence: it is
86possible to assign the .set_config() to the function gpiochip_generic_config()
87which will result in pinctrl_gpio_set_config() being called and eventually
88ending up in the pin control back-end "behind" the GPIO controller, usually
89closer to the actual pins. This way the pin controller can manage the below
90listed GPIO configurations.
91
92If a pin controller back-end is used, the GPIO controller or hardware
93description needs to provide "GPIO ranges" mapping the GPIO line offsets to pin
94numbers on the pin controller so they can properly cross-reference each other.
95
96
97GPIOs with debounce support
98---------------------------
99
100Debouncing is a configuration set to a pin indicating that it is connected to
101a mechanical switch or button, or similar that may bounce. Bouncing means the
102line is pulled high/low quickly at very short intervals for mechanical
103reasons. This can result in the value being unstable or irqs fireing repeatedly
104unless the line is debounced.
105
106Debouncing in practice involves setting up a timer when something happens on
107the line, wait a little while and then sample the line again, so see if it
108still has the same value (low or high). This could also be repeated by a clever
109state machine, waiting for a line to become stable. In either case, it sets
110a certain number of milliseconds for debouncing, or just "on/off" if that time
111is not configurable.
112
113
114GPIOs with open drain/source support
115------------------------------------
116
117Open drain (CMOS) or open collector (TTL) means the line is not actively driven
118high: instead you provide the drain/collector as output, so when the transistor
119is not open, it will present a high-impedance (tristate) to the external rail::
120
121
122 CMOS CONFIGURATION TTL CONFIGURATION
123
124 ||--- out +--- out
125 in ----|| |/
126 ||--+ in ----|
127 | |\
128 GND GND
129
130This configuration is normally used as a way to achieve one of two things:
131
132- Level-shifting: to reach a logical level higher than that of the silicon
133 where the output resides.
134
135- inverse wire-OR on an I/O line, for example a GPIO line, making it possible
136 for any driving stage on the line to drive it low even if any other output
137 to the same line is simultaneously driving it high. A special case of this
138 is driving the SCL and SCA lines of an I2C bus, which is by definition a
139 wire-OR bus.
140
141Both usecases require that the line be equipped with a pull-up resistor. This
142resistor will make the line tend to high level unless one of the transistors on
143the rail actively pulls it down.
144
145The level on the line will go as high as the VDD on the pull-up resistor, which
146may be higher than the level supported by the transistor, achieveing a
147level-shift to the higher VDD.
148
149Integrated electronics often have an output driver stage in the form of a CMOS
150"totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
151the line high and one of them drives the line low. This is called a push-pull
152output. The "totem-pole" looks like so::
153
154 VDD
155 |
156 OD ||--+
157 +--/ ---o|| P-MOS-FET
158 | ||--+
159 IN --+ +----- out
160 | ||--+
161 +--/ ----|| N-MOS-FET
162 OS ||--+
163 |
164 GND
165
166The desired output signal (e.g. coming directly from some GPIO output register)
167arrives at IN. The switches named "OD" and "OS" are normally closed, creating
168a push-pull circuit.
169
170Consider the little "switches" named "OD" and "OS" that enable/disable the
171P-MOS or N-MOS transistor right after the split of the input. As you can see,
172either transistor will go totally numb if this switch is open. The totem-pole
173is then halved and give high impedance instead of actively driving the line
174high or low respectively. That is usually how software-controlled open
175drain/source works.
176
177Some GPIO hardware come in open drain / open source configuration. Some are
178hard-wired lines that will only support open drain or open source no matter
179what: there is only one transistor there. Some are software-configurable:
180by flipping a bit in a register the output can be configured as open drain
181or open source, in practice by flicking open the switches labeled "OD" and "OS"
182in the drawing above.
183
184By disabling the P-MOS transistor, the output can be driven between GND and
185high impedance (open drain), and by disabling the N-MOS transistor, the output
186can be driven between VDD and high impedance (open source). In the first case,
187a pull-up resistor is needed on the outgoing rail to complete the circuit, and
188in the second case, a pull-down resistor is needed on the rail.
189
190Hardware that supports open drain or open source or both, can implement a
191special callback in the gpio_chip: .set_config() that takes a generic
192pinconf packed value telling whether to configure the line as open drain,
193open source or push-pull. This will happen in response to the
194GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag set in the machine file, or coming
195from other hardware descriptions.
196
197If this state can not be configured in hardware, i.e. if the GPIO hardware does
198not support open drain/open source in hardware, the GPIO library will instead
199use a trick: when a line is set as output, if the line is flagged as open
200drain, and the IN output value is low, it will be driven low as usual. But
201if the IN output value is set to high, it will instead *NOT* be driven high,
202instead it will be switched to input, as input mode is high impedance, thus
203achieveing an "open drain emulation" of sorts: electrically the behaviour will
204be identical, with the exception of possible hardware glitches when switching
205the mode of the line.
206
207For open source configuration the same principle is used, just that instead
208of actively driving the line low, it is set to input.
209
210
211GPIO drivers providing IRQs
212---------------------------
213It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
214most often cascaded off a parent interrupt controller, and in some special
215cases the GPIO logic is melded with a SoC's primary interrupt controller.
216
217The IRQ portions of the GPIO block are implemented using an irqchip, using
218the header <linux/irq.h>. So basically such a driver is utilizing two sub-
219systems simultaneously: gpio and irq.
220
221RT_FULL: a realtime compliant GPIO driver should not use spinlock_t or any
222sleepable APIs (like PM runtime) as part of its irq_chip implementation.
223
224* spinlock_t should be replaced with raw_spinlock_t [1].
225* If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
226 and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks
227 on an irqchip. Create the callbacks if needed [2].
228
229GPIO irqchips usually fall in one of two categories:
230
231* CHAINED GPIO irqchips: these are usually the type that is embedded on
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
234 system interrupt controller. This means that the GPIO irqchip handler will
235 be called immediately from the parent irqchip, while holding the IRQs
236 disabled. The GPIO irqchip will then end up calling something like this
237 sequence in its interrupt handler::
238
239 static irqreturn_t foo_gpio_irq(int irq, void *data)
240 chained_irq_enter(...);
241 generic_handle_irq(...);
242 chained_irq_exit(...);
243
244 Chained GPIO irqchips typically can NOT set the .can_sleep flag on
245 struct gpio_chip, as everything happens directly in the callbacks: no
246 slow bus traffic like I2C can be used.
247
248 RT_FULL: Note, chained IRQ handlers will not be forced threaded on -RT.
249 As result, spinlock_t or any sleepable APIs (like PM runtime) can't be used
250 in chained IRQ handler.
251 If required (and if it can't be converted to the nested threaded GPIO irqchip)
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
254 (for example, see [3]).
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
257 forced to a thread. The "fake?" raw lock can be used to W/A this problem::
258
259 raw_spinlock_t wa_lock;
260 static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
261 unsigned long wa_lock_flags;
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);
265
266* GENERIC CHAINED GPIO irqchips: these are the same as "CHAINED GPIO irqchips",
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().
269 The GPIO irqchip will then end up calling something like this sequence in
270 its interrupt handler::
271
272 static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
273 for each detected GPIO IRQ
274 generic_handle_irq(...);
275
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
278 the same W/A as for "CHAINED GPIO irqchips" can be applied.
279
280* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
281 other GPIO irqchip residing on the other side of a sleeping bus. Of course
282 such drivers that need slow bus traffic to read out IRQ status and similar,
283 traffic which may in turn incur other IRQs to happen, cannot be handled
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
286 by the driver. The hallmark of this driver is to call something like
287 this in its interrupt handler::
288
289 static irqreturn_t foo_gpio_irq(int irq, void *data)
290 ...
291 handle_nested_irq(irq);
292
293 The hallmark of threaded GPIO irqchips is that they set the .can_sleep
294 flag on struct gpio_chip to true, indicating that this chip may sleep
295 when accessing the GPIOs.
296
297To help out in handling the set-up and management of GPIO irqchips and the
298associated irqdomain and resource allocation callbacks, the gpiolib has
299some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
300symbol:
301
302* gpiochip_irqchip_add(): adds a chained irqchip to a gpiochip. It will pass
303 the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
304 need to embed the gpio_chip in its state container and obtain a pointer
305 to the container using container_of().
306 (See Documentation/driver-model/design-patterns.txt)
307
308* gpiochip_irqchip_add_nested(): adds a nested irqchip to a gpiochip.
309 Apart from that it works exactly like the chained irqchip.
310
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
313 data. (Notice handler data, since the irqchip data is likely used by the
314 parent irqchip!).
315
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
318 explicitly requested by the driver, this does very little more than
319 mark all the child IRQs as having the other IRQ as parent.
320
321If there is a need to exclude certain GPIOs from the IRQ domain, you can
322set .irq.need_valid_mask of the gpiochip before gpiochip_add_data() is
323called. This allocates an .irq.valid_mask with as many bits set as there
324are GPIOs in the chip. Drivers can exclude GPIOs by clearing bits from this
325mask. The mask must be filled in before gpiochip_irqchip_add() or
326gpiochip_irqchip_add_nested() is called.
327
328To use the helpers please keep the following in mind:
329
330- Make sure to assign all relevant members of the struct gpio_chip so that
331 the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
332 properly.
333
334- Nominally set all handlers to handle_bad_irq() in the setup call and pass
335 handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is
336 expected for GPIO driver that irqchip .set_type() callback have to be called
337 before using/enabling GPIO IRQ. Then set the handler to handle_level_irq()
338 and/or handle_edge_irq() in the irqchip .set_type() callback depending on
339 what your controller supports.
340
341It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
342if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
343irq_chip are orthogonal, and offering their services independent of each
344other.
345
346gpiod_to_irq() is just a convenience function to figure out the IRQ for a
347certain GPIO line and should not be relied upon to have been called before
348the IRQ is used.
349
350So always prepare the hardware and make it ready for action in respective
351callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
352been called first.
353
354This orthogonality leads to ambiguities that we need to solve: if there is
355competition inside the subsystem which side is using the resource (a certain
356GPIO line and register for example) it needs to deny certain operations and
357keep track of usage inside of the gpiolib subsystem. This is why the API
358below exists.
359
360
361Locking IRQ usage
362-----------------
363Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
364to mark the GPIO as being used as an IRQ::
365
366 int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
367
368This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
369is released::
370
371 void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
372
373When implementing an irqchip inside a GPIO driver, these two functions should
374typically be called in the .startup() and .shutdown() callbacks from the
375irqchip.
376
377When using the gpiolib irqchip helpers, these callback are automatically
378assigned.
379
380Real-Time compliance for GPIO IRQ chips
381---------------------------------------
382
383Any provider of irqchips needs to be carefully tailored to support Real Time
384preemption. It is desirable that all irqchips in the GPIO subsystem keep this
385in mind and does the proper testing to assure they are real time-enabled.
386So, pay attention on above " RT_FULL:" notes, please.
387The following is a checklist to follow when preparing a driver for real
388time-compliance:
389
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.
392 If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
393 and .irq_bus_unlock() callbacks;
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
397 apply corresponding W/A;
398- Chained GPIO irqchips: get rid of chained IRQ handler and use generic irq
399 handler if possible :)
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
403 level and edge IRQs.
404
405
406Requesting self-owned GPIO pins
407-------------------------------
408
409Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
410descriptors through the gpiolib API. Using gpio_request() for this purpose
411does not help since it pins the module to the kernel forever (it calls
412try_module_get()). A GPIO driver can use the following functions instead
413to request and free descriptors without being pinned to the kernel forever::
414
415 struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
416 const char *label)
417
418 void gpiochip_free_own_desc(struct gpio_desc *desc)
419
420Descriptors requested with gpiochip_request_own_desc() must be released with
421gpiochip_free_own_desc().
422
423These functions must be used with care since they do not affect module use
424count. Do not use the functions to request gpio descriptors not owned by the
425calling driver.
426
427* [1] http://www.spinics.net/lists/linux-omap/msg120425.html
428* [2] https://lkml.org/lkml/2015/9/25/494
429* [3] https://lkml.org/lkml/2015/9/25/495