Documentation/driver-api/gpio/driver.rst

   1 ================================
   2 GPIO Descriptor Driver Interface
   3 ================================
   4
   5 This document serves as a guide for GPIO chip drivers writers. Note that it
   6 describes the new descriptor-based interface. For a description of the
   7 deprecated integer-based GPIO interface please refer to gpio-legacy.txt.
   8
   9 Each GPIO controller driver needs to include the following header, which defines
  10 the structures used to define a GPIO driver:
  11
  12         #include <linux/gpio/driver.h>
  13
  14
  15 Internal Representation of GPIOs
  16 ================================
  17
  18 Inside a GPIO driver, individual GPIOs are identified by their hardware number,
  19 which is a unique number between 0 and n, n being the number of GPIOs managed by
  20 the chip. This number is purely internal: the hardware number of a particular
  21 GPIO descriptor is never made visible outside of the driver.
  22
  23 On top of this internal number, each GPIO also need to have a global number in
  24 the integer GPIO namespace so that it can be used with the legacy GPIO
  25 interface. Each chip must thus have a "base" number (which can be automatically
  26 assigned), and for each GPIO the global number will be (base + hardware number).
  27 Although the integer representation is considered deprecated, it still has many
  28 users and thus needs to be maintained.
  29
  30 So for example one platform could use numbers 32-159 for GPIOs, with a
  31 controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
  32 numbers 0..63 with one set of GPIO controllers, 64-79 with another type of GPIO
  33 controller, and on one particular board 80-95 with an FPGA. The numbers need not
  34 be contiguous; either of those platforms could also use numbers 2000-2063 to
  35 identify GPIOs in a bank of I2C GPIO expanders.
  36
  37
  38 Controller Drivers: gpio_chip
  39 =============================
  40
  41 In the gpiolib framework each GPIO controller is packaged as a "struct
  42 gpio_chip" (see linux/gpio/driver.h for its complete definition) with members
  43 common to each controller of that type:
  44
  45  - methods to establish GPIO line direction
  46  - methods used to access GPIO line values
  47  - method to set electrical configuration for a given GPIO line
  48  - method to return the IRQ number associated to a given GPIO line
  49  - flag saying whether calls to its methods may sleep
  50  - optional line names array to identify lines
  51  - optional debugfs dump method (showing extra state like pullup config)
  52  - optional base number (will be automatically assigned if omitted)
  53  - optional label for diagnostics and GPIO chip mapping using platform data
  54
  55 The code implementing a gpio_chip should support multiple instances of the
  56 controller, possibly using the driver model. That code will configure each
  57 gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``.
  58 Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()``
  59 when it is unavoidable.
  60
  61 Often a gpio_chip is part of an instance-specific structure with states not
  62 exposed by the GPIO interfaces, such as addressing, power management, and more.
  63 Chips such as audio codecs will have complex non-GPIO states.
  64
  65 Any debugfs dump method should normally ignore signals which haven't been
  66 requested as GPIOs. They can use gpiochip_is_requested(), which returns either
  67 NULL or the label associated with that GPIO when it was requested.
  68
  69 RT_FULL: the GPIO driver should not use spinlock_t or any sleepable APIs
  70 (like PM runtime) in its gpio_chip implementation (.get/.set and direction
  71 control callbacks) if it is expected to call GPIO APIs from atomic context
  72 on -RT (inside hard IRQ handlers and similar contexts). Normally this should
  73 not be required.
  74
  75
  76 GPIO electrical configuration
  77 -----------------------------
  78
  79 GPIOs can be configured for several electrical modes of operation by using the
  80 .set_config() callback. Currently this API supports setting debouncing and
  81 single-ended modes (open drain/open source). These settings are described
  82 below.
  83
  84 The .set_config() callback uses the same enumerators and configuration
  85 semantics as the generic pin control drivers. This is not a coincidence: it is
  86 possible to assign the .set_config() to the function gpiochip_generic_config()
  87 which will result in pinctrl_gpio_set_config() being called and eventually
  88 ending up in the pin control back-end "behind" the GPIO controller, usually
  89 closer to the actual pins. This way the pin controller can manage the below
  90 listed GPIO configurations.
  91
  92 If a pin controller back-end is used, the GPIO controller or hardware
  93 description needs to provide "GPIO ranges" mapping the GPIO line offsets to pin
  94 numbers on the pin controller so they can properly cross-reference each other.
  95
  96
  97 GPIOs with debounce support
  98 ---------------------------
  99
 100 Debouncing is a configuration set to a pin indicating that it is connected to
 101 a mechanical switch or button, or similar that may bounce. Bouncing means the
 102 line is pulled high/low quickly at very short intervals for mechanical
 103 reasons. This can result in the value being unstable or irqs fireing repeatedly
 104 unless the line is debounced.
 105
 106 Debouncing in practice involves setting up a timer when something happens on
 107 the line, wait a little while and then sample the line again, so see if it
 108 still has the same value (low or high). This could also be repeated by a clever
 109 state machine, waiting for a line to become stable. In either case, it sets
 110 a certain number of milliseconds for debouncing, or just "on/off" if that time
 111 is not configurable.
 112
 113
 114 GPIOs with open drain/source support
 115 ------------------------------------
 116
 117 Open drain (CMOS) or open collector (TTL) means the line is not actively driven
 118 high: instead you provide the drain/collector as output, so when the transistor
 119 is not open, it will present a high-impedance (tristate) to the external rail::
 120
 121
 122    CMOS CONFIGURATION      TTL CONFIGURATION
 123
 124             ||--- out              +--- out
 125      in ----||                   |/
 126             ||--+         in ----|
 127                 |                |\
 128                GND                 GND
 129
 130 This configuration is normally used as a way to achieve one of two things:
 131
 132 - Level-shifting: to reach a logical level higher than that of the silicon
 133   where the output resides.
 134
 135 - inverse wire-OR on an I/O line, for example a GPIO line, making it possible
 136   for any driving stage on the line to drive it low even if any other output
 137   to the same line is simultaneously driving it high. A special case of this
 138   is driving the SCL and SCA lines of an I2C bus, which is by definition a
 139   wire-OR bus.
 140
 141 Both usecases require that the line be equipped with a pull-up resistor. This
 142 resistor will make the line tend to high level unless one of the transistors on
 143 the rail actively pulls it down.
 144
 145 The level on the line will go as high as the VDD on the pull-up resistor, which
 146 may be higher than the level supported by the transistor, achieving a
 147 level-shift to the higher VDD.
 148
 149 Integrated electronics often have an output driver stage in the form of a CMOS
 150 "totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
 151 the line high and one of them drives the line low. This is called a push-pull
 152 output. The "totem-pole" looks like so::
 153
 154                      VDD
 155                       |
 156             OD    ||--+
 157          +--/ ---o||     P-MOS-FET
 158          |        ||--+
 159     IN --+            +----- out
 160          |        ||--+
 161          +--/ ----||     N-MOS-FET
 162             OS    ||--+
 163                       |
 164                      GND
 165
 166 The desired output signal (e.g. coming directly from some GPIO output register)
 167 arrives at IN. The switches named "OD" and "OS" are normally closed, creating
 168 a push-pull circuit.
 169
 170 Consider the little "switches" named "OD" and "OS" that enable/disable the
 171 P-MOS or N-MOS transistor right after the split of the input. As you can see,
 172 either transistor will go totally numb if this switch is open. The totem-pole
 173 is then halved and give high impedance instead of actively driving the line
 174 high or low respectively. That is usually how software-controlled open
 175 drain/source works.
 176
 177 Some GPIO hardware come in open drain / open source configuration. Some are
 178 hard-wired lines that will only support open drain or open source no matter
 179 what: there is only one transistor there. Some are software-configurable:
 180 by flipping a bit in a register the output can be configured as open drain
 181 or open source, in practice by flicking open the switches labeled "OD" and "OS"
 182 in the drawing above.
 183
 184 By disabling the P-MOS transistor, the output can be driven between GND and
 185 high impedance (open drain), and by disabling the N-MOS transistor, the output
 186 can be driven between VDD and high impedance (open source). In the first case,
 187 a pull-up resistor is needed on the outgoing rail to complete the circuit, and
 188 in the second case, a pull-down resistor is needed on the rail.
 189
 190 Hardware that supports open drain or open source or both, can implement a
 191 special callback in the gpio_chip: .set_config() that takes a generic
 192 pinconf packed value telling whether to configure the line as open drain,
 193 open source or push-pull. This will happen in response to the
 194 GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag set in the machine file, or coming
 195 from other hardware descriptions.
 196
 197 If this state can not be configured in hardware, i.e. if the GPIO hardware does
 198 not support open drain/open source in hardware, the GPIO library will instead
 199 use a trick: when a line is set as output, if the line is flagged as open
 200 drain, and the IN output value is low, it will be driven low as usual. But
 201 if the IN output value is set to high, it will instead *NOT* be driven high,
 202 instead it will be switched to input, as input mode is high impedance, thus
 203 achieveing an "open drain emulation" of sorts: electrically the behaviour will
 204 be identical, with the exception of possible hardware glitches when switching
 205 the mode of the line.
 206
 207 For open source configuration the same principle is used, just that instead
 208 of actively driving the line low, it is set to input.
 209
 210
 211 GPIO drivers providing IRQs
 212 ---------------------------
 213 It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
 214 most often cascaded off a parent interrupt controller, and in some special
 215 cases the GPIO logic is melded with a SoC's primary interrupt controller.
 216
 217 The IRQ portions of the GPIO block are implemented using an irqchip, using
 218 the header <linux/irq.h>. So basically such a driver is utilizing two sub-
 219 systems simultaneously: gpio and irq.
 220
 221 RT_FULL: a realtime compliant GPIO driver should not use spinlock_t or any
 222 sleepable APIs (like PM runtime) as part of its irq_chip implementation.
 223
 224 * spinlock_t should be replaced with raw_spinlock_t [1].
 225 * If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
 226   and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks
 227   on an irqchip. Create the callbacks if needed [2].
 228
 229 GPIO irqchips usually fall in one of two categories:
 230
 231 * CHAINED GPIO irqchips: these are usually the type that is embedded on
 232   an SoC. This means that there is a fast IRQ flow handler for the GPIOs that
 233   gets called in a chain from the parent IRQ handler, most typically the
 234   system interrupt controller. This means that the GPIO irqchip handler will
 235   be called immediately from the parent irqchip, while holding the IRQs
 236   disabled. The GPIO irqchip will then end up calling something like this
 237   sequence in its interrupt handler::
 238
 239     static irqreturn_t foo_gpio_irq(int irq, void *data)
 240         chained_irq_enter(...);
 241         generic_handle_irq(...);
 242         chained_irq_exit(...);
 243
 244   Chained GPIO irqchips typically can NOT set the .can_sleep flag on
 245   struct gpio_chip, as everything happens directly in the callbacks: no
 246   slow bus traffic like I2C can be used.
 247
 248   RT_FULL: Note, chained IRQ handlers will not be forced threaded on -RT.
 249   As result, spinlock_t or any sleepable APIs (like PM runtime) can't be used
 250   in chained IRQ handler.
 251   If required (and if it can't be converted to the nested threaded GPIO irqchip)
 252   a chained IRQ handler can be converted to generic irq handler and this way
 253   it will be a threaded IRQ handler on -RT and a hard IRQ handler on non-RT
 254   (for example, see [3]).
 255   Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled,
 256   so the IRQ core will complain if it is called from an IRQ handler which is
 257   forced to a thread. The "fake?" raw lock can be used to W/A this problem::
 258
 259         raw_spinlock_t wa_lock;
 260         static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
 261                 unsigned long wa_lock_flags;
 262                 raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags);
 263                 generic_handle_irq(irq_find_mapping(bank->chip.irq.domain, bit));
 264                 raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags);
 265
 266 * GENERIC CHAINED GPIO irqchips: these are the same as "CHAINED GPIO irqchips",
 267   but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
 268   performed by generic IRQ handler which is configured using request_irq().
 269   The GPIO irqchip will then end up calling something like this sequence in
 270   its interrupt handler::
 271
 272     static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
 273         for each detected GPIO IRQ
 274             generic_handle_irq(...);
 275
 276   RT_FULL: Such kind of handlers will be forced threaded on -RT, as result IRQ
 277   core will complain that generic_handle_irq() is called with IRQ enabled and
 278   the same W/A as for "CHAINED GPIO irqchips" can be applied.
 279
 280 * NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
 281   other GPIO irqchip residing on the other side of a sleeping bus. Of course
 282   such drivers that need slow bus traffic to read out IRQ status and similar,
 283   traffic which may in turn incur other IRQs to happen, cannot be handled
 284   in a quick IRQ handler with IRQs disabled. Instead they need to spawn a
 285   thread and then mask the parent IRQ line until the interrupt is handled
 286   by the driver. The hallmark of this driver is to call something like
 287   this in its interrupt handler::
 288
 289     static irqreturn_t foo_gpio_irq(int irq, void *data)
 290         ...
 291         handle_nested_irq(irq);
 292
 293   The hallmark of threaded GPIO irqchips is that they set the .can_sleep
 294   flag on struct gpio_chip to true, indicating that this chip may sleep
 295   when accessing the GPIOs.
 296
 297 To help out in handling the set-up and management of GPIO irqchips and the
 298 associated irqdomain and resource allocation callbacks, the gpiolib has
 299 some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
 300 symbol:
 301
 302 * gpiochip_irqchip_add(): adds a chained irqchip to a gpiochip. It will pass
 303   the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
 304   need to embed the gpio_chip in its state container and obtain a pointer
 305   to the container using container_of().
 306   (See Documentation/driver-model/design-patterns.txt)
 307
 308 * gpiochip_irqchip_add_nested(): adds a nested irqchip to a gpiochip.
 309   Apart from that it works exactly like the chained irqchip.
 310
 311 * gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
 312   gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
 313   data. (Notice handler data, since the irqchip data is likely used by the
 314   parent irqchip!).
 315
 316 * gpiochip_set_nested_irqchip(): sets up a nested irq handler for a
 317   gpio_chip from a parent IRQ. As the parent IRQ has usually been
 318   explicitly requested by the driver, this does very little more than
 319   mark all the child IRQs as having the other IRQ as parent.
 320
 321 If there is a need to exclude certain GPIOs from the IRQ domain, you can
 322 set .irq.need_valid_mask of the gpiochip before gpiochip_add_data() is
 323 called. This allocates an .irq.valid_mask with as many bits set as there
 324 are GPIOs in the chip. Drivers can exclude GPIOs by clearing bits from this
 325 mask. The mask must be filled in before gpiochip_irqchip_add() or
 326 gpiochip_irqchip_add_nested() is called.
 327
 328 To use the helpers please keep the following in mind:
 329
 330 - Make sure to assign all relevant members of the struct gpio_chip so that
 331   the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
 332   properly.
 333
 334 - Nominally set all handlers to handle_bad_irq() in the setup call and pass
 335   handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is
 336   expected for GPIO driver that irqchip .set_type() callback have to be called
 337   before using/enabling GPIO IRQ. Then set the handler to handle_level_irq()
 338   and/or handle_edge_irq() in the irqchip .set_type() callback depending on
 339   what your controller supports.
 340
 341 It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
 342 if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
 343 irq_chip are orthogonal, and offering their services independent of each
 344 other.
 345
 346 gpiod_to_irq() is just a convenience function to figure out the IRQ for a
 347 certain GPIO line and should not be relied upon to have been called before
 348 the IRQ is used.
 349
 350 So always prepare the hardware and make it ready for action in respective
 351 callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
 352 been called first.
 353
 354 This orthogonality leads to ambiguities that we need to solve: if there is
 355 competition inside the subsystem which side is using the resource (a certain
 356 GPIO line and register for example) it needs to deny certain operations and
 357 keep track of usage inside of the gpiolib subsystem. This is why the API
 358 below exists.
 359
 360
 361 Locking IRQ usage
 362 -----------------
 363 Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
 364 to mark the GPIO as being used as an IRQ::
 365
 366         int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
 367
 368 This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
 369 is released::
 370
 371         void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
 372
 373 When implementing an irqchip inside a GPIO driver, these two functions should
 374 typically be called in the .startup() and .shutdown() callbacks from the
 375 irqchip.
 376
 377 When using the gpiolib irqchip helpers, these callbacks are automatically
 378 assigned.
 379
 380
 381 Disabling and enabling IRQs
 382 ---------------------------
 383 When a GPIO is used as an IRQ signal, then gpiolib also needs to know if
 384 the IRQ is enabled or disabled. In order to inform gpiolib about this,
 385 a driver should call::
 386
 387         void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset)
 388
 389 This allows drivers to drive the GPIO as an output while the IRQ is
 390 disabled. When the IRQ is enabled again, a driver should call::
 391
 392         void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset)
 393
 394 When implementing an irqchip inside a GPIO driver, these two functions should
 395 typically be called in the .irq_disable() and .irq_enable() callbacks from the
 396 irqchip.
 397
 398 When using the gpiolib irqchip helpers, these callbacks are automatically
 399 assigned.
 400
 401 Real-Time compliance for GPIO IRQ chips
 402 ---------------------------------------
 403
 404 Any provider of irqchips needs to be carefully tailored to support Real Time
 405 preemption. It is desirable that all irqchips in the GPIO subsystem keep this
 406 in mind and do the proper testing to assure they are real time-enabled.
 407 So, pay attention on above " RT_FULL:" notes, please.
 408 The following is a checklist to follow when preparing a driver for real
 409 time-compliance:
 410
 411 - ensure spinlock_t is not used as part irq_chip implementation;
 412 - ensure that sleepable APIs are not used as part irq_chip implementation.
 413   If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
 414   and .irq_bus_unlock() callbacks;
 415 - Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
 416   from chained IRQ handler;
 417 - Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
 418   apply corresponding W/A;
 419 - Chained GPIO irqchips: get rid of chained IRQ handler and use generic irq
 420   handler if possible :)
 421 - regmap_mmio: Sry, but you are in trouble :( if MMIO regmap is used as for
 422   GPIO IRQ chip implementation;
 423 - Test your driver with the appropriate in-kernel real time test cases for both
 424   level and edge IRQs.
 425
 426
 427 Requesting self-owned GPIO pins
 428 -------------------------------
 429
 430 Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
 431 descriptors through the gpiolib API. Using gpio_request() for this purpose
 432 does not help since it pins the module to the kernel forever (it calls
 433 try_module_get()). A GPIO driver can use the following functions instead
 434 to request and free descriptors without being pinned to the kernel forever::
 435
 436         struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
 437                                                     const char *label)
 438
 439         void gpiochip_free_own_desc(struct gpio_desc *desc)
 440
 441 Descriptors requested with gpiochip_request_own_desc() must be released with
 442 gpiochip_free_own_desc().
 443
 444 These functions must be used with care since they do not affect module use
 445 count. Do not use the functions to request gpio descriptors not owned by the
 446 calling driver.
 447
 448 * [1] http://www.spinics.net/lists/linux-omap/msg120425.html
 449 * [2] https://lkml.org/lkml/2015/9/25/494
 450 * [3] https://lkml.org/lkml/2015/9/25/495