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 Locking IRQ usage
  66 -----------------
  67 Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
  68 to mark the GPIO as being used as an IRQ:
  69
  70         int gpiod_lock_as_irq(struct gpio_desc *desc)
  71
  72 This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
  73 is released:
  74
  75         void gpiod_unlock_as_irq(struct gpio_desc *desc)