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