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