Documentation/gpio/driver.txt

   1 GPIO Descriptor Driver Interface
   2 ================================
   3
   4 This document serves as a guide for GPIO chip drivers writers. Note that it
   5 describes the new descriptor-based interface. For a description of the
   6 deprecated integer-based GPIO interface please refer to gpio-legacy.txt.
   7
   8 Each GPIO controller driver needs to include the following header, which defines
   9 the structures used to define a GPIO driver:
  10
  11         #include <linux/gpio/driver.h>
  12
  13
  14 Internal Representation of GPIOs
  15 ================================
  16
  17 Inside a GPIO driver, individual GPIOs are identified by their hardware number,
  18 which is a unique number between 0 and n, n being the number of GPIOs managed by
  19 the chip. This number is purely internal: the hardware number of a particular
  20 GPIO descriptor is never made visible outside of the driver.
  21
  22 On top of this internal number, each GPIO also need to have a global number in
  23 the integer GPIO namespace so that it can be used with the legacy GPIO
  24 interface. Each chip must thus have a "base" number (which can be automatically
  25 assigned), and for each GPIO the global number will be (base + hardware number).
  26 Although the integer representation is considered deprecated, it still has many
  27 users and thus needs to be maintained.
  28
  29 So for example one platform could use numbers 32-159 for GPIOs, with a
  30 controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
  31 numbers 0..63 with one set of GPIO controllers, 64-79 with another type of GPIO
  32 controller, and on one particular board 80-95 with an FPGA. The numbers need not
  33 be contiguous; either of those platforms could also use numbers 2000-2063 to
  34 identify GPIOs in a bank of I2C GPIO expanders.
  35
  36
  37 Controller Drivers: gpio_chip
  38 =============================
  39
  40 In the gpiolib framework each GPIO controller is packaged as a "struct
  41 gpio_chip" (see linux/gpio/driver.h for its complete definition) with members
  42 common to each controller of that type:
  43
  44  - methods to establish GPIO direction
  45  - methods used to access GPIO values
  46  - method to return the IRQ number associated to a given GPIO
  47  - flag saying whether calls to its methods may sleep
  48  - optional debugfs dump method (showing extra state like pullup config)
  49  - optional base number (will be automatically assigned if omitted)
  50  - label for diagnostics and GPIOs mapping using platform data
  51
  52 The code implementing a gpio_chip should support multiple instances of the
  53 controller, possibly using the driver model. That code will configure each
  54 gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be rare;
  55 use gpiochip_remove() when it is unavoidable.
  56
  57 Most often a gpio_chip is part of an instance-specific structure with state not
  58 exposed by the GPIO interfaces, such as addressing, power management, and more.
  59 Chips such as codecs will have complex non-GPIO state.
  60
  61 Any debugfs dump method should normally ignore signals which haven't been
  62 requested as GPIOs. They can use gpiochip_is_requested(), which returns either
  63 NULL or the label associated with that GPIO when it was requested.
  64
  65
  66 GPIO drivers providing IRQs
  67 ---------------------------
  68 It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
  69 most often cascaded off a parent interrupt controller, and in some special
  70 cases the GPIO logic is melded with a SoC's primary interrupt controller.
  71
  72 The IRQ portions of the GPIO block are implemented using an irqchip, using
  73 the header <linux/irq.h>. So basically such a driver is utilizing two sub-
  74 systems simultaneously: gpio and irq.
  75
  76 GPIO irqchips usually fall in one of two categories:
  77
  78 * CHAINED GPIO irqchips: these are usually the type that is embedded on
  79   an SoC. This means that there is a fast IRQ handler for the GPIOs that
  80   gets called in a chain from the parent IRQ handler, most typically the
  81   system interrupt controller. This means the GPIO irqchip is registered
  82   using irq_set_chained_handler() or the corresponding
  83   gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip
  84   handler will be called immediately from the parent irqchip, while
  85   holding the IRQs disabled. The GPIO irqchip will then end up calling
  86   something like this sequence in its interrupt handler:
  87
  88   static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
  89       chained_irq_enter(...);
  90       generic_handle_irq(...);
  91       chained_irq_exit(...);
  92
  93   Chained GPIO irqchips typically can NOT set the .can_sleep flag on
  94   struct gpio_chip, as everything happens directly in the callbacks.
  95
  96   NOTE: chained IRQ handlers are usually not good for real time. If you
  97   are submitting a new driver or refactoring a driver for real time compliance,
  98   consider using creating a nested/threaded irqchip instead, see below.
  99
 100 * NESTED THREADED GPIO irqchips: these are traditionally off-chip GPIO
 101   expanders and any other GPIO irqchip residing on the other side of a
 102   sleeping bus. Of course such drivers that need slow bus traffic to read
 103   out IRQ status and similar, traffic which may in turn incur other IRQs to
 104   happen, cannot be handled in a quick IRQ handler with IRQs disabled.
 105
 106   With the introduction of real time support in the Linux kernel, also other
 107   GPIO irqchips are encouraged to use a nested and threaded IRQ handler.
 108   Doing so makes the interrupts naturally preemptible on a real time
 109   setup, which means the system can easily be configured for real time with
 110   a (usually negligable) performance loss.
 111
 112   These drivers spawn a thread and then mask the parent IRQ line until the
 113   interrupt is handled by the driver. The hallmark of this driver is to call
 114   something like this in its interrupt handler:
 115
 116   static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
 117       ...
 118       handle_nested_irq(irq);
 119       OR
 120       generic_handle_irq(irq);
 121
 122   Threaded GPIO irqchips should set the .can_sleep flag on struct gpio_chip
 123   to true if they are e.g. accessing the chip over I2C or SPI, indicating that
 124   this chip may sleep when accessing the GPIOs. irqchips that are just made
 125   threaded to be preemptible and thus real time compliant need not do this:
 126   preemption is not sleeping.
 127
 128 To help out in handling the set-up and management of GPIO irqchips and the
 129 associated irqdomain and resource allocation callbacks, the gpiolib has
 130 some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
 131 symbol:
 132
 133 * gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass
 134   the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
 135   need to embed the gpio_chip in its state container and obtain a pointer
 136   to the container using container_of().
 137   (See Documentation/driver-model/design-patterns.txt)
 138
 139 * gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
 140   gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
 141   data. (Notice handler data, since the irqchip data is likely used by the
 142   parent irqchip!) This is for the chained type of chip. This is also used
 143   to set up a threaded/nested irqchip if NULL is passed as handler.
 144
 145 To use the helpers please keep the following in mind:
 146
 147 - Make sure to assign all relevant members of the struct gpio_chip so that
 148   the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
 149   properly.
 150
 151 It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
 152 if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
 153 irq_chip are orthogonal, and offering their services independent of each
 154 other.
 155
 156 gpiod_to_irq() is just a convenience function to figure out the IRQ for a
 157 certain GPIO line and should not be relied upon to have been called before
 158 the IRQ is used.
 159
 160 So always prepare the hardware and make it ready for action in respective
 161 callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
 162 been called first.
 163
 164 This orthogonality leads to ambiguities that we need to solve: if there is
 165 competition inside the subsystem which side is using the resource (a certain
 166 GPIO line and register for example) it needs to deny certain operations and
 167 keep track of usage inside of the gpiolib subsystem. This is why the API
 168 below exists.
 169
 170
 171 Locking IRQ usage
 172 -----------------
 173 Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
 174 to mark the GPIO as being used as an IRQ:
 175
 176         int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
 177
 178 This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
 179 is released:
 180
 181         void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
 182
 183 When implementing an irqchip inside a GPIO driver, these two functions should
 184 typically be called in the .startup() and .shutdown() callbacks from the
 185 irqchip.
 186
 187
 188 Real-Time compliance for GPIO IRQ chips
 189 ---------------------------------------
 190
 191 Any provider of irqchips needs to be carefully tailored to support Real Time
 192 preemption. It is desireable that all irqchips in the GPIO subsystem keep this
 193 in mind and does the proper testing to assure they are real time-enabled. The
 194 following is a checklist to follow when preparing a driver for real
 195 time-compliance:
 196
 197 - Nominally use raw_spinlock_t in the IRQ context path of the IRQ handler as
 198   we do not want these sections to be preempted.
 199
 200 - Do NOT use chained_irq_enter() or chained_irq_exit() in the IRQ handler,
 201   as we want the hotpath to be preemptible.
 202
 203 - Instead use nested IRQs and generic handlers such as handle_bad_irq(),
 204   handle_level_irq() and handle_edge_irq(). Consequentally the handler
 205   argument of gpiochip_set_chained_irqchip() should be NULL when using the
 206   gpiolib irqchip helpers.
 207
 208 - Nominally set all handlers to handle_bad_irq() in the setup call, then
 209   set the handler to handle_level_irq() and/or handle_edge_irq() in the irqchip
 210   .set_type() callback depending on what your controller supports.
 211
 212 - If you need to use the pm_runtime_get*()/pm_runtime_put*() callbacks in some
 213   of the irqchip callbacks, these should be moved to the .irq_bus_lock()
 214   and .irq_bus_unlock() callbacks respectively, as these are the only
 215   slowpath callbacks on an irqchip. Create the callbacks if need be.
 216
 217 - Test your driver with the apropriate in-kernel real time test cases for both
 218   level and edge IRQs.
 219
 220
 221 Requesting self-owned GPIO pins
 222 -------------------------------
 223
 224 Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
 225 descriptors through the gpiolib API. Using gpio_request() for this purpose
 226 does not help since it pins the module to the kernel forever (it calls
 227 try_module_get()). A GPIO driver can use the following functions instead
 228 to request and free descriptors without being pinned to the kernel forever.
 229
 230         struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
 231                                                     const char *label)
 232
 233         void gpiochip_free_own_desc(struct gpio_desc *desc)
 234
 235 Descriptors requested with gpiochip_request_own_desc() must be released with
 236 gpiochip_free_own_desc().
 237
 238 These functions must be used with care since they do not affect module use
 239 count. Do not use the functions to request gpio descriptors not owned by the
 240 calling driver.