Lines Matching +full:re +full:- +full:configured
13 A "General Purpose Input/Output" (GPIO) is a flexible software-controlled
21 System-on-Chip (SOC) processors heavily rely on GPIOs. In some cases, every
22 non-dedicated pin can be configured as a GPIO; and most chips have at least
27 Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS
28 firmware knowing how they're used).
32 - Output values are writable (high=1, low=0). Some chips also have
34 value might be driven ... supporting "wire-OR" and similar schemes
37 - Input values are likewise readable (1, 0). Some chips support readback
38 of pins configured as "output", which is very useful in such "wire-OR"
40 input de-glitch/debounce logic, sometimes with software controls.
42 - Inputs can often be used as IRQ signals, often edge triggered but
46 - Usually a GPIO will be configurable as either input or output, as needed
49 - Most GPIOs can be accessed while holding spinlocks, but those accessed
62 is not the main issue; GPIOs are often used for the kind of board-specific
64 used on a board that's wired differently. Only least-common-denominator
65 functionality can be very portable. Other features are platform-specific,
80 GPIO calls are available, either as "real code" or as optimized-away stubs,
93 -----------------
100 for the GPIO lines so that board-specific setup code directly corresponds
103 board-specific pin configuration data (along with other board specific
106 So for example one platform uses numbers 32-159 for GPIOs; while another
107 uses numbers 0..63 with one set of GPIO controllers, 64-79 with another
108 type of GPIO controller, and on one particular board 80-95 with an FPGA.
110 use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
113 some negative number (perhaps "-EINVAL"); that will never be valid. To
123 Whether a platform supports multiple GPIO controllers is a platform-specific
129 -----------
143 a task context. However, for spinlock-safe GPIOs it's OK to use them
162 Spinlock-Safe GPIO access
163 -------------------------
180 issues including open-drain signaling and output latencies.
188 Platform-specific implementations are encouraged to optimize the two
198 --------------------------
221 spinlock-safe accessors without the cansleep() name suffix.
225 the same as the spinlock-safe calls.
246 ----------------------------
250 * non-null labels may be useful for diagnostics.
254 /* release previously-claimed GPIO */
260 a task context. However, for spinlock-safe GPIOs it's OK to request GPIOs
286 setup of an output GPIO's value. This allows a glitch-free migration from a
288 to implement a workaround on signals typically driven by a non-GPIO HW block.
291 Similarly, other aspects of the GPIO or pin may need to be configured, such as
293 configured prior to gpio_request() being called for those GPIOs, e.g. using
300 Considering in most cases GPIOs are actually configured right after they
319 * GPIOF_DIR_IN - to configure direction as input
320 * GPIOF_DIR_OUT - to configure direction as output
322 * GPIOF_INIT_LOW - as output, set initial level to LOW
323 * GPIOF_INIT_HIGH - as output, set initial level to HIGH
324 * GPIOF_OPEN_DRAIN - gpio pin is open drain type.
325 * GPIOF_OPEN_SOURCE - gpio pin is open source type.
327 * GPIOF_EXPORT_DIR_FIXED - export gpio to sysfs, keep direction
328 * GPIOF_EXPORT_DIR_CHANGEABLE - also export, allow changing direction
330 since GPIOF_INIT_* are only valid when configured as output, so group valid
333 * GPIOF_IN - configure as input
334 * GPIOF_OUT_INIT_LOW - configured as output, initial level LOW
335 * GPIOF_OUT_INIT_HIGH - configured as output, initial level HIGH
339 require to connect pull-up on such pins. By enabling this flag, gpio lib will
345 require to connect pull-down on such pin. By enabling this flag, gpio lib will
382 --------------------
400 addition or subtraction. They're not allowed to sleep.
402 Non-error values returned from gpio_to_irq() can be passed to request_irq()
404 devices, by the board-specific initialization code. Note that IRQ trigger
408 Non-error values returned from irq_to_gpio() would most commonly be used
410 when the IRQ is edge-triggered. Note that some platforms don't support
415 ----------------------------
419 level. This is sometimes called a "wire-AND"; or more practically, from the
420 negative logic (low=true) perspective this is a "wire-OR".
422 One common example of an open drain signal is a shared active-low IRQ line.
445 ------------------------------------------
458 But how does the pin control subsystem cross-correlate the GPIO
463 cross-reference tables. These are described in
464 Documentation/driver-api/pin-control.rst
480 For non-DT support, user can call gpiochip_add_pin_range() with appropriate
489 this is highly chip-specific and nonportable. One platform might not need
498 pullups (or pulldowns) so that the on-chip ones should not be used.
499 (When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.)
501 platform-specific issue, as are models like (not) having a one-to-one
504 There are other system-specific mechanisms that are not specified here,
505 like the aforementioned options for input de-glitching and wire-OR output.
514 a side effect of configuring an add-on board with some GPIO expanders.
529 -----------------------------
533 - methods to establish GPIO direction
534 - methods used to access GPIO values
535 - flag saying whether calls to its methods may sleep
536 - optional debugfs dump method (showing extra state like pullup config)
537 - label for diagnostics
539 There is also per-instance data, which may come from device.platform_data:
547 Most often a gpio_chip is part of an instance-specific structure with state
549 and more. Chips such as codecs will have complex non-GPIO state.
557 ----------------
558 To force-enable this framework, a platform's Kconfig will "select" GPIOLIB,
563 wasting static table space. (It should count both built-in/SoC GPIOs and
567 GPIOs through GPIO-lib and the code cannot be enabled by the user.
577 logic optimizing access to specific SOC-based GPIOs. For example, if the
584 For SOCs, platform-specific code defines and registers gpio_chip instances
585 for each bank of on-chip GPIOs. Those GPIOs should be numbered/labeled to
587 may well start at zero and go up to a platform-specific limit. Such GPIOs
593 -------------
594 For external GPIO controllers -- such as I2C or SPI expanders, ASICs, multi
595 function devices, FPGAs or CPLDs -- most often board-specific code handles
598 platform-specific GPIOs.
606 an I2C-based GPIO, its probe() routine should only be called after that GPIO
627 then changing its output state, then updating the code before re-enabling
637 GPIO tasks: "leds-gpio" and "gpio_keys", respectively. Use those
643 --------------
646 - Control interfaces used to get userspace control over GPIOs;
648 - GPIOs themselves; and
650 - GPIO controllers ("gpio_chip" instances).
654 The control interfaces are write-only:
686 is configured as an output, this value may be written;
689 If the pin can be configured as interrupt-generating interrupt
690 and if it has been configured to generate interrupts (see the
696 new value or close the file and re-open it to read the value.
702 This file exists only if the pin can be configured as an
714 read-only attributes:
722 "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1)
733 --------------------------
753 of experiments easier), or can provide an always-there interface that's
768 .. kernel-doc:: drivers/gpio/gpiolib-legacy.c