forked from ~ljy/RK356X_SDK_RELEASE
blame | history | patch | commit | commitdiff
hc
2024-01-05 071106ecf68c401173c58808b1cf5f68cc50d390 
 kernel/Documentation/driver-api/gpio/driver.rst
....@@ -1,13 +1,11 @@
1
-================================
2
-GPIO Descriptor Driver Interface
3
-================================
1
+=====================
2
+GPIO Driver Interface
3
+=====================
44 
5
-This document serves as a guide for GPIO chip drivers writers. Note that it
6
-describes the new descriptor-based interface. For a description of the
7
-deprecated integer-based GPIO interface please refer to gpio-legacy.txt.
5
+This document serves as a guide for writers of GPIO chip drivers.
86 
97 Each GPIO controller driver needs to include the following header, which defines
10
-the structures used to define a GPIO driver:
8
+the structures used to define a GPIO driver::
119 
1210 	#include <linux/gpio/driver.h>
1311 
....@@ -15,32 +13,49 @@
1513 Internal Representation of GPIOs
1614 ================================
1715 
18
-Inside a GPIO driver, individual GPIOs are identified by their hardware number,
19
-which is a unique number between 0 and n, n being the number of GPIOs managed by
20
-the chip. This number is purely internal: the hardware number of a particular
21
-GPIO descriptor is never made visible outside of the driver.
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.
2223 
23
-On top of this internal number, each GPIO also need to have a global number in
24
-the integer GPIO namespace so that it can be used with the legacy GPIO
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
2539 interface. Each chip must thus have a "base" number (which can be automatically
26
-assigned), and for each GPIO the global number will be (base + hardware number).
27
-Although the integer representation is considered deprecated, it still has many
28
-users and thus needs to be maintained.
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.
2943 
30
-So for example one platform could use numbers 32-159 for GPIOs, with a
44
+So for example one platform could use global numbers 32-159 for GPIOs, with a
3145 controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
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
35
-identify GPIOs in a bank of I2C GPIO expanders.
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.
3650 
3751 
3852 Controller Drivers: gpio_chip
3953 =============================
4054 
4155 In the gpiolib framework each GPIO controller is packaged as a "struct
42
-gpio_chip" (see linux/gpio/driver.h for its complete definition) with members
43
-common to each controller of that type:
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:
4459 
4560  - methods to establish GPIO line direction
4661  - methods used to access GPIO line values
....@@ -48,38 +63,42 @@
4863  - method to return the IRQ number associated to a given GPIO line
4964  - flag saying whether calls to its methods may sleep
5065  - optional line names array to identify lines
51
- - optional debugfs dump method (showing extra state like pullup config)
66
+ - optional debugfs dump method (showing extra state information)
5267  - optional base number (will be automatically assigned if omitted)
5368  - optional label for diagnostics and GPIO chip mapping using platform data
5469 
5570 The code implementing a gpio_chip should support multiple instances of the
56
-controller, possibly using the driver model. That code will configure each
57
-gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``.
58
-Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()``
59
-when it is unavoidable.
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.
6075 
6176 Often a gpio_chip is part of an instance-specific structure with states not
6277 exposed by the GPIO interfaces, such as addressing, power management, and more.
6378 Chips such as audio codecs will have complex non-GPIO states.
6479 
65
-Any debugfs dump method should normally ignore signals which haven't been
66
-requested as GPIOs. They can use gpiochip_is_requested(), which returns either
67
-NULL or the label associated with that GPIO when it was requested.
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.
6883 
69
-RT_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
71
-control callbacks) if it is expected to call GPIO APIs from atomic context
72
-on -RT (inside hard IRQ handlers and similar contexts). Normally this should
73
-not be required.
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.
7489 
7590 
7691 GPIO electrical configuration
7792 -----------------------------
7893 
79
-GPIOs can be configured for several electrical modes of operation by using the
80
-.set_config() callback. Currently this API supports setting debouncing and
81
-single-ended modes (open drain/open source). These settings are described
82
-below.
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.
83102 
84103 The .set_config() callback uses the same enumerators and configuration
85104 semantics as the generic pin control drivers. This is not a coincidence: it is
....@@ -94,8 +113,8 @@
94113 numbers on the pin controller so they can properly cross-reference each other.
95114 
96115 
97
-GPIOs with debounce support
98
----------------------------
116
+GPIO lines with debounce support
117
+--------------------------------
99118 
100119 Debouncing is a configuration set to a pin indicating that it is connected to
101120 a mechanical switch or button, or similar that may bounce. Bouncing means the
....@@ -111,8 +130,8 @@
111130 is not configurable.
112131 
113132 
114
-GPIOs with open drain/source support
115
-------------------------------------
133
+GPIO lines with open drain/source support
134
+-----------------------------------------
116135 
117136 Open drain (CMOS) or open collector (TTL) means the line is not actively driven
118137 high: instead you provide the drain/collector as output, so when the transistor
....@@ -132,13 +151,13 @@
132151 - Level-shifting: to reach a logical level higher than that of the silicon
133152   where the output resides.
134153 
135
-- inverse wire-OR on an I/O line, for example a GPIO line, making it possible
154
+- Inverse wire-OR on an I/O line, for example a GPIO line, making it possible
136155   for any driving stage on the line to drive it low even if any other output
137156   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
157
+  is driving the SCL and SDA lines of an I2C bus, which is by definition a
139158   wire-OR bus.
140159 
141
-Both usecases require that the line be equipped with a pull-up resistor. This
160
+Both use cases require that the line be equipped with a pull-up resistor. This
142161 resistor will make the line tend to high level unless one of the transistors on
143162 the rail actively pulls it down.
144163 
....@@ -208,27 +227,91 @@
208227 of actively driving the line low, it is set to input.
209228 
210229 
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
+
211254 GPIO drivers providing IRQs
212
----------------------------
255
+===========================
256
+
213257 It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
214258 most often cascaded off a parent interrupt controller, and in some special
215259 cases the GPIO logic is melded with a SoC's primary interrupt controller.
216260 
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-
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-
219263 systems simultaneously: gpio and irq.
220264 
221
-RT_FULL: a realtime compliant GPIO driver should not use spinlock_t or any
222
-sleepable APIs (like PM runtime) as part of its irq_chip implementation.
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.
223269 
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()
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()
226305   and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks
227
-  on an irqchip. Create the callbacks if needed [2].
306
+  on an irqchip. Create the callbacks if needed.[2]
228307 
229
-GPIO irqchips usually fall in one of two categories:
230308 
231
-* CHAINED GPIO irqchips: these are usually the type that is embedded on
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
232315   an SoC. This means that there is a fast IRQ flow handler for the GPIOs that
233316   gets called in a chain from the parent IRQ handler, most typically the
234317   system interrupt controller. This means that the GPIO irqchip handler will
....@@ -245,25 +328,28 @@
245328   struct gpio_chip, as everything happens directly in the callbacks: no
246329   slow bus traffic like I2C can be used.
247330 
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,
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,
256341   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::
342
+  forced to a thread. The "fake?" raw lock can be used to work around this
343
+  problem::
258344 
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);
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);
265351 
266
-* GENERIC CHAINED GPIO irqchips: these are the same as "CHAINED GPIO irqchips",
352
+- GENERIC CHAINED GPIO IRQCHIPS: these are the same as "CHAINED GPIO irqchips",
267353   but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
268354   performed by generic IRQ handler which is configured using request_irq().
269355   The GPIO irqchip will then end up calling something like this sequence in
....@@ -273,16 +359,19 @@
273359         for each detected GPIO IRQ
274360             generic_handle_irq(...);
275361 
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.
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.
279366 
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
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
286375   by the driver. The hallmark of this driver is to call something like
287376   this in its interrupt handler::
288377 
....@@ -294,35 +383,141 @@
294383   flag on struct gpio_chip to true, indicating that this chip may sleep
295384   when accessing the GPIOs.
296385 
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
+
297393 To help out in handling the set-up and management of GPIO irqchips and the
298
-associated irqdomain and resource allocation callbacks, the gpiolib has
299
-some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
300
-symbol:
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:
301400 
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)
401
+.. csv-table::
402
+    :header: GPIO line offset, Hardware IRQ
307403 
308
-* gpiochip_irqchip_add_nested(): adds a nested irqchip to a gpiochip.
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 cascaded interrupt handler using gpio_irq_chip:
420
+
421
+.. code-block:: c
422
+
423
+  /* Typical state container with dynamic irqchip */
424
+  struct my_gpio {
425
+      struct gpio_chip gc;
426
+      struct irq_chip irq;
427
+  };
428
+
429
+  int irq; /* from platform etc */
430
+  struct my_gpio *g;
431
+  struct gpio_irq_chip *girq;
432
+
433
+  /* Set up the irqchip dynamically */
434
+  g->irq.name = "my_gpio_irq";
435
+  g->irq.irq_ack = my_gpio_ack_irq;
436
+  g->irq.irq_mask = my_gpio_mask_irq;
437
+  g->irq.irq_unmask = my_gpio_unmask_irq;
438
+  g->irq.irq_set_type = my_gpio_set_irq_type;
439
+
440
+  /* Get a pointer to the gpio_irq_chip */
441
+  girq = &g->gc.irq;
442
+  girq->chip = &g->irq;
443
+  girq->parent_handler = ftgpio_gpio_irq_handler;
444
+  girq->num_parents = 1;
445
+  girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
446
+                               GFP_KERNEL);
447
+  if (!girq->parents)
448
+      return -ENOMEM;
449
+  girq->default_type = IRQ_TYPE_NONE;
450
+  girq->handler = handle_bad_irq;
451
+  girq->parents[0] = irq;
452
+
453
+  return devm_gpiochip_add_data(dev, &g->gc, g);
454
+
455
+The helper support using hierarchical interrupt controllers as well.
456
+In this case the typical set-up will look like this:
457
+
458
+.. code-block:: c
459
+
460
+  /* Typical state container with dynamic irqchip */
461
+  struct my_gpio {
462
+      struct gpio_chip gc;
463
+      struct irq_chip irq;
464
+      struct fwnode_handle *fwnode;
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
+  /* Get a pointer to the gpio_irq_chip */
479
+  girq = &g->gc.irq;
480
+  girq->chip = &g->irq;
481
+  girq->default_type = IRQ_TYPE_NONE;
482
+  girq->handler = handle_bad_irq;
483
+  girq->fwnode = g->fwnode;
484
+  girq->parent_domain = parent;
485
+  girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq;
486
+
487
+  return devm_gpiochip_add_data(dev, &g->gc, g);
488
+
489
+As you can see pretty similar, but you do not supply a parent handler for
490
+the IRQ, instead a parent irqdomain, an fwnode for the hardware and
491
+a funcion .child_to_parent_hwirq() that has the purpose of looking up
492
+the parent hardware irq from a child (i.e. this gpio chip) hardware irq.
493
+As always it is good to look at examples in the kernel tree for advice
494
+on how to find the required pieces.
495
+
496
+The old way of adding irqchips to gpiochips after registration is also still
497
+available but we try to move away from this:
498
+
499
+- DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a
500
+  gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ
501
+  callbacks, so the callbacks need to embed the gpio_chip in its state
502
+  container and obtain a pointer to the container using container_of().
503
+  (See Documentation/driver-api/driver-model/design-patterns.rst)
504
+
505
+- gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip,
506
+  as discussed above regarding different types of cascaded irqchips. The
507
+  cascaded irq has to be handled by a threaded interrupt handler.
309508   Apart from that it works exactly like the chained irqchip.
310509 
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
510
+- gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a
317511   gpio_chip from a parent IRQ. As the parent IRQ has usually been
318512   explicitly requested by the driver, this does very little more than
319513   mark all the child IRQs as having the other IRQ as parent.
320514 
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
324
-are GPIOs in the chip. Drivers can exclude GPIOs by clearing bits from this
325
-mask. The mask must be filled in before gpiochip_irqchip_add() or
515
+If there is a need to exclude certain GPIO lines from the IRQ domain handled by
516
+these helpers, we can set .irq.need_valid_mask of the gpiochip before
517
+devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an
518
+.irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
519
+bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
520
+from this mask. The mask must be filled in before gpiochip_irqchip_add() or
326521 gpiochip_irqchip_add_nested() is called.
327522 
328523 To use the helpers please keep the following in mind:
....@@ -333,33 +528,24 @@
333528 
334529 - Nominally set all handlers to handle_bad_irq() in the setup call and pass
335530   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
-
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
343
-irq_chip are orthogonal, and offering their services independent of each
344
-other.
345
-
346
-gpiod_to_irq() is just a convenience function to figure out the IRQ for a
347
-certain GPIO line and should not be relied upon to have been called before
348
-the IRQ is used.
349
-
350
-So always prepare the hardware and make it ready for action in respective
351
-callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
352
-been called first.
353
-
354
-This orthogonality leads to ambiguities that we need to solve: if there is
355
-competition inside the subsystem which side is using the resource (a certain
356
-GPIO line and register for example) it needs to deny certain operations and
357
-keep track of usage inside of the gpiolib subsystem. This is why the API
358
-below exists.
531
+  expected for GPIO driver that irqchip .set_type() callback will be called
532
+  before using/enabling each GPIO IRQ. Then set the handler to
533
+  handle_level_irq() and/or handle_edge_irq() in the irqchip .set_type()
534
+  callback depending on what your controller supports and what is requested
535
+  by the consumer.
359536 
360537 
361538 Locking IRQ usage
362539 -----------------
540
+
541
+Since GPIO and irq_chip are orthogonal, we can get conflicts between different
542
+use cases. For example a GPIO line used for IRQs should be an input line,
543
+it does not make sense to fire interrupts on an output GPIO.
544
+
545
+If there is competition inside the subsystem which side is using the
546
+resource (a certain GPIO line and register for example) it needs to deny
547
+certain operations and keep track of usage inside of the gpiolib subsystem.
548
+
363549 Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
364550 to mark the GPIO as being used as an IRQ::
365551 
....@@ -374,46 +560,80 @@
374560 typically be called in the .startup() and .shutdown() callbacks from the
375561 irqchip.
376562 
377
-When using the gpiolib irqchip helpers, these callback are automatically
563
+When using the gpiolib irqchip helpers, these callbacks are automatically
378564 assigned.
565
+
566
+
567
+Disabling and enabling IRQs
568
+---------------------------
569
+
570
+In some (fringe) use cases, a driver may be using a GPIO line as input for IRQs,
571
+but occasionally switch that line over to drive output and then back to being
572
+an input with interrupts again. This happens on things like CEC (Consumer
573
+Electronics Control).
574
+
575
+When a GPIO is used as an IRQ signal, then gpiolib also needs to know if
576
+the IRQ is enabled or disabled. In order to inform gpiolib about this,
577
+the irqchip driver should call::
578
+
579
+	void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset)
580
+
581
+This allows drivers to drive the GPIO as an output while the IRQ is
582
+disabled. When the IRQ is enabled again, a driver should call::
583
+
584
+	void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset)
585
+
586
+When implementing an irqchip inside a GPIO driver, these two functions should
587
+typically be called in the .irq_disable() and .irq_enable() callbacks from the
588
+irqchip.
589
+
590
+When using the gpiolib irqchip helpers, these callbacks are automatically
591
+assigned.
592
+
379593 
380594 Real-Time compliance for GPIO IRQ chips
381595 ---------------------------------------
382596 
383
-Any provider of irqchips needs to be carefully tailored to support Real Time
597
+Any provider of irqchips needs to be carefully tailored to support Real-Time
384598 preemption. It is desirable that all irqchips in the GPIO subsystem keep this
385599 in mind and do the proper testing to assure they are real time-enabled.
386
-So, pay attention on above " RT_FULL:" notes, please.
387
-The following is a checklist to follow when preparing a driver for real
388
-time-compliance:
389600 
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.
601
+So, pay attention on above realtime considerations in the documentation.
602
+
603
+The following is a checklist to follow when preparing a driver for real-time
604
+compliance:
605
+
606
+- ensure spinlock_t is not used as part irq_chip implementation
607
+- ensure that sleepable APIs are not used as part irq_chip implementation
392608   If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
393
-  and .irq_bus_unlock() callbacks;
609
+  and .irq_bus_unlock() callbacks
394610 - Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
395
-  from chained IRQ handler;
611
+  from the chained IRQ handler
396612 - 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.
613
+  apply corresponding work-around
614
+- Chained GPIO irqchips: get rid of the chained IRQ handler and use generic irq
615
+  handler if possible
616
+- regmap_mmio: it is possible to disable internal locking in regmap by setting
617
+  .disable_locking and handling the locking in the GPIO driver
618
+- Test your driver with the appropriate in-kernel real-time test cases for both
619
+  level and edge IRQs
620
+
621
+* [1] http://www.spinics.net/lists/linux-omap/msg120425.html
622
+* [2] https://lkml.org/lkml/2015/9/25/494
623
+* [3] https://lkml.org/lkml/2015/9/25/495
404624 
405625 
406626 Requesting self-owned GPIO pins
407
--------------------------------
627
+===============================
408628 
409629 Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
410
-descriptors through the gpiolib API. Using gpio_request() for this purpose
411
-does not help since it pins the module to the kernel forever (it calls
412
-try_module_get()). A GPIO driver can use the following functions instead
413
-to request and free descriptors without being pinned to the kernel forever::
630
+descriptors through the gpiolib API. A GPIO driver can use the following
631
+functions to request and free descriptors::
414632 
415633 	struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
416
-						    const char *label)
634
+						    u16 hwnum,
635
+						    const char *label,
636
+						    enum gpiod_flags flags)
417637 
418638 	void gpiochip_free_own_desc(struct gpio_desc *desc)
419639 
....@@ -423,7 +643,3 @@
423643 These functions must be used with care since they do not affect module use
424644 count. Do not use the functions to request gpio descriptors not owned by the
425645 calling 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