123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306 |
- GPIO Interfaces
- This provides an overview of GPIO access conventions on Linux.
- What is a GPIO?
- ===============
- A "General Purpose Input/Output" (GPIO) is a flexible software-controlled
- digital signal. They are provided from many kinds of chip, and are familiar
- to Linux developers working with embedded and custom hardware. Each GPIO
- represents a bit connected to a particular pin, or "ball" on Ball Grid Array
- (BGA) packages. Board schematics show which external hardware connects to
- which GPIOs. Drivers can be written generically, so that board setup code
- passes such pin configuration data to drivers.
- System-on-Chip (SOC) processors heavily rely on GPIOs. In some cases, every
- non-dedicated pin can be configured as a GPIO; and most chips have at least
- several dozen of them. Programmable logic devices (like FPGAs) can easily
- provide GPIOs; multifunction chips like power managers, and audio codecs
- often have a few such pins to help with pin scarcity on SOCs; and there are
- also "GPIO Expander" chips that connect using the I2C or SPI serial busses.
- Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS
- firmware knowing how they're used).
- The exact capabilities of GPIOs vary between systems. Common options:
- - Output values are writable (high=1, low=0). Some chips also have
- options about how that value is driven, so that for example only one
- value might be driven ... supporting "wire-OR" and similar schemes
- for the other value (notably, "open drain" signaling).
- - Input values are likewise readable (1, 0). Some chips support readback
- of pins configured as "output", which is very useful in such "wire-OR"
- cases (to support bidirectional signaling). GPIO controllers may have
- input de-glitch logic, sometimes with software controls.
- - Inputs can often be used as IRQ signals, often edge triggered but
- sometimes level triggered. Such IRQs may be configurable as system
- wakeup events, to wake the system from a low power state.
- - Usually a GPIO will be configurable as either input or output, as needed
- by different product boards; single direction ones exist too.
- - Most GPIOs can be accessed while holding spinlocks, but those accessed
- through a serial bus normally can't. Some systems support both types.
- On a given board each GPIO is used for one specific purpose like monitoring
- MMC/SD card insertion/removal, detecting card writeprotect status, driving
- a LED, configuring a transceiver, bitbanging a serial bus, poking a hardware
- watchdog, sensing a switch, and so on.
- GPIO conventions
- ================
- Note that this is called a "convention" because you don't need to do it this
- way, and it's no crime if you don't. There **are** cases where portability
- is not the main issue; GPIOs are often used for the kind of board-specific
- glue logic that may even change between board revisions, and can't ever be
- used on a board that's wired differently. Only least-common-denominator
- functionality can be very portable. Other features are platform-specific,
- and that can be critical for glue logic.
- Plus, this doesn't define an implementation framework, just an interface.
- One platform might implement it as simple inline functions accessing chip
- registers; another might implement it by delegating through abstractions
- used for several very different kinds of GPIO controller.
- That said, if the convention is supported on their platform, drivers should
- use it when possible:
- #include <asm/gpio.h>
- If you stick to this convention then it'll be easier for other developers to
- see what your code is doing, and help maintain it.
- Identifying GPIOs
- -----------------
- GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
- reserves "negative" numbers for other purposes like marking signals as
- "not available on this board", or indicating faults. Code that doesn't
- touch the underlying hardware treats these integers as opaque cookies.
- Platforms define how they use those integers, and usually #define symbols
- for the GPIO lines so that board-specific setup code directly corresponds
- to the relevant schematics. In contrast, drivers should only use GPIO
- numbers passed to them from that setup code, using platform_data to hold
- board-specific pin configuration data (along with other board specific
- data they need). That avoids portability problems.
- So for example one platform uses numbers 32-159 for GPIOs; while another
- uses numbers 0..63 with one set of GPIO controllers, 64-79 with another
- type of GPIO controller, and on one particular board 80-95 with an FPGA.
- The numbers need not be contiguous; either of those platforms could also
- use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
- Whether a platform supports multiple GPIO controllers is currently a
- platform-specific implementation issue.
- Using GPIOs
- -----------
- One of the first things to do with a GPIO, often in board setup code when
- setting up a platform_device using the GPIO, is mark its direction:
- /* set as input or output, returning 0 or negative errno */
- int gpio_direction_input(unsigned gpio);
- int gpio_direction_output(unsigned gpio, int value);
- The return value is zero for success, else a negative errno. It should
- be checked, since the get/set calls don't have error returns and since
- misconfiguration is possible. (These calls could sleep.)
- For output GPIOs, the value provided becomes the initial output value.
- This helps avoid signal glitching during system startup.
- Setting the direction can fail if the GPIO number is invalid, or when
- that particular GPIO can't be used in that mode. It's generally a bad
- idea to rely on boot firmware to have set the direction correctly, since
- it probably wasn't validated to do more than boot Linux. (Similarly,
- that board setup code probably needs to multiplex that pin as a GPIO,
- and configure pullups/pulldowns appropriately.)
- Spinlock-Safe GPIO access
- -------------------------
- Most GPIO controllers can be accessed with memory read/write instructions.
- That doesn't need to sleep, and can safely be done from inside IRQ handlers.
- Use these calls to access such GPIOs:
- /* GPIO INPUT: return zero or nonzero */
- int gpio_get_value(unsigned gpio);
- /* GPIO OUTPUT */
- void gpio_set_value(unsigned gpio, int value);
- The values are boolean, zero for low, nonzero for high. When reading the
- value of an output pin, the value returned should be what's seen on the
- pin ... that won't always match the specified output value, because of
- issues including wire-OR and output latencies.
- The get/set calls have no error returns because "invalid GPIO" should have
- been reported earlier in gpio_set_direction(). However, note that not all
- platforms can read the value of output pins; those that can't should always
- return zero. Also, using these calls for GPIOs that can't safely be accessed
- without sleeping (see below) is an error.
- Platform-specific implementations are encouraged to optimize the two
- calls to access the GPIO value in cases where the GPIO number (and for
- output, value) are constant. It's normal for them to need only a couple
- of instructions in such cases (reading or writing a hardware register),
- and not to need spinlocks. Such optimized calls can make bitbanging
- applications a lot more efficient (in both space and time) than spending
- dozens of instructions on subroutine calls.
- GPIO access that may sleep
- --------------------------
- Some GPIO controllers must be accessed using message based busses like I2C
- or SPI. Commands to read or write those GPIO values require waiting to
- get to the head of a queue to transmit a command and get its response.
- This requires sleeping, which can't be done from inside IRQ handlers.
- Platforms that support this type of GPIO distinguish them from other GPIOs
- by returning nonzero from this call:
- int gpio_cansleep(unsigned gpio);
- To access such GPIOs, a different set of accessors is defined:
- /* GPIO INPUT: return zero or nonzero, might sleep */
- int gpio_get_value_cansleep(unsigned gpio);
- /* GPIO OUTPUT, might sleep */
- void gpio_set_value_cansleep(unsigned gpio, int value);
- Other than the fact that these calls might sleep, and will not be ignored
- for GPIOs that can't be accessed from IRQ handlers, these calls act the
- same as the spinlock-safe calls.
- Claiming and Releasing GPIOs (OPTIONAL)
- ---------------------------------------
- To help catch system configuration errors, two calls are defined.
- However, many platforms don't currently support this mechanism.
- /* request GPIO, returning 0 or negative errno.
- * non-null labels may be useful for diagnostics.
- */
- int gpio_request(unsigned gpio, const char *label);
- /* release previously-claimed GPIO */
- void gpio_free(unsigned gpio);
- Passing invalid GPIO numbers to gpio_request() will fail, as will requesting
- GPIOs that have already been claimed with that call. The return value of
- gpio_request() must be checked. (These calls could sleep.)
- These calls serve two basic purposes. One is marking the signals which
- are actually in use as GPIOs, for better diagnostics; systems may have
- several hundred potential GPIOs, but often only a dozen are used on any
- given board. Another is to catch conflicts between drivers, reporting
- errors when drivers wrongly think they have exclusive use of that signal.
- These two calls are optional because not not all current Linux platforms
- offer such functionality in their GPIO support; a valid implementation
- could return success for all gpio_request() calls. Unlike the other calls,
- the state they represent doesn't normally match anything from a hardware
- register; it's just a software bitmap which clearly is not necessary for
- correct operation of hardware or (bug free) drivers.
- Note that requesting a GPIO does NOT cause it to be configured in any
- way; it just marks that GPIO as in use. Separate code must handle any
- pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
- GPIOs mapped to IRQs
- --------------------
- GPIO numbers are unsigned integers; so are IRQ numbers. These make up
- two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can
- map between them using calls like:
- /* map GPIO numbers to IRQ numbers */
- int gpio_to_irq(unsigned gpio);
- /* map IRQ numbers to GPIO numbers */
- int irq_to_gpio(unsigned irq);
- Those return either the corresponding number in the other namespace, or
- else a negative errno code if the mapping can't be done. (For example,
- some GPIOs can't used as IRQs.) It is an unchecked error to use a GPIO
- number that hasn't been marked as an input using gpio_set_direction(), or
- to use an IRQ number that didn't originally come from gpio_to_irq().
- These two mapping calls are expected to cost on the order of a single
- addition or subtraction. They're not allowed to sleep.
- Non-error values returned from gpio_to_irq() can be passed to request_irq()
- or free_irq(). They will often be stored into IRQ resources for platform
- devices, by the board-specific initialization code. Note that IRQ trigger
- options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are
- system wakeup capabilities.
- Non-error values returned from irq_to_gpio() would most commonly be used
- with gpio_get_value(), for example to initialize or update driver state
- when the IRQ is edge-triggered.
- Emulating Open Drain Signals
- ----------------------------
- Sometimes shared signals need to use "open drain" signaling, where only the
- low signal level is actually driven. (That term applies to CMOS transistors;
- "open collector" is used for TTL.) A pullup resistor causes the high signal
- level. This is sometimes called a "wire-AND"; or more practically, from the
- negative logic (low=true) perspective this is a "wire-OR".
- One common example of an open drain signal is a shared active-low IRQ line.
- Also, bidirectional data bus signals sometimes use open drain signals.
- Some GPIO controllers directly support open drain outputs; many don't. When
- you need open drain signaling but your hardware doesn't directly support it,
- there's a common idiom you can use to emulate it with any GPIO pin that can
- be used as either an input or an output:
- LOW: gpio_direction_output(gpio, 0) ... this drives the signal
- and overrides the pullup.
- HIGH: gpio_direction_input(gpio) ... this turns off the output,
- so the pullup (or some other device) controls the signal.
- If you are "driving" the signal high but gpio_get_value(gpio) reports a low
- value (after the appropriate rise time passes), you know some other component
- is driving the shared signal low. That's not necessarily an error. As one
- common example, that's how I2C clocks are stretched: a slave that needs a
- slower clock delays the rising edge of SCK, and the I2C master adjusts its
- signaling rate accordingly.
- What do these conventions omit?
- ===============================
- One of the biggest things these conventions omit is pin multiplexing, since
- this is highly chip-specific and nonportable. One platform might not need
- explicit multiplexing; another might have just two options for use of any
- given pin; another might have eight options per pin; another might be able
- to route a given GPIO to any one of several pins. (Yes, those examples all
- come from systems that run Linux today.)
- Related to multiplexing is configuration and enabling of the pullups or
- pulldowns integrated on some platforms. Not all platforms support them,
- or support them in the same way; and any given board might use external
- pullups (or pulldowns) so that the on-chip ones should not be used.
- There are other system-specific mechanisms that are not specified here,
- like the aforementioned options for input de-glitching and wire-OR output.
- Hardware may support reading or writing GPIOs in gangs, but that's usually
- configuration dependent: for GPIOs sharing the same bank. (GPIOs are
- commonly grouped in banks of 16 or 32, with a given SOC having several such
- banks.) Some systems can trigger IRQs from output GPIOs. Code relying on
- such mechanisms will necessarily be nonportable.
- Dynamic definition of GPIOs is not currently supported; for example, as
- a side effect of configuring an add-on board with some GPIO expanders.
- These calls are purely for kernel space, but a userspace API could be built
- on top of it.
|