Lines Matching +full:in +full:- +full:gpios
5 This document explains how GPIOs can be assigned to given devices and functions.
7 Note that it only applies to the new descriptor-based interface. For a
8 description of the deprecated integer-based GPIO interface please refer to
15 Kconfig. Then, how GPIOs are mapped depends on what the platform uses to
20 -----------
21 GPIOs can easily be mapped to devices and functions in the device tree. The
22 exact way to do it depends on the GPIO controller providing the GPIOs, see the
25 GPIOs mappings are defined in the consumer device's node, in a property named
26 <function>-gpios, where <function> is the function the driver will request
32 led-gpios = <&gpio 15 GPIO_ACTIVE_HIGH>, /* red */
36 power-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
39 Properties named <function>-gpio are also considered valid and old bindings use
43 This property will make GPIOs 15, 16 and 17 available to the driver under the
54 The led GPIOs will be active high, while the power GPIO will be active low (i.e.
58 the <function>-prefix of the GPIO suffixes ("gpios" or "gpio", automatically
59 looked up by the gpiod functions internally) used in the device tree. With above
60 "led-gpios" example, use the prefix without the "-" as con_id parameter: "led".
62 Internally, the GPIO subsystem prefixes the GPIO suffix ("gpios" or "gpio")
63 with the string passed in con_id to get the resulting string
64 (``snprintf(... "%s-%s", con_id, gpio_suffixes[]``).
67 ----
68 ACPI also supports function names for GPIOs in a similar fashion to DT.
70 with the help of _DSD (Device Specific Data), introduced in ACPI 5.1::
85 ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
88 "led-gpios",
95 Package () { "power-gpios", Package () { ^FOO, 3, 0, 0 } },
101 Documentation/firmware-guide/acpi/gpio-properties.rst.
104 -------------
105 Finally, GPIOs can be bound to devices and functions using platform data. Board
110 GPIOs are mapped by the means of tables of lookups, containing instances of the
118 - key is either the label of the gpiod_chip instance providing the GPIO, or
120 - chip_hwnum is the hardware number of the GPIO within the chip, or U16_MAX
122 - con_id is the name of the GPIO function from the device point of view. It
123 can be NULL, in which case it will match any function.
124 - idx is the index of the GPIO within the function.
125 - flags is defined to specify the following properties:
126 * GPIO_ACTIVE_HIGH - GPIO line is active high
127 * GPIO_ACTIVE_LOW - GPIO line is active low
128 * GPIO_OPEN_DRAIN - GPIO line is set up as open drain
129 * GPIO_OPEN_SOURCE - GPIO line is set up as open source
130 * GPIO_PERSISTENT - GPIO line is persistent during
132 * GPIO_TRANSITORY - GPIO line is transitory and may loose its
135 In the future, these flags might be extended to support more properties.
144 make use of these GPIOs. It can be NULL, in which case it will be matched for
147 .. code-block:: c
164 The driver controlling "foo.0" will then be able to obtain its GPIOs as follows::
174 Since the "led" GPIOs are mapped as active-high, this example will switch their
176 as active-low, its actual signal will be 0 after this code. Contrary to the
177 legacy integer GPIO interface, the active-low property is handled during
181 the new descriptor-oriented interface.
185 .. code-block:: c
196 The line will be hogged as soon as the gpiochip is created or - in case the
197 chip was created earlier - when the hog table is registered.
200 --------------
201 In addition to requesting pins belonging to a function one by one, a device may
207 In order to qualify for fast bitmap processing, the array must meet the
210 - pin hardware number of array member 0 must also be 0,
211 - pin hardware numbers of consecutive array members which belong to the same
214 Otherwise fast bitmap processing path is not used in order to avoid consecutive
215 pins which belong to the same chip but are not in hardware order being processed