^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Legacy GPIO Interfaces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) This provides an overview of GPIO access conventions on Linux.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) These calls use the gpio_* naming prefix. No other calls should use that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) prefix, or the related __gpio_* prefix.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) What is a GPIO?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) A "General Purpose Input/Output" (GPIO) is a flexible software-controlled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) digital signal. They are provided from many kinds of chip, and are familiar
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) to Linux developers working with embedded and custom hardware. Each GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) represents a bit connected to a particular pin, or "ball" on Ball Grid Array
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) (BGA) packages. Board schematics show which external hardware connects to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) which GPIOs. Drivers can be written generically, so that board setup code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) passes such pin configuration data to drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) System-on-Chip (SOC) processors heavily rely on GPIOs. In some cases, every
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) non-dedicated pin can be configured as a GPIO; and most chips have at least
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) several dozen of them. Programmable logic devices (like FPGAs) can easily
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) provide GPIOs; multifunction chips like power managers, and audio codecs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) often have a few such pins to help with pin scarcity on SOCs; and there are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) also "GPIO Expander" chips that connect using the I2C or SPI serial busses.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) firmware knowing how they're used).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) The exact capabilities of GPIOs vary between systems. Common options:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) - Output values are writable (high=1, low=0). Some chips also have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) options about how that value is driven, so that for example only one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) value might be driven ... supporting "wire-OR" and similar schemes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) for the other value (notably, "open drain" signaling).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) - Input values are likewise readable (1, 0). Some chips support readback
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) of pins configured as "output", which is very useful in such "wire-OR"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) cases (to support bidirectional signaling). GPIO controllers may have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) input de-glitch/debounce logic, sometimes with software controls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) - Inputs can often be used as IRQ signals, often edge triggered but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) sometimes level triggered. Such IRQs may be configurable as system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) wakeup events, to wake the system from a low power state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) - Usually a GPIO will be configurable as either input or output, as needed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) by different product boards; single direction ones exist too.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) - Most GPIOs can be accessed while holding spinlocks, but those accessed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) through a serial bus normally can't. Some systems support both types.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) On a given board each GPIO is used for one specific purpose like monitoring
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) MMC/SD card insertion/removal, detecting card writeprotect status, driving
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) a LED, configuring a transceiver, bitbanging a serial bus, poking a hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) watchdog, sensing a switch, and so on.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) GPIO conventions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) Note that this is called a "convention" because you don't need to do it this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) way, and it's no crime if you don't. There **are** cases where portability
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) is not the main issue; GPIOs are often used for the kind of board-specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) glue logic that may even change between board revisions, and can't ever be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) used on a board that's wired differently. Only least-common-denominator
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) functionality can be very portable. Other features are platform-specific,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) and that can be critical for glue logic.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) Plus, this doesn't require any implementation framework, just an interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) One platform might implement it as simple inline functions accessing chip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) registers; another might implement it by delegating through abstractions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) used for several very different kinds of GPIO controller. (There is some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) optional code supporting such an implementation strategy, described later
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) in this document, but drivers acting as clients to the GPIO interface must
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) not care how it's implemented.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) That said, if the convention is supported on their platform, drivers should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) use it when possible. Platforms must select GPIOLIB if GPIO functionality
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) is strictly required. Drivers that can't work without
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) standard GPIO calls should have Kconfig entries which depend on GPIOLIB. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) GPIO calls are available, either as "real code" or as optimized-away stubs,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) when drivers use the include file:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) #include <linux/gpio.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) If you stick to this convention then it'll be easier for other developers to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) see what your code is doing, and help maintain it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) Note that these operations include I/O barriers on platforms which need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) use them; drivers don't need to add them explicitly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) Identifying GPIOs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) -----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) reserves "negative" numbers for other purposes like marking signals as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) "not available on this board", or indicating faults. Code that doesn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) touch the underlying hardware treats these integers as opaque cookies.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) Platforms define how they use those integers, and usually #define symbols
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) for the GPIO lines so that board-specific setup code directly corresponds
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) to the relevant schematics. In contrast, drivers should only use GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) numbers passed to them from that setup code, using platform_data to hold
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) board-specific pin configuration data (along with other board specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) data they need). That avoids portability problems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) So for example one platform uses numbers 32-159 for GPIOs; while another
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) uses numbers 0..63 with one set of GPIO controllers, 64-79 with another
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) type of GPIO controller, and on one particular board 80-95 with an FPGA.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) The numbers need not be contiguous; either of those platforms could also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) If you want to initialize a structure with an invalid GPIO number, use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) some negative number (perhaps "-EINVAL"); that will never be valid. To
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) test if such number from such a structure could reference a GPIO, you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) may use this predicate:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) int gpio_is_valid(int number);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) A number that's not valid will be rejected by calls which may request
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) or free GPIOs (see below). Other numbers may also be rejected; for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) example, a number might be valid but temporarily unused on a given board.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) Whether a platform supports multiple GPIO controllers is a platform-specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) implementation issue, as are whether that support can leave "holes" in the space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) of GPIO numbers, and whether new controllers can be added at runtime. Such issues
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) can affect things including whether adjacent GPIO numbers are both valid.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) Using GPIOs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) -----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) The first thing a system should do with a GPIO is allocate it, using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) the gpio_request() call; see later.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) One of the next things to do with a GPIO, often in board setup code when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) setting up a platform_device using the GPIO, is mark its direction::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) /* set as input or output, returning 0 or negative errno */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) int gpio_direction_input(unsigned gpio);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) int gpio_direction_output(unsigned gpio, int value);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) The return value is zero for success, else a negative errno. It should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) be checked, since the get/set calls don't have error returns and since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) misconfiguration is possible. You should normally issue these calls from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) a task context. However, for spinlock-safe GPIOs it's OK to use them
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) before tasking is enabled, as part of early board setup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) For output GPIOs, the value provided becomes the initial output value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) This helps avoid signal glitching during system startup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) For compatibility with legacy interfaces to GPIOs, setting the direction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) of a GPIO implicitly requests that GPIO (see below) if it has not been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) requested already. That compatibility is being removed from the optional
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) gpiolib framework.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) Setting the direction can fail if the GPIO number is invalid, or when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) that particular GPIO can't be used in that mode. It's generally a bad
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) idea to rely on boot firmware to have set the direction correctly, since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) it probably wasn't validated to do more than boot Linux. (Similarly,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) that board setup code probably needs to multiplex that pin as a GPIO,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) and configure pullups/pulldowns appropriately.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) Spinlock-Safe GPIO access
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) -------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) Most GPIO controllers can be accessed with memory read/write instructions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) Those don't need to sleep, and can safely be done from inside hard
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) (nonthreaded) IRQ handlers and similar contexts.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) Use the following calls to access such GPIOs,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) for which gpio_cansleep() will always return false (see below)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) /* GPIO INPUT: return zero or nonzero */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) int gpio_get_value(unsigned gpio);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) /* GPIO OUTPUT */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) void gpio_set_value(unsigned gpio, int value);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) The values are boolean, zero for low, nonzero for high. When reading the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) value of an output pin, the value returned should be what's seen on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) pin ... that won't always match the specified output value, because of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) issues including open-drain signaling and output latencies.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) The get/set calls have no error returns because "invalid GPIO" should have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) been reported earlier from gpio_direction_*(). However, note that not all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) platforms can read the value of output pins; those that can't should always
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) return zero. Also, using these calls for GPIOs that can't safely be accessed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) without sleeping (see below) is an error.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) Platform-specific implementations are encouraged to optimize the two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) calls to access the GPIO value in cases where the GPIO number (and for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) output, value) are constant. It's normal for them to need only a couple
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) of instructions in such cases (reading or writing a hardware register),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) and not to need spinlocks. Such optimized calls can make bitbanging
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) applications a lot more efficient (in both space and time) than spending
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) dozens of instructions on subroutine calls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) GPIO access that may sleep
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) Some GPIO controllers must be accessed using message based busses like I2C
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) or SPI. Commands to read or write those GPIO values require waiting to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) get to the head of a queue to transmit a command and get its response.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) This requires sleeping, which can't be done from inside IRQ handlers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) Platforms that support this type of GPIO distinguish them from other GPIOs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) by returning nonzero from this call (which requires a valid GPIO number,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) which should have been previously allocated with gpio_request)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) int gpio_cansleep(unsigned gpio);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) To access such GPIOs, a different set of accessors is defined::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) /* GPIO INPUT: return zero or nonzero, might sleep */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) int gpio_get_value_cansleep(unsigned gpio);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) /* GPIO OUTPUT, might sleep */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) void gpio_set_value_cansleep(unsigned gpio, int value);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) Accessing such GPIOs requires a context which may sleep, for example
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) a threaded IRQ handler, and those accessors must be used instead of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) spinlock-safe accessors without the cansleep() name suffix.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) Other than the fact that these accessors might sleep, and will work
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) on GPIOs that can't be accessed from hardIRQ handlers, these calls act
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) the same as the spinlock-safe calls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) **IN ADDITION** calls to setup and configure such GPIOs must be made
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) from contexts which may sleep, since they may need to access the GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) controller chip too (These setup calls are usually made from board
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) setup or driver probe/teardown code, so this is an easy constraint.)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) gpio_direction_input()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) gpio_direction_output()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) gpio_request()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) ## gpio_request_one()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) ## gpio_request_array()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) ## gpio_free_array()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) gpio_free()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) gpio_set_debounce()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) Claiming and Releasing GPIOs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) ----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) To help catch system configuration errors, two calls are defined::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) /* request GPIO, returning 0 or negative errno.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) * non-null labels may be useful for diagnostics.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) int gpio_request(unsigned gpio, const char *label);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) /* release previously-claimed GPIO */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) void gpio_free(unsigned gpio);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) Passing invalid GPIO numbers to gpio_request() will fail, as will requesting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) GPIOs that have already been claimed with that call. The return value of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) gpio_request() must be checked. You should normally issue these calls from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) a task context. However, for spinlock-safe GPIOs it's OK to request GPIOs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) before tasking is enabled, as part of early board setup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) These calls serve two basic purposes. One is marking the signals which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) are actually in use as GPIOs, for better diagnostics; systems may have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) several hundred potential GPIOs, but often only a dozen are used on any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) given board. Another is to catch conflicts, identifying errors when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) (a) two or more drivers wrongly think they have exclusive use of that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) signal, or (b) something wrongly believes it's safe to remove drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) needed to manage a signal that's in active use. That is, requesting a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) GPIO can serve as a kind of lock.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) Some platforms may also use knowledge about what GPIOs are active for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) power management, such as by powering down unused chip sectors and, more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) easily, gating off unused clocks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) For GPIOs that use pins known to the pinctrl subsystem, that subsystem should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) be informed of their use; a gpiolib driver's .request() operation may call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) pinctrl_gpio_request(), and a gpiolib driver's .free() operation may call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) pinctrl_gpio_free(). The pinctrl subsystem allows a pinctrl_gpio_request()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) to succeed concurrently with a pin or pingroup being "owned" by a device for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) pin multiplexing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) Any programming of pin multiplexing hardware that is needed to route the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) GPIO signal to the appropriate pin should occur within a GPIO driver's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) .direction_input() or .direction_output() operations, and occur after any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) setup of an output GPIO's value. This allows a glitch-free migration from a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) pin's special function to GPIO. This is sometimes required when using a GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) to implement a workaround on signals typically driven by a non-GPIO HW block.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) Some platforms allow some or all GPIO signals to be routed to different pins.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) Similarly, other aspects of the GPIO or pin may need to be configured, such as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) pullup/pulldown. Platform software should arrange that any such details are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) configured prior to gpio_request() being called for those GPIOs, e.g. using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) the pinctrl subsystem's mapping table, so that GPIO users need not be aware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) of these details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) Also note that it's your responsibility to have stopped using a GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) before you free it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) Considering in most cases GPIOs are actually configured right after they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) are claimed, three additional calls are defined::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) /* request a single GPIO, with initial configuration specified by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) * 'flags', identical to gpio_request() wrt other arguments and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) * return value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) int gpio_request_one(unsigned gpio, unsigned long flags, const char *label);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) /* request multiple GPIOs in a single call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) int gpio_request_array(struct gpio *array, size_t num);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) /* release multiple GPIOs in a single call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) void gpio_free_array(struct gpio *array, size_t num);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) where 'flags' is currently defined to specify the following properties:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) * GPIOF_DIR_IN - to configure direction as input
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) * GPIOF_DIR_OUT - to configure direction as output
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) * GPIOF_INIT_LOW - as output, set initial level to LOW
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) * GPIOF_INIT_HIGH - as output, set initial level to HIGH
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324) * GPIOF_OPEN_DRAIN - gpio pin is open drain type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) * GPIOF_OPEN_SOURCE - gpio pin is open source type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) * GPIOF_EXPORT_DIR_FIXED - export gpio to sysfs, keep direction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) * GPIOF_EXPORT_DIR_CHANGEABLE - also export, allow changing direction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) since GPIOF_INIT_* are only valid when configured as output, so group valid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) combinations as:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) * GPIOF_IN - configure as input
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) * GPIOF_OUT_INIT_LOW - configured as output, initial level LOW
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) * GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) open drain type. Such pins will not be driven to 1 in output mode. It is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) require to connect pull-up on such pins. By enabling this flag, gpio lib will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) make the direction to input when it is asked to set value of 1 in output mode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) to make the pin HIGH. The pin is make to LOW by driving value 0 in output mode.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) When setting the flag as GPIOF_OPEN_SOURCE then it will assume that pins is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) open source type. Such pins will not be driven to 0 in output mode. It is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) require to connect pull-down on such pin. By enabling this flag, gpio lib will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) make the direction to input when it is asked to set value of 0 in output mode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) to make the pin LOW. The pin is make to HIGH by driving value 1 in output mode.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) In the future, these flags can be extended to support more properties.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351) Further more, to ease the claim/release of multiple GPIOs, 'struct gpio' is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) introduced to encapsulate all three fields as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) struct gpio {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355) unsigned gpio;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) unsigned long flags;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) const char *label;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) A typical example of usage::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) static struct gpio leds_gpios[] = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) { 32, GPIOF_OUT_INIT_HIGH, "Power LED" }, /* default to ON */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) { 33, GPIOF_OUT_INIT_LOW, "Green LED" }, /* default to OFF */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) { 34, GPIOF_OUT_INIT_LOW, "Red LED" }, /* default to OFF */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) { 35, GPIOF_OUT_INIT_LOW, "Blue LED" }, /* default to OFF */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) { ... },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) err = gpio_request_one(31, GPIOF_IN, "Reset Button");
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) if (err)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) err = gpio_request_array(leds_gpios, ARRAY_SIZE(leds_gpios));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) if (err)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) gpio_free_array(leds_gpios, ARRAY_SIZE(leds_gpios));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) GPIOs mapped to IRQs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) --------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) GPIO numbers are unsigned integers; so are IRQ numbers. These make up
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) map between them using calls like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) /* map GPIO numbers to IRQ numbers */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) int gpio_to_irq(unsigned gpio);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390) /* map IRQ numbers to GPIO numbers (avoid using this) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) int irq_to_gpio(unsigned irq);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) Those return either the corresponding number in the other namespace, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) else a negative errno code if the mapping can't be done. (For example,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) some GPIOs can't be used as IRQs.) It is an unchecked error to use a GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) number that wasn't set up as an input using gpio_direction_input(), or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) to use an IRQ number that didn't originally come from gpio_to_irq().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399) These two mapping calls are expected to cost on the order of a single
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) addition or subtraction. They're not allowed to sleep.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) Non-error values returned from gpio_to_irq() can be passed to request_irq()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) or free_irq(). They will often be stored into IRQ resources for platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) devices, by the board-specific initialization code. Note that IRQ trigger
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) system wakeup capabilities.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) Non-error values returned from irq_to_gpio() would most commonly be used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) with gpio_get_value(), for example to initialize or update driver state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) when the IRQ is edge-triggered. Note that some platforms don't support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) this reverse mapping, so you should avoid using it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) Emulating Open Drain Signals
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) ----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416) Sometimes shared signals need to use "open drain" signaling, where only the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) low signal level is actually driven. (That term applies to CMOS transistors;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) "open collector" is used for TTL.) A pullup resistor causes the high signal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) level. This is sometimes called a "wire-AND"; or more practically, from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) negative logic (low=true) perspective this is a "wire-OR".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422) One common example of an open drain signal is a shared active-low IRQ line.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) Also, bidirectional data bus signals sometimes use open drain signals.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) Some GPIO controllers directly support open drain outputs; many don't. When
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) you need open drain signaling but your hardware doesn't directly support it,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) there's a common idiom you can use to emulate it with any GPIO pin that can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) be used as either an input or an output:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) LOW: gpio_direction_output(gpio, 0) ... this drives the signal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) and overrides the pullup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) HIGH: gpio_direction_input(gpio) ... this turns off the output,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) so the pullup (or some other device) controls the signal.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) If you are "driving" the signal high but gpio_get_value(gpio) reports a low
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) value (after the appropriate rise time passes), you know some other component
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) is driving the shared signal low. That's not necessarily an error. As one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) common example, that's how I2C clocks are stretched: a slave that needs a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440) slower clock delays the rising edge of SCK, and the I2C master adjusts its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) signaling rate accordingly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) GPIO controllers and the pinctrl subsystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) ------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) A GPIO controller on a SOC might be tightly coupled with the pinctrl
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) subsystem, in the sense that the pins can be used by other functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) together with an optional gpio feature. We have already covered the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) case where e.g. a GPIO controller need to reserve a pin or set the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) direction of a pin by calling any of::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) pinctrl_gpio_request()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454) pinctrl_gpio_free()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) pinctrl_gpio_direction_input()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) pinctrl_gpio_direction_output()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) But how does the pin control subsystem cross-correlate the GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) numbers (which are a global business) to a certain pin on a certain
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) pin controller?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) This is done by registering "ranges" of pins, which are essentially
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) cross-reference tables. These are described in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) Documentation/driver-api/pinctl.rst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) While the pin allocation is totally managed by the pinctrl subsystem,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) gpio (under gpiolib) is still maintained by gpio drivers. It may happen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) that different pin ranges in a SoC is managed by different gpio drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470) This makes it logical to let gpio drivers announce their pin ranges to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) the pin ctrl subsystem before it will call 'pinctrl_gpio_request' in order
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) to request the corresponding pin to be prepared by the pinctrl subsystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473) before any gpio usage.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) For this, the gpio controller can register its pin range with pinctrl
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) subsystem. There are two ways of doing it currently: with or without DT.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) For with DT support refer to Documentation/devicetree/bindings/gpio/gpio.txt.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) For non-DT support, user can call gpiochip_add_pin_range() with appropriate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) parameters to register a range of gpio pins with a pinctrl driver. For this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) exact name string of pinctrl device has to be passed as one of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) argument to this routine.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) What do these conventions omit?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) One of the biggest things these conventions omit is pin multiplexing, since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489) this is highly chip-specific and nonportable. One platform might not need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) explicit multiplexing; another might have just two options for use of any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) given pin; another might have eight options per pin; another might be able
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) to route a given GPIO to any one of several pins. (Yes, those examples all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) come from systems that run Linux today.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) Related to multiplexing is configuration and enabling of the pullups or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) pulldowns integrated on some platforms. Not all platforms support them,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) or support them in the same way; and any given board might use external
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) pullups (or pulldowns) so that the on-chip ones should not be used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) (When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) platform-specific issue, as are models like (not) having a one-to-one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) correspondence between configurable pins and GPIOs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504) There are other system-specific mechanisms that are not specified here,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) like the aforementioned options for input de-glitching and wire-OR output.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506) Hardware may support reading or writing GPIOs in gangs, but that's usually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507) configuration dependent: for GPIOs sharing the same bank. (GPIOs are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) commonly grouped in banks of 16 or 32, with a given SOC having several such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) banks.) Some systems can trigger IRQs from output GPIOs, or read values
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510) from pins not managed as GPIOs. Code relying on such mechanisms will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511) necessarily be nonportable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) Dynamic definition of GPIOs is not currently standard; for example, as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514) a side effect of configuring an add-on board with some GPIO expanders.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517) GPIO implementor's framework (OPTIONAL)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) =======================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) As noted earlier, there is an optional implementation framework making it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520) easier for platforms to support different kinds of GPIO controller using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) the same programming interface. This framework is called "gpiolib".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) As a debugging aid, if debugfs is available a /sys/kernel/debug/gpio file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524) will be found there. That will list all the controllers registered through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) this framework, and the state of the GPIOs currently in use.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) Controller Drivers: gpio_chip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529) -----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530) In this framework each GPIO controller is packaged as a "struct gpio_chip"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) with information common to each controller of that type:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) - methods to establish GPIO direction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534) - methods used to access GPIO values
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) - flag saying whether calls to its methods may sleep
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536) - optional debugfs dump method (showing extra state like pullup config)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537) - label for diagnostics
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) There is also per-instance data, which may come from device.platform_data:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540) the number of its first GPIO, and how many GPIOs it exposes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) The code implementing a gpio_chip should support multiple instances of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543) controller, possibly using the driver model. That code will configure each
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544) gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) rare; use gpiochip_remove() when it is unavoidable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547) Most often a gpio_chip is part of an instance-specific structure with state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) not exposed by the GPIO interfaces, such as addressing, power management,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) and more. Chips such as codecs will have complex non-GPIO state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551) Any debugfs dump method should normally ignore signals which haven't been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) requested as GPIOs. They can use gpiochip_is_requested(), which returns
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) either NULL or the label associated with that GPIO when it was requested.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556) Platform Support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) ----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) To force-enable this framework, a platform's Kconfig will "select" GPIOLIB,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) else it is up to the user to configure support for GPIO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561) It may also provide a custom value for ARCH_NR_GPIOS, so that it better
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562) reflects the number of GPIOs in actual use on that platform, without
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563) wasting static table space. (It should count both built-in/SoC GPIOs and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564) also ones on GPIO expanders.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566) If neither of these options are selected, the platform does not support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567) GPIOs through GPIO-lib and the code cannot be enabled by the user.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) Trivial implementations of those functions can directly use framework
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) code, which always dispatches through the gpio_chip::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572) #define gpio_get_value __gpio_get_value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) #define gpio_set_value __gpio_set_value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) #define gpio_cansleep __gpio_cansleep
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) Fancier implementations could instead define those as inline functions with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577) logic optimizing access to specific SOC-based GPIOs. For example, if the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578) referenced GPIO is the constant "12", getting or setting its value could
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) cost as little as two or three instructions, never sleeping. When such an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) optimization is not possible those calls must delegate to the framework
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581) code, costing at least a few dozen instructions. For bitbanged I/O, such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582) instruction savings can be significant.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584) For SOCs, platform-specific code defines and registers gpio_chip instances
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) for each bank of on-chip GPIOs. Those GPIOs should be numbered/labeled to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586) match chip vendor documentation, and directly match board schematics. They
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587) may well start at zero and go up to a platform-specific limit. Such GPIOs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) are normally integrated into platform initialization to make them always be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) available, from arch_initcall() or earlier; they can often serve as IRQs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) Board Support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594) For external GPIO controllers -- such as I2C or SPI expanders, ASICs, multi
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) function devices, FPGAs or CPLDs -- most often board-specific code handles
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596) registering controller devices and ensures that their drivers know what GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597) numbers to use with gpiochip_add(). Their numbers often start right after
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) platform-specific GPIOs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600) For example, board setup code could create structures identifying the range
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601) of GPIOs that chip will expose, and passes them to each GPIO expander chip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602) using platform_data. Then the chip driver's probe() routine could pass that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603) data to gpiochip_add().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605) Initialization order can be important. For example, when a device relies on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606) an I2C-based GPIO, its probe() routine should only be called after that GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607) becomes available. That may mean the device should not be registered until
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608) calls for that GPIO can work. One way to address such dependencies is for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609) such gpio_chip controllers to provide setup() and teardown() callbacks to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) board specific code; those board specific callbacks would register devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) once all the necessary resources are available, and remove them later when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612) the GPIO controller device becomes unavailable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615) Sysfs Interface for Userspace (OPTIONAL)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616) ========================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617) Platforms which use the "gpiolib" implementors framework may choose to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618) configure a sysfs user interface to GPIOs. This is different from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619) debugfs interface, since it provides control over GPIO direction and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620) value instead of just showing a gpio state summary. Plus, it could be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621) present on production systems without debugging support.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) Given appropriate hardware documentation for the system, userspace could
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624) know for example that GPIO #23 controls the write protect line used to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625) protect boot loader segments in flash memory. System upgrade procedures
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626) may need to temporarily remove that protection, first importing a GPIO,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627) then changing its output state, then updating the code before re-enabling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628) the write protection. In normal use, GPIO #23 would never be touched,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629) and the kernel would have no need to know about it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631) Again depending on appropriate hardware documentation, on some systems
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632) userspace GPIO can be used to determine system configuration data that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633) standard kernels won't know about. And for some tasks, simple userspace
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634) GPIO drivers could be all that the system really needs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636) Note that standard kernel drivers exist for common "LEDs and Buttons"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 637) GPIO tasks: "leds-gpio" and "gpio_keys", respectively. Use those
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 638) instead of talking directly to the GPIOs; they integrate with kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 639) frameworks better than your userspace code could.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 640)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 641)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 642) Paths in Sysfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 643) --------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 644) There are three kinds of entry in /sys/class/gpio:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 645)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 646) - Control interfaces used to get userspace control over GPIOs;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 647)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 648) - GPIOs themselves; and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 649)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 650) - GPIO controllers ("gpio_chip" instances).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 651)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 652) That's in addition to standard files including the "device" symlink.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 653)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 654) The control interfaces are write-only:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 655)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 656) /sys/class/gpio/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 657)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 658) "export" ... Userspace may ask the kernel to export control of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 659) a GPIO to userspace by writing its number to this file.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 660)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 661) Example: "echo 19 > export" will create a "gpio19" node
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 662) for GPIO #19, if that's not requested by kernel code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 663)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 664) "unexport" ... Reverses the effect of exporting to userspace.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 665)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 666) Example: "echo 19 > unexport" will remove a "gpio19"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 667) node exported using the "export" file.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 668)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 669) GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 670) and have the following read/write attributes:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 671)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 672) /sys/class/gpio/gpioN/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 673)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 674) "direction" ... reads as either "in" or "out". This value may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 675) normally be written. Writing as "out" defaults to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 676) initializing the value as low. To ensure glitch free
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 677) operation, values "low" and "high" may be written to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 678) configure the GPIO as an output with that initial value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 679)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 680) Note that this attribute *will not exist* if the kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 681) doesn't support changing the direction of a GPIO, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 682) it was exported by kernel code that didn't explicitly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 683) allow userspace to reconfigure this GPIO's direction.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 684)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 685) "value" ... reads as either 0 (low) or 1 (high). If the GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 686) is configured as an output, this value may be written;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 687) any nonzero value is treated as high.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 688)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 689) If the pin can be configured as interrupt-generating interrupt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 690) and if it has been configured to generate interrupts (see the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 691) description of "edge"), you can poll(2) on that file and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 692) poll(2) will return whenever the interrupt was triggered. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 693) you use poll(2), set the events POLLPRI. If you use select(2),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 694) set the file descriptor in exceptfds. After poll(2) returns,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 695) either lseek(2) to the beginning of the sysfs file and read the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 696) new value or close the file and re-open it to read the value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 697)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 698) "edge" ... reads as either "none", "rising", "falling", or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 699) "both". Write these strings to select the signal edge(s)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 700) that will make poll(2) on the "value" file return.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 701)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 702) This file exists only if the pin can be configured as an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 703) interrupt generating input pin.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 704)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 705) "active_low" ... reads as either 0 (false) or 1 (true). Write
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 706) any nonzero value to invert the value attribute both
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 707) for reading and writing. Existing and subsequent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 708) poll(2) support configuration via the edge attribute
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 709) for "rising" and "falling" edges will follow this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 710) setting.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 711)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 712) GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 713) controller implementing GPIOs starting at #42) and have the following
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 714) read-only attributes:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 715)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 716) /sys/class/gpio/gpiochipN/
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 717)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 718) "base" ... same as N, the first GPIO managed by this chip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 719)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 720) "label" ... provided for diagnostics (not always unique)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 721)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 722) "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 723)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 724) Board documentation should in most cases cover what GPIOs are used for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 725) what purposes. However, those numbers are not always stable; GPIOs on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 726) a daughtercard might be different depending on the base board being used,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 727) or other cards in the stack. In such cases, you may need to use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 728) gpiochip nodes (possibly in conjunction with schematics) to determine
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 729) the correct GPIO number to use for a given signal.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 730)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 731)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 732) Exporting from Kernel code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 733) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 734) Kernel code can explicitly manage exports of GPIOs which have already been
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 735) requested using gpio_request()::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 736)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 737) /* export the GPIO to userspace */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 738) int gpio_export(unsigned gpio, bool direction_may_change);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 739)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 740) /* reverse gpio_export() */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 741) void gpio_unexport();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 742)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 743) /* create a sysfs link to an exported GPIO node */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 744) int gpio_export_link(struct device *dev, const char *name,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 745) unsigned gpio)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 746)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 747) After a kernel driver requests a GPIO, it may only be made available in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 748) the sysfs interface by gpio_export(). The driver can control whether the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 749) signal direction may change. This helps drivers prevent userspace code
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 750) from accidentally clobbering important system state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 751)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 752) This explicit exporting can help with debugging (by making some kinds
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 753) of experiments easier), or can provide an always-there interface that's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 754) suitable for documenting as part of a board support package.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 755)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 756) After the GPIO has been exported, gpio_export_link() allows creating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 757) symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 758) use this to provide the interface under their own device in sysfs with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 759) a descriptive name.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 760)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 761)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 762) API Reference
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 763) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 764)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 765) The functions listed in this section are deprecated. The GPIO descriptor based
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 766) API should be used in new code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 767)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 768) .. kernel-doc:: drivers/gpio/gpiolib-legacy.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 769) :export:
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags