这里会显示出您选择的修订版和当前版本之间的差别。
jaysnote:gpio_legacy [2019/04/26 17:02] jaylee |
jaysnote:gpio_legacy [2021/06/22 23:14] |
||
---|---|---|---|
行 1: | 行 1: | ||
- | < | ||
- | # GPIO Interfaces | ||
- | |||
- | * 整理自 [gpio-legacy.txt](https:// | ||
- | * pdf下载 [gpio_interfaces.pdf](http:// | ||
- | |||
- | This provides an overview of GPIO access conventions on Linux. | ||
- | |||
- | These calls use the gpio_* naming prefix. | ||
- | |||
- | |||
- | ## What is a GPIO? | ||
- | |||
- | A " | ||
- | (BGA) packages. | ||
- | |||
- | System-on-Chip (SOC) processors heavily rely on GPIOs. | ||
- | Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS firmware knowing how they' | ||
- | |||
- | The exact capabilities of GPIOs vary between systems. | ||
- | |||
- | - Output values are writable (high=1, low=0). | ||
- | | ||
- | - Input values are likewise readable (1, 0). Some chips support readback of pins configured as " | ||
- | | ||
- | - Inputs can often be used as IRQ signals, often edge triggered but sometimes level triggered. | ||
- | | ||
- | - 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' | ||
- | |||
- | On a given board each GPIO is used for one specific purpose like monitoring MMC/SD card insertion/ | ||
- | |||
- | |||
- | ## GPIO conventions | ||
- | |||
- | Note that this is called a " | ||
- | |||
- | Plus, this doesn' | ||
- | 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 < | ||
- | |||
- | 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. | ||
- | |||
- | Note that these operations include I/O barriers on platforms which need to use them; drivers don't need to add them explicitly. | ||
- | |||
- | |||
- | ### Identifying GPIOs | ||
- | |||
- | GPIOs are identified by unsigned integers in the range 0..MAX_INT. | ||
- | "not available on this board", | ||
- | |||
- | 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. | ||
- | |||
- | So for example one platform uses numbers 32-159 for GPIOs; while another uses numbers 0..63 with one set of GPIO controllers, | ||
- | 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. | ||
- | |||
- | If you want to initialize a structure with an invalid GPIO number, use some negative number (perhaps " | ||
- | |||
- | int gpio_is_valid(int number); | ||
- | |||
- | A number that's not valid will be rejected by calls which may request or free GPIOs (see below). | ||
- | |||
- | Whether a platform supports multiple GPIO controllers is a platform-specific implementation issue, as are whether that support can leave " | ||
- | |||
- | ### Using GPIOs | ||
- | |||
- | |||
- | The first thing a system should do with a GPIO is allocate it, using the gpio_request() call; see later. | ||
- | |||
- | One of the next 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. | ||
- | |||
- | For output GPIOs, the value provided becomes the initial output value. | ||
- | This helps avoid signal glitching during system startup. | ||
- | |||
- | For compatibility with legacy interfaces to GPIOs, setting the direction of a GPIO implicitly requests that GPIO (see below) if it has not been requested already. | ||
- | |||
- | 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. | ||
- | that board setup code probably needs to multiplex that pin as a GPIO, | ||
- | and configure pullups/ | ||
- | |||
- | |||
- | ### Spinlock-Safe GPIO access | ||
- | |||
- | Most GPIO controllers can be accessed with memory read/write instructions. | ||
- | Those don't need to sleep, and can safely be done from inside hard (nonthreaded) IRQ handlers and similar contexts. | ||
- | |||
- | Use the following calls to access such GPIOs,for which gpio_cansleep() will always return false (see below): | ||
- | |||
- | /* GPIO INPUT: | ||
- | 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 open-drain signaling and output latencies. | ||
- | |||
- | The get/set calls have no error returns because " | ||
- | |||
- | 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. | ||
- | and not to need spinlocks. | ||
- | |||
- | |||
- | ### 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 (which requires a valid GPIO number, | ||
- | which should have been previously allocated with gpio_request): | ||
- | |||
- | int gpio_cansleep(unsigned gpio); | ||
- | |||
- | To access such GPIOs, a different set of accessors is defined: | ||
- | |||
- | /* GPIO INPUT: | ||
- | int gpio_get_value_cansleep(unsigned gpio); | ||
- | |||
- | /* GPIO OUTPUT, might sleep */ | ||
- | void gpio_set_value_cansleep(unsigned gpio, int value); | ||
- | |||
- | |||
- | Accessing such GPIOs requires a context which may sleep, | ||
- | |||
- | Other than the fact that these accessors might sleep, and will work on GPIOs that can't be accessed from hardIRQ handlers, these calls act the same as the spinlock-safe calls. | ||
- | |||
- | ** IN ADDITION ** calls to setup and configure such GPIOs must be made from contexts which may sleep, since they may need to access the GPIO controller chip too: (These setup calls are usually made from board setup or driver probe/ | ||
- | |||
- | ```c | ||
- | gpio_direction_input() | ||
- | gpio_direction_output() | ||
- | gpio_request() | ||
- | |||
- | gpio_request_one() | ||
- | gpio_request_array() | ||
- | gpio_free_array() | ||
- | |||
- | gpio_free() | ||
- | gpio_set_debounce() | ||
- | ``` | ||
- | |||
- | |||
- | ### Claiming and Releasing GPIOs | ||
- | |||
- | |||
- | To help catch system configuration errors, two calls are defined. | ||
- | |||
- | /* 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 serve two basic purposes. | ||
- | (a) two or more drivers wrongly think they have exclusive use of that signal, or (b) something wrongly believes it's safe to remove drivers needed to manage a signal that's in active use. That is, requesting a GPIO can serve as a kind of lock. | ||
- | |||
- | Some platforms may also use knowledge about what GPIOs are active for power management, such as by powering down unused chip sectors and, more easily, gating off unused clocks. | ||
- | |||
- | For GPIOs that use pins known to the pinctrl subsystem, that subsystem should be informed of their use; a gpiolib driver' | ||
- | to succeed concurrently with a pin or pingroup being " | ||
- | |||
- | Any programming of pin multiplexing hardware that is needed to route the GPIO signal to the appropriate pin should occur within a GPIO driver' | ||
- | .direction_input() or .direction_output() operations, and occur after any setup of an output GPIO's value. This allows a glitch-free migration from a pin's special function to GPIO. This is sometimes required when using a GPIO to implement a workaround on signals typically driven by a non-GPIO HW block. | ||
- | |||
- | Some platforms allow some or all GPIO signals to be routed to different pins. | ||
- | Similarly, other aspects of the GPIO or pin may need to be configured, such as pullup/ | ||
- | |||
- | Also note that it's your responsibility to have stopped using a GPIO before you free it. | ||
- | |||
- | Considering in most cases GPIOs are actually configured right after they are claimed, three additional calls are defined: | ||
- | |||
- | /* request a single GPIO, with initial configuration specified by | ||
- | * ' | ||
- | * return value | ||
- | */ | ||
- | int gpio_request_one(unsigned gpio, unsigned long flags, const char *label); | ||
- | |||
- | /* request multiple GPIOs in a single call | ||
- | */ | ||
- | int gpio_request_array(struct gpio *array, size_t num); | ||
- | |||
- | /* release multiple GPIOs in a single call | ||
- | */ | ||
- | void gpio_free_array(struct gpio *array, size_t num); | ||
- | |||
- | where ' | ||
- | |||
- | * GPIOF_DIR_IN - to configure direction as input | ||
- | * GPIOF_DIR_OUT - to configure direction as output | ||
- | |||
- | * GPIOF_INIT_LOW - as output, set initial level to LOW | ||
- | * GPIOF_INIT_HIGH - as output, set initial level to HIGH | ||
- | * GPIOF_OPEN_DRAIN - gpio pin is open drain type. | ||
- | * GPIOF_OPEN_SOURCE - gpio pin is open source type. | ||
- | |||
- | * GPIOF_EXPORT_DIR_FIXED - export gpio to sysfs, keep direction | ||
- | * GPIOF_EXPORT_DIR_CHANGEABLE - also export, allow changing direction | ||
- | |||
- | since GPIOF_INIT_* are only valid when configured as output, so group valid combinations as: | ||
- | |||
- | * GPIOF_IN - configure as input | ||
- | * GPIOF_OUT_INIT_LOW - configured as output, initial level LOW | ||
- | * GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH | ||
- | |||
- | When setting the flag as GPIOF_OPEN_DRAIN then it will assume that pins is open drain type. Such pins will not be driven to 1 in output mode. It is require to connect pull-up on such pins. By enabling this flag, gpio lib will make the direction to input when it is asked to set value of 1 in output mode to make the pin HIGH. The pin is make to LOW by driving value 0 in output mode. | ||
- | |||
- | When setting the flag as GPIOF_OPEN_SOURCE then it will assume that pins is open source type. Such pins will not be driven to 0 in output mode. It is require to connect pull-down on such pin. By enabling this flag, gpio lib will make the direction to input when it is asked to set value of 0 in output mode to make the pin LOW. The pin is make to HIGH by driving value 1 in output mode. | ||
- | |||
- | In the future, these flags can be extended to support more properties. | ||
- | |||
- | Further more, to ease the claim/ | ||
- | |||
- | struct gpio { | ||
- | unsigned gpio; | ||
- | unsigned long flags; | ||
- | const char *label; | ||
- | }; | ||
- | |||
- | A typical example of usage: | ||
- | |||
- | static struct gpio leds_gpios[] = { | ||
- | { 32, GPIOF_OUT_INIT_HIGH, | ||
- | { 33, GPIOF_OUT_INIT_LOW, | ||
- | { 34, GPIOF_OUT_INIT_LOW, | ||
- | { 35, GPIOF_OUT_INIT_LOW, | ||
- | { ... }, | ||
- | }; | ||
- | |||
- | err = gpio_request_one(31, | ||
- | if (err) | ||
- | ... | ||
- | |||
- | err = gpio_request_array(leds_gpios, | ||
- | if (err) | ||
- | ... | ||
- | |||
- | gpio_free_array(leds_gpios, | ||
- | |||
- | |||
- | ### GPIOs mapped to IRQs | ||
- | |||
- | GPIO numbers are unsigned integers; so are IRQ numbers. | ||
- | |||
- | /* map GPIO numbers to IRQ numbers */ | ||
- | int gpio_to_irq(unsigned gpio); | ||
- | |||
- | /* map IRQ numbers to GPIO numbers (avoid using this) */ | ||
- | 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 be used as IRQs.) | ||
- | |||
- | These two mapping calls are expected to cost on the order of a single addition or subtraction. | ||
- | |||
- | Non-error values returned from gpio_to_irq() can be passed to request_irq() | ||
- | or free_irq(). | ||
- | |||
- | Non-error values returned from irq_to_gpio() would most commonly be used with gpio_get_value(), | ||
- | |||
- | |||
- | ### Emulating Open Drain Signals | ||
- | |||
- | Sometimes shared signals need to use "open drain" signaling, where only the low signal level is actually driven. | ||
- | "open collector" | ||
- | |||
- | 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' | ||
- | there' | ||
- | |||
- | | ||
- | and overrides the pullup. | ||
- | |||
- | | ||
- | so the pullup (or some other device) controls the signal. | ||
- | |||
- | If you are " | ||
- | |||
- | |||
- | ### GPIO controllers and the pinctrl subsystem | ||
- | |||
- | A GPIO controller on a SOC might be tightly coupled with the pinctrl subsystem, in the sense that the pins can be used by other functions together with an optional gpio feature. We have already covered the case where e.g. a GPIO controller need to reserve a pin or set the direction of a pin by calling any of: | ||
- | |||
- | ```c | ||
- | pinctrl_gpio_request() | ||
- | pinctrl_gpio_free() | ||
- | pinctrl_gpio_direction_input() | ||
- | pinctrl_gpio_direction_output() | ||
- | ``` | ||
- | |||
- | But how does the pin control subsystem cross-correlate the GPIO numbers (which are a global business) to a certain pin on a certain pin controller? | ||
- | |||
- | This is done by registering " | ||
- | |||
- | While the pin allocation is totally managed by the pinctrl subsystem, | ||
- | gpio (under gpiolib) is still maintained by gpio drivers. It may happen that different pin ranges in a SoC is managed by different gpio drivers. | ||
- | |||
- | This makes it logical to let gpio drivers announce their pin ranges to the pin ctrl subsystem before it will call ' | ||
- | |||
- | For this, the gpio controller can register its pin range with pinctrl subsystem. There are two ways of doing it currently: with or without DT. | ||
- | |||
- | For with DT support refer to Documentation/ | ||
- | |||
- | For non-DT support, user can call gpiochip_add_pin_range() with appropriate parameters to register a range of gpio pins with a pinctrl driver. For this exact name string of pinctrl device has to be passed as one of the argument to this routine. | ||
- | |||
- | |||
- | ## What do these conventions omit? | ||
- | |||
- | One of the biggest things these conventions omit is pin multiplexing, | ||
- | |||
- | Related to multiplexing is configuration and enabling of the pullups or pulldowns integrated on some platforms. | ||
- | 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. | ||
- | (When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.) | ||
- | Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a platform-specific issue, as are models like (not) having a one-to-one correspondence between configurable pins and GPIOs. | ||
- | |||
- | 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: | ||
- | |||
- | Dynamic definition of GPIOs is not currently standard; for example, as a side effect of configuring an add-on board with some GPIO expanders. | ||
- | |||
- | |||
- | ## GPIO implementor' | ||
- | |||
- | As noted earlier, there is an optional implementation framework making it easier for platforms to support different kinds of GPIO controller using the same programming interface. | ||
- | |||
- | As a debugging aid, if debugfs is available a / | ||
- | |||
- | |||
- | ### Controller Drivers: gpio_chip | ||
- | In this framework each GPIO controller is packaged as a " | ||
- | |||
- | - methods to establish GPIO direction | ||
- | - methods used to access GPIO values | ||
- | - flag saying whether calls to its methods may sleep | ||
- | - optional debugfs dump method (showing extra state like pullup config) | ||
- | - label for diagnostics | ||
- | |||
- | There is also per-instance data, which may come from device.platform_data: | ||
- | the number of its first GPIO, and how many GPIOs it exposes. | ||
- | |||
- | The code implementing a gpio_chip should support multiple instances of the controller, possibly using the driver model. | ||
- | |||
- | Most often a gpio_chip is part of an instance-specific structure with state not exposed by the GPIO interfaces, such as addressing, power management, | ||
- | and more. Chips such as codecs will have complex non-GPIO state. | ||
- | |||
- | Any debugfs dump method should normally ignore signals which haven' | ||
- | |||
- | ### Platform Support | ||
- | |||
- | To force-enable this framework, a platform' | ||
- | else it is up to the user to configure support for GPIO. | ||
- | |||
- | It may also provide a custom value for ARCH_NR_GPIOS, | ||
- | |||
- | If neither of these options are selected, the platform does not support GPIOs through GPIO-lib and the code cannot be enabled by the user. | ||
- | |||
- | Trivial implementations of those functions can directly use framework code, which always dispatches through the gpio_chip: | ||
- | ``` | ||
- | #define gpio_get_value __gpio_get_value | ||
- | #define gpio_set_value __gpio_set_value | ||
- | #define gpio_cansleep __gpio_cansleep | ||
- | ``` | ||
- | Fancier implementations could instead define those as inline functions with logic optimizing access to specific SOC-based GPIOs. | ||
- | |||
- | For SOCs, platform-specific code defines and registers gpio_chip instances for each bank of on-chip GPIOs. | ||
- | |||
- | |||
- | Board Support | ||
- | ------------- | ||
- | For external GPIO controllers -- such as I2C or SPI expanders, ASICs, multi function devices, FPGAs or CPLDs -- most often board-specific code handles registering controller devices and ensures that their drivers know what GPIO numbers to use with gpiochip_add(). | ||
- | |||
- | For example, board setup code could create structures identifying the range of GPIOs that chip will expose, and passes them to each GPIO expander chip using platform_data. | ||
- | |||
- | Initialization order can be important. | ||
- | |||
- | Sysfs Interface for Userspace (OPTIONAL) | ||
- | |||
- | Platforms which use the " | ||
- | |||
- | Given appropriate hardware documentation for the system, userspace could know for example that GPIO #23 controls the write protect line used to protect boot loader segments in flash memory. | ||
- | then changing its output state, then updating the code before re-enabling the write protection. | ||
- | and the kernel would have no need to know about it. | ||
- | |||
- | Again depending on appropriate hardware documentation, | ||
- | |||
- | Note that standard kernel drivers exist for common "LEDs and Buttons" | ||
- | GPIO tasks: | ||
- | |||
- | |||
- | ### Paths in Sysfs | ||
- | |||
- | There are three kinds of entry in / | ||
- | |||
- | - Control interfaces used to get userspace control over GPIOs; | ||
- | - GPIOs themselves; and | ||
- | |||
- | - GPIO controllers (" | ||
- | |||
- | That's in addition to standard files including the " | ||
- | |||
- | The control interfaces are write-only: | ||
- | |||
- | / | ||
- | | ||
- | " | ||
- | a GPIO to userspace by writing its number to this file. | ||
- | | ||
- | Example: | ||
- | for GPIO #19, if that's not requested by kernel code. | ||
- | | ||
- | " | ||
- | | ||
- | Example: | ||
- | node exported using the " | ||
- | |||
- | GPIO signals have paths like / | ||
- | and have the following read/write attributes: | ||
- | |||
- | / | ||
- | | ||
- | " | ||
- | normally be written. | ||
- | initializing the value as low. To ensure glitch free | ||
- | operation, values " | ||
- | configure the GPIO as an output with that initial value. | ||
- | | ||
- | Note that this attribute *will not exist* if the kernel | ||
- | doesn' | ||
- | it was exported by kernel code that didn't explicitly | ||
- | allow userspace to reconfigure this GPIO's direction. | ||
- | | ||
- | " | ||
- | is configured as an output, this value may be written; | ||
- | any nonzero value is treated as high. | ||
- | | ||
- | If the pin can be configured as interrupt-generating interrupt | ||
- | and if it has been configured to generate interrupts (see the | ||
- | description of " | ||
- | poll(2) will return whenever the interrupt was triggered. If | ||
- | you use poll(2), set the events POLLPRI and POLLERR. If you | ||
- | use select(2), set the file descriptor in exceptfds. After | ||
- | poll(2) returns, either lseek(2) to the beginning of the sysfs | ||
- | file and read the new value or close the file and re-open it | ||
- | to read the value. | ||
- | | ||
- | " | ||
- | " | ||
- | that will make poll(2) on the " | ||
- | | ||
- | This file exists only if the pin can be configured as an | ||
- | interrupt generating input pin. | ||
- | | ||
- | " | ||
- | any nonzero value to invert the value attribute both | ||
- | for reading and writing. | ||
- | poll(2) support configuration via the edge attribute | ||
- | for " | ||
- | setting. | ||
- | |||
- | GPIO controllers have paths like / | ||
- | |||
- | / | ||
- | | ||
- | " | ||
- | | ||
- | " | ||
- | | ||
- | " | ||
- | |||
- | Board documentation should in most cases cover what GPIOs are used for what purposes. | ||
- | or other cards in the stack. | ||
- | |||
- | |||
- | ### Exporting from Kernel code | ||
- | |||
- | Kernel code can explicitly manage exports of GPIOs which have already been requested using gpio_request(): | ||
- | |||
- | /* export the GPIO to userspace */ | ||
- | int gpio_export(unsigned gpio, bool direction_may_change); | ||
- | |||
- | /* reverse gpio_export() */ | ||
- | void gpio_unexport(); | ||
- | |||
- | /* create a sysfs link to an exported GPIO node */ | ||
- | int gpio_export_link(struct device *dev, const char *name, | ||
- | unsigned gpio) | ||
- | |||
- | After a kernel driver requests a GPIO, it may only be made available in the sysfs interface by gpio_export(). | ||
- | |||
- | This explicit exporting can help with debugging (by making some kinds of experiments easier), or can provide an always-there interface that's suitable for documenting as part of a board support package. | ||
- | |||
- | After the GPIO has been exported, gpio_export_link() allows creating symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can use this to provide the interface under their own device in sysfs with a descriptive name. | ||
- | |||
- | </ |