Lines Matching refs:GPIO
1 GPIO Interfaces
3 This provides an overview of GPIO access conventions on Linux.
9 What is a GPIO?
11 A "General Purpose Input/Output" (GPIO) is a flexible software-controlled
13 to Linux developers working with embedded and custom hardware. Each GPIO
20 non-dedicated pin can be configured as a GPIO; and most chips have at least
24 also "GPIO Expander" chips that connect using the I2C or SPI serial busses.
25 Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS
37 cases (to support bidirectional signaling). GPIO controllers may have
44 - Usually a GPIO will be configurable as either input or output, as needed
50 On a given board each GPIO is used for one specific purpose like monitoring
56 GPIO conventions
69 used for several very different kinds of GPIO controller. (There is some
71 in this document, but drivers acting as clients to the GPIO interface must
77 standard GPIO calls should have Kconfig entries which depend on GPIOLIB. The
78 GPIO calls are available, either as "real code" or as optimized-away stubs,
98 for the GPIO lines so that board-specific setup code directly corresponds
99 to the relevant schematics. In contrast, drivers should only use GPIO
105 uses numbers 0..63 with one set of GPIO controllers, 64-79 with another
106 type of GPIO controller, and on one particular board 80-95 with an FPGA.
108 use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
110 If you want to initialize a structure with an invalid GPIO number, use
112 test if such number from such a structure could reference a GPIO, you
121 Whether a platform supports multiple GPIO controllers is a platform-specific
123 of GPIO numbers, and whether new controllers can be added at runtime. Such issues
124 can affect things including whether adjacent GPIO numbers are both valid.
128 The first thing a system should do with a GPIO is allocate it, using
131 One of the next things to do with a GPIO, often in board setup code when
132 setting up a platform_device using the GPIO, is mark its direction:
148 of a GPIO implicitly requests that GPIO (see below) if it has not been
152 Setting the direction can fail if the GPIO number is invalid, or when
153 that particular GPIO can't be used in that mode. It's generally a bad
156 that board setup code probably needs to multiplex that pin as a GPIO,
160 Spinlock-Safe GPIO access
162 Most GPIO controllers can be accessed with memory read/write instructions.
169 /* GPIO INPUT: return zero or nonzero */
172 /* GPIO OUTPUT */
180 The get/set calls have no error returns because "invalid GPIO" should have
187 calls to access the GPIO value in cases where the GPIO number (and for
195 GPIO access that may sleep
197 Some GPIO controllers must be accessed using message based busses like I2C
198 or SPI. Commands to read or write those GPIO values require waiting to
202 Platforms that support this type of GPIO distinguish them from other GPIOs
203 by returning nonzero from this call (which requires a valid GPIO number,
210 /* GPIO INPUT: return zero or nonzero, might sleep */
213 /* GPIO OUTPUT, might sleep */
226 from contexts which may sleep, since they may need to access the GPIO
247 /* request GPIO, returning 0 or negative errno.
252 /* release previously-claimed GPIO */
255 Passing invalid GPIO numbers to gpio_request() will fail, as will requesting
268 GPIO can serve as a kind of lock.
282 GPIO signal to the appropriate pin should occur within a GPIO driver's
284 setup of an output GPIO's value. This allows a glitch-free migration from a
285 pin's special function to GPIO. This is sometimes required when using a GPIO
286 to implement a workaround on signals typically driven by a non-GPIO HW block.
288 Some platforms allow some or all GPIO signals to be routed to different pins.
289 Similarly, other aspects of the GPIO or pin may need to be configured, such as
292 the pinctrl subsystem's mapping table, so that GPIO users need not be aware
295 Also note that it's your responsibility to have stopped using a GPIO
301 /* request a single GPIO, with initial configuration specified by
381 GPIO numbers are unsigned integers; so are IRQ numbers. These make up
382 two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can
385 /* map GPIO numbers to IRQ numbers */
388 /* map IRQ numbers to GPIO numbers (avoid using this) */
393 some GPIOs can't be used as IRQs.) It is an unchecked error to use a GPIO
423 Some GPIO controllers directly support open drain outputs; many don't. When
425 there's a common idiom you can use to emulate it with any GPIO pin that can
442 GPIO controllers and the pinctrl subsystem
445 A GPIO controller on a SOC might be tightly coupled with the pinctrl
448 case where e.g. a GPIO controller need to reserve a pin or set the
456 But how does the pin control subsystem cross-correlate the GPIO
490 to route a given GPIO to any one of several pins. (Yes, those examples all
512 a side effect of configuring an add-on board with some GPIO expanders.
515 GPIO implementor's framework (OPTIONAL)
518 easier for platforms to support different kinds of GPIO controller using
528 In this framework each GPIO controller is packaged as a "struct gpio_chip"
531 - methods to establish GPIO direction
532 - methods used to access GPIO values
538 the number of its first GPIO, and how many GPIOs it exposes.
542 gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be
546 not exposed by the GPIO interfaces, such as addressing, power management,
547 and more. Chips such as codecs will have complex non-GPIO state.
551 either NULL or the label associated with that GPIO when it was requested.
564 also ones on GPIO expanders.
573 GPIOs through GPIO-lib and the code cannot be enabled by the user.
584 referenced GPIO is the constant "12", getting or setting its value could
600 For external GPIO controllers -- such as I2C or SPI expanders, ASICs, multi
602 registering controller devices and ensures that their drivers know what GPIO
607 of GPIOs that chip will expose, and passes them to each GPIO expander chip
612 an I2C-based GPIO, its probe() routine should only be called after that GPIO
614 calls for that GPIO can work. One way to address such dependencies is for
618 the GPIO controller device becomes unavailable.
625 debugfs interface, since it provides control over GPIO direction and
630 know for example that GPIO #23 controls the write protect line used to
632 may need to temporarily remove that protection, first importing a GPIO,
634 the write protection. In normal use, GPIO #23 would never be touched,
638 userspace GPIO can be used to determine system configuration data that
640 GPIO drivers could be all that the system really needs.
643 GPIO tasks: "leds-gpio" and "gpio_keys", respectively. Use those
656 - GPIO controllers ("gpio_chip" instances).
665 a GPIO to userspace by writing its number to this file.
668 for GPIO #19, if that's not requested by kernel code.
675 GPIO signals have paths like /sys/class/gpio/gpio42/ (for GPIO #42)
684 configure the GPIO as an output with that initial value.
687 doesn't support changing the direction of a GPIO, or
689 allow userspace to reconfigure this GPIO's direction.
691 "value" ... reads as either 0 (low) or 1 (high). If the GPIO
719 GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
725 "base" ... same as N, the first GPIO managed by this chip
736 the correct GPIO number to use for a given signal.
744 /* export the GPIO to userspace */
750 /* create a sysfs link to an exported GPIO node */
754 After a kernel driver requests a GPIO, it may only be made available in
763 After the GPIO has been exported, gpio_export_link() allows creating
764 symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can