^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) GPIO Mappings
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) This document explains how GPIOs can be assigned to given devices and functions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) Note that it only applies to the new descriptor-based interface. For a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) description of the deprecated integer-based GPIO interface please refer to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) gpio-legacy.txt (actually, there is no real mapping possible with the old
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) interface; you just fetch an integer from somewhere and request the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) corresponding GPIO).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) All platforms can enable the GPIO library, but if the platform strictly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) requires GPIO functionality to be present, it needs to select GPIOLIB from its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) Kconfig. Then, how GPIOs are mapped depends on what the platform uses to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) describe its hardware layout. Currently, mappings can be defined through device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) tree, ACPI, and platform data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) Device Tree
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) -----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) GPIOs can easily be mapped to devices and functions in the device tree. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) exact way to do it depends on the GPIO controller providing the GPIOs, see the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) device tree bindings for your controller.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) GPIOs mappings are defined in the consumer device's node, in a property named
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) <function>-gpios, where <function> is the function the driver will request
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) through gpiod_get(). For example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) foo_device {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) compatible = "acme,foo";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) led-gpios = <&gpio 15 GPIO_ACTIVE_HIGH>, /* red */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) <&gpio 16 GPIO_ACTIVE_HIGH>, /* green */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) <&gpio 17 GPIO_ACTIVE_HIGH>; /* blue */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) power-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) Properties named <function>-gpio are also considered valid and old bindings use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) it but are only supported for compatibility reasons and should not be used for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) newer bindings since it has been deprecated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) This property will make GPIOs 15, 16 and 17 available to the driver under the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) "led" function, and GPIO 1 as the "power" GPIO::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) struct gpio_desc *red, *green, *blue, *power;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) red = gpiod_get_index(dev, "led", 0, GPIOD_OUT_HIGH);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) green = gpiod_get_index(dev, "led", 1, GPIOD_OUT_HIGH);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) blue = gpiod_get_index(dev, "led", 2, GPIOD_OUT_HIGH);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) power = gpiod_get(dev, "power", GPIOD_OUT_HIGH);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) The led GPIOs will be active high, while the power GPIO will be active low (i.e.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) gpiod_is_active_low(power) will be true).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) The second parameter of the gpiod_get() functions, the con_id string, has to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) the <function>-prefix of the GPIO suffixes ("gpios" or "gpio", automatically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) looked up by the gpiod functions internally) used in the device tree. With above
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) "led-gpios" example, use the prefix without the "-" as con_id parameter: "led".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) Internally, the GPIO subsystem prefixes the GPIO suffix ("gpios" or "gpio")
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) with the string passed in con_id to get the resulting string
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) (``snprintf(... "%s-%s", con_id, gpio_suffixes[]``).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) ACPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) ----
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) ACPI also supports function names for GPIOs in a similar fashion to DT.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) The above DT example can be converted to an equivalent ACPI description
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) with the help of _DSD (Device Specific Data), introduced in ACPI 5.1::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) Device (FOO) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) Name (_CRS, ResourceTemplate () {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) GpioIo (Exclusive, ..., IoRestrictionOutputOnly,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) "\\_SB.GPI0") {15} // red
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) GpioIo (Exclusive, ..., IoRestrictionOutputOnly,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) "\\_SB.GPI0") {16} // green
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) GpioIo (Exclusive, ..., IoRestrictionOutputOnly,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) "\\_SB.GPI0") {17} // blue
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) GpioIo (Exclusive, ..., IoRestrictionOutputOnly,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) "\\_SB.GPI0") {1} // power
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) })
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) Name (_DSD, Package () {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) Package () {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) Package () {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) "led-gpios",
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) Package () {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) ^FOO, 0, 0, 1,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) ^FOO, 1, 0, 1,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) ^FOO, 2, 0, 1,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) Package () {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) "power-gpios",
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) Package () {^FOO, 3, 0, 0},
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) })
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) For more information about the ACPI GPIO bindings see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) Documentation/firmware-guide/acpi/gpio-properties.rst.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) Platform Data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) Finally, GPIOs can be bound to devices and functions using platform data. Board
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) files that desire to do so need to include the following header::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) #include <linux/gpio/machine.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) GPIOs are mapped by the means of tables of lookups, containing instances of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) gpiod_lookup structure. Two macros are defined to help declaring such mappings::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) GPIO_LOOKUP(key, chip_hwnum, con_id, flags)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) GPIO_LOOKUP_IDX(key, chip_hwnum, con_id, idx, flags)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) - key is either the label of the gpiod_chip instance providing the GPIO, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) the GPIO line name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) - chip_hwnum is the hardware number of the GPIO within the chip, or U16_MAX
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) to indicate that key is a GPIO line name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) - con_id is the name of the GPIO function from the device point of view. It
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) can be NULL, in which case it will match any function.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) - idx is the index of the GPIO within the function.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) - flags is defined to specify the following properties:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) * GPIO_ACTIVE_HIGH - GPIO line is active high
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) * GPIO_ACTIVE_LOW - GPIO line is active low
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) * GPIO_OPEN_DRAIN - GPIO line is set up as open drain
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) * GPIO_OPEN_SOURCE - GPIO line is set up as open source
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) * GPIO_PERSISTENT - GPIO line is persistent during
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) suspend/resume and maintains its value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) * GPIO_TRANSITORY - GPIO line is transitory and may loose its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) electrical state during suspend/resume
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) In the future, these flags might be extended to support more properties.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) Note that:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) 1. GPIO line names are not guaranteed to be globally unique, so the first
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) match found will be used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) 2. GPIO_LOOKUP() is just a shortcut to GPIO_LOOKUP_IDX() where idx = 0.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) A lookup table can then be defined as follows, with an empty entry defining its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) end. The 'dev_id' field of the table is the identifier of the device that will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) make use of these GPIOs. It can be NULL, in which case it will be matched for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) calls to gpiod_get() with a NULL device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) struct gpiod_lookup_table gpios_table = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) .dev_id = "foo.0",
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) .table = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) GPIO_LOOKUP_IDX("gpio.0", 15, "led", 0, GPIO_ACTIVE_HIGH),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) GPIO_LOOKUP_IDX("gpio.0", 16, "led", 1, GPIO_ACTIVE_HIGH),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) GPIO_LOOKUP_IDX("gpio.0", 17, "led", 2, GPIO_ACTIVE_HIGH),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) GPIO_LOOKUP("gpio.0", 1, "power", GPIO_ACTIVE_LOW),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) { },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) },
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) And the table can be added by the board code as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) gpiod_add_lookup_table(&gpios_table);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) The driver controlling "foo.0" will then be able to obtain its GPIOs as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) struct gpio_desc *red, *green, *blue, *power;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) red = gpiod_get_index(dev, "led", 0, GPIOD_OUT_HIGH);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) green = gpiod_get_index(dev, "led", 1, GPIOD_OUT_HIGH);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) blue = gpiod_get_index(dev, "led", 2, GPIOD_OUT_HIGH);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) power = gpiod_get(dev, "power", GPIOD_OUT_HIGH);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) Since the "led" GPIOs are mapped as active-high, this example will switch their
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) signals to 1, i.e. enabling the LEDs. And for the "power" GPIO, which is mapped
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) as active-low, its actual signal will be 0 after this code. Contrary to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) legacy integer GPIO interface, the active-low property is handled during
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) mapping and is thus transparent to GPIO consumers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) A set of functions such as gpiod_set_value() is available to work with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) the new descriptor-oriented interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) Boards using platform data can also hog GPIO lines by defining GPIO hog tables.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) .. code-block:: c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) struct gpiod_hog gpio_hog_table[] = {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) GPIO_HOG("gpio.0", 10, "foo", GPIO_ACTIVE_LOW, GPIOD_OUT_HIGH),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) { }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) And the table can be added to the board code as follows::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) gpiod_add_hogs(gpio_hog_table);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) The line will be hogged as soon as the gpiochip is created or - in case the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) chip was created earlier - when the hog table is registered.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) Arrays of pins
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) --------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) In addition to requesting pins belonging to a function one by one, a device may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) also request an array of pins assigned to the function. The way those pins are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) mapped to the device determines if the array qualifies for fast bitmap
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) processing. If yes, a bitmap is passed over get/set array functions directly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) between a caller and a respective .get/set_multiple() callback of a GPIO chip.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) In order to qualify for fast bitmap processing, the array must meet the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) following requirements:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) - pin hardware number of array member 0 must also be 0,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) - pin hardware numbers of consecutive array members which belong to the same
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) chip as member 0 does must also match their array indexes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) Otherwise fast bitmap processing path is not used in order to avoid consecutive
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) pins which belong to the same chip but are not in hardware order being processed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) separately.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) If the array applies for fast bitmap processing path, pins which belong to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) different chips than member 0 does, as well as those with indexes different from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) their hardware pin numbers, are excluded from the fast path, both input and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) output. Moreover, open drain and open source pins are excluded from fast bitmap
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) output processing.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags