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