Documentation/driver-api/gpio/board.rst GitHub 원문 ↗

Linux 6.18.37 · Driver API

GPIO Mappings

Device Tree·ACPI·software node·platform data에서 GPIO consumer mapping을 정의하는 방법입니다.

Source pathDocumentation/driver-api/gpio/board.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약과 해설

board.rst:1-281

GPIO mapping은 firmware description이나 board lookup table을 descriptor-oriented consumer API에 연결합니다. Polarity는 mapping layer에서 처리되며 pin array는 hardware 순서 조건을 만족할 때 bitmap fast path를 사용합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 =============
2 GPIO Mappings
3 =============
4
5 This document explains how GPIOs can be assigned to given devices and functions.
6
7 All platforms can enable the GPIO library, but if the platform strictly
8 requires GPIO functionality to be present, it needs to select GPIOLIB from its
9 Kconfig. Then, how GPIOs are mapped depends on what the platform uses to
10 describe its hardware layout. Currently, mappings can be defined through device
11 tree, ACPI, and platform data.
12
13 Device Tree
14 -----------
15 GPIOs can easily be mapped to devices and functions in the device tree. The
16 exact way to do it depends on the GPIO controller providing the GPIOs, see the
17 device tree bindings for your controller.
18
19 GPIOs mappings are defined in the consumer device's node, in a property named
20 <function>-gpios, where <function> is the function the driver will request
21 through gpiod_get(). For example::
22
23 foo_device {
24 compatible = "acme,foo";
25 ...
26 led-gpios = <&gpio 15 GPIO_ACTIVE_HIGH>, /* red */
27 <&gpio 16 GPIO_ACTIVE_HIGH>, /* green */
28 <&gpio 17 GPIO_ACTIVE_HIGH>; /* blue */
29
30 power-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
31 };
32
33 Properties named <function>-gpio are also considered valid and old bindings use
34 it but are only supported for compatibility reasons and should not be used for
35 newer bindings since it has been deprecated.
36
37 This property will make GPIOs 15, 16 and 17 available to the driver under the
38 "led" function, and GPIO 1 as the "power" GPIO::
39
40 struct gpio_desc *red, *green, *blue, *power;
41
42 red = gpiod_get_index(dev, "led", 0, GPIOD_OUT_HIGH);
43 green = gpiod_get_index(dev, "led", 1, GPIOD_OUT_HIGH);
44 blue = gpiod_get_index(dev, "led", 2, GPIOD_OUT_HIGH);
45
46 power = gpiod_get(dev, "power", GPIOD_OUT_HIGH);
47
48 The led GPIOs will be active high, while the power GPIO will be active low (i.e.
49 gpiod_is_active_low(power) will be true).
50
51 The second parameter of the gpiod_get() functions, the con_id string, has to be
52 the <function>-prefix of the GPIO suffixes ("gpios" or "gpio", automatically
53 looked up by the gpiod functions internally) used in the device tree. With above
54 "led-gpios" example, use the prefix without the "-" as con_id parameter: "led".
55
56 Internally, the GPIO subsystem prefixes the GPIO suffix ("gpios" or "gpio")
57 with the string passed in con_id to get the resulting string
58 (``snprintf(... "%s-%s", con_id, gpio_suffixes[]``).
59
60 ACPI
61 ----
62 ACPI also supports function names for GPIOs in a similar fashion to DT.
63 The above DT example can be converted to an equivalent ACPI description
64 with the help of _DSD (Device Specific Data), introduced in ACPI 5.1::
65
66 Device (FOO) {
67 Name (_CRS, ResourceTemplate () {
68 GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
69 "\\_SB.GPI0", 0, ResourceConsumer) { 15 } // red
70 GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
71 "\\_SB.GPI0", 0, ResourceConsumer) { 16 } // green
72 GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
73 "\\_SB.GPI0", 0, ResourceConsumer) { 17 } // blue
74 GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionOutputOnly,
75 "\\_SB.GPI0", 0, ResourceConsumer) { 1 } // power
76 })
77
78 Name (_DSD, Package () {
79 ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
80 Package () {
81 Package () {
82 "led-gpios",
83 Package () {
84 ^FOO, 0, 0, 1,
85 ^FOO, 1, 0, 1,
86 ^FOO, 2, 0, 1,
87 }
88 },
89 Package () { "power-gpios", Package () { ^FOO, 3, 0, 0 } },
90 }
91 })
92 }
93
94 For more information about the ACPI GPIO bindings see
95 Documentation/firmware-guide/acpi/gpio-properties.rst.
96
97 Software Nodes
98 --------------
99
100 Software nodes allow board-specific code to construct an in-memory,
101 device-tree-like structure using struct software_node and struct
102 property_entry. This structure can then be associated with a platform device,
103 allowing drivers to use the standard device properties API to query
104 configuration, just as they would on an ACPI or device tree system.
105
106 Software-node-backed GPIOs are described using the ``PROPERTY_ENTRY_GPIO()``
107 macro, which ties a software node representing the GPIO controller with
108 consumer device. It allows consumers to use regular gpiolib APIs, such as
109 gpiod_get(), gpiod_get_optional().
110
111 The software node representing a GPIO controller need not be attached to the
112 GPIO controller device. The only requirement is that the node must be
113 registered and its name must match the GPIO controller's label.
114
115 For example, here is how to describe a single GPIO-connected LED. This is an
116 alternative to using platform_data on legacy systems.
117
118 .. code-block:: c
119
120 #include <linux/property.h>
121 #include <linux/gpio/machine.h>
122 #include <linux/gpio/property.h>
123
124 /*
125 * 1. Define a node for the GPIO controller. Its .name must match the
126 * controller's label.
127 */
128 static const struct software_node gpio_controller_node = {
129 .name = "gpio-foo",
130 };
131
132 /* 2. Define the properties for the LED device. */
133 static const struct property_entry led_device_props[] = {
134 PROPERTY_ENTRY_STRING("label", "myboard:green:status"),
135 PROPERTY_ENTRY_STRING("linux,default-trigger", "heartbeat"),
136 PROPERTY_ENTRY_GPIO("gpios", &gpio_controller_node, 42, GPIO_ACTIVE_HIGH),
137 { }
138 };
139
140 /* 3. Define the software node for the LED device. */
141 static const struct software_node led_device_swnode = {
142 .name = "status-led",
143 .properties = led_device_props,
144 };
145
146 /*
147 * 4. Register the software nodes and the platform device.
148 */
149 const struct software_node *swnodes[] = {
150 &gpio_controller_node,
151 &led_device_swnode,
152 NULL
153 };
154 software_node_register_node_group(swnodes);
155
156 // Then register a platform_device for "leds-gpio" and associate
157 // it with &led_device_swnode via .fwnode.
158
159 For a complete guide on converting board files to use software nodes, see
160 Documentation/driver-api/gpio/legacy-boards.rst.
161
162 Platform Data
163 -------------
164 Finally, GPIOs can be bound to devices and functions using platform data. Board
165 files that desire to do so need to include the following header::
166
167 #include <linux/gpio/machine.h>
168
169 GPIOs are mapped by the means of tables of lookups, containing instances of the
170 gpiod_lookup structure. Two macros are defined to help declaring such mappings::
171
172 GPIO_LOOKUP(key, chip_hwnum, con_id, flags)
173 GPIO_LOOKUP_IDX(key, chip_hwnum, con_id, idx, flags)
174
175 where
176
177 - key is either the label of the gpiod_chip instance providing the GPIO, or
178 the GPIO line name
179 - chip_hwnum is the hardware number of the GPIO within the chip, or U16_MAX
180 to indicate that key is a GPIO line name
181 - con_id is the name of the GPIO function from the device point of view. It
182 can be NULL, in which case it will match any function.
183 - idx is the index of the GPIO within the function.
184 - flags is defined to specify the following properties:
185 * GPIO_ACTIVE_HIGH - GPIO line is active high
186 * GPIO_ACTIVE_LOW - GPIO line is active low
187 * GPIO_OPEN_DRAIN - GPIO line is set up as open drain
188 * GPIO_OPEN_SOURCE - GPIO line is set up as open source
189 * GPIO_PERSISTENT - GPIO line is persistent during
190 suspend/resume and maintains its value
191 * GPIO_TRANSITORY - GPIO line is transitory and may loose its
192 electrical state during suspend/resume
193
194 In the future, these flags might be extended to support more properties.
195
196 Note that:
197 1. GPIO line names are not guaranteed to be globally unique, so the first
198 match found will be used.
199 2. GPIO_LOOKUP() is just a shortcut to GPIO_LOOKUP_IDX() where idx = 0.
200
201 A lookup table can then be defined as follows, with an empty entry defining its
202 end. The 'dev_id' field of the table is the identifier of the device that will
203 make use of these GPIOs. It can be NULL, in which case it will be matched for
204 calls to gpiod_get() with a NULL device.
205
206 .. code-block:: c
207
208 struct gpiod_lookup_table gpios_table = {
209 .dev_id = "foo.0",
210 .table = {
211 GPIO_LOOKUP_IDX("gpio.0", 15, "led", 0, GPIO_ACTIVE_HIGH),
212 GPIO_LOOKUP_IDX("gpio.0", 16, "led", 1, GPIO_ACTIVE_HIGH),
213 GPIO_LOOKUP_IDX("gpio.0", 17, "led", 2, GPIO_ACTIVE_HIGH),
214 GPIO_LOOKUP("gpio.0", 1, "power", GPIO_ACTIVE_LOW),
215 { },
216 },
217 };
218
219 And the table can be added by the board code as follows::
220
221 gpiod_add_lookup_table(&gpios_table);
222
223 The driver controlling "foo.0" will then be able to obtain its GPIOs as follows::
224
225 struct gpio_desc *red, *green, *blue, *power;
226
227 red = gpiod_get_index(dev, "led", 0, GPIOD_OUT_HIGH);
228 green = gpiod_get_index(dev, "led", 1, GPIOD_OUT_HIGH);
229 blue = gpiod_get_index(dev, "led", 2, GPIOD_OUT_HIGH);
230
231 power = gpiod_get(dev, "power", GPIOD_OUT_HIGH);
232
233 Since the "led" GPIOs are mapped as active-high, this example will switch their
234 signals to 1, i.e. enabling the LEDs. And for the "power" GPIO, which is mapped
235 as active-low, its actual signal will be 0 after this code. Contrary to the
236 legacy integer GPIO interface, the active-low property is handled during
237 mapping and is thus transparent to GPIO consumers.
238
239 A set of functions such as gpiod_set_value() is available to work with
240 the new descriptor-oriented interface.
241
242 Boards using platform data can also hog GPIO lines by defining GPIO hog tables.
243
244 .. code-block:: c
245
246 struct gpiod_hog gpio_hog_table[] = {
247 GPIO_HOG("gpio.0", 10, "foo", GPIO_ACTIVE_LOW, GPIOD_OUT_HIGH),
248 { }
249 };
250
251 And the table can be added to the board code as follows::
252
253 gpiod_add_hogs(gpio_hog_table);
254
255 The line will be hogged as soon as the gpiochip is created or - in case the
256 chip was created earlier - when the hog table is registered.
257
258 Arrays of pins
259 --------------
260 In addition to requesting pins belonging to a function one by one, a device may
261 also request an array of pins assigned to the function. The way those pins are
262 mapped to the device determines if the array qualifies for fast bitmap
263 processing. If yes, a bitmap is passed over get/set array functions directly
264 between a caller and a respective .get/set_multiple() callback of a GPIO chip.
265
266 In order to qualify for fast bitmap processing, the array must meet the
267 following requirements:
268
269 - pin hardware number of array member 0 must also be 0,
270 - pin hardware numbers of consecutive array members which belong to the same
271 chip as member 0 does must also match their array indexes.
272
273 Otherwise fast bitmap processing path is not used in order to avoid consecutive
274 pins which belong to the same chip but are not in hardware order being processed
275 separately.
276
277 If the array applies for fast bitmap processing path, pins which belong to
278 different chips than member 0 does, as well as those with indexes different from
279 their hardware pin numbers, are excluded from the fast path, both input and
280 output. Moreover, open drain and open source pins are excluded from fast bitmap
281 output processing.
282

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

GPIO mapping 개요

1-12

문서 제목은 `GPIO Mappings`이며, GPIO를 특정 device와 function에 할당하는 방법을 설명합니다.

모든 platform에서 GPIO library를 enable할 수 있습니다. Platform이 GPIO 기능의 존재를 반드시 요구한다면 Kconfig에서 `GPIOLIB`을 select해야 합니다.

GPIO mapping 방식은 platform이 hardware layout을 기술하는 방법에 따라 달라집니다. 현재 Device Tree, ACPI, platform data로 mapping을 정의할 수 있습니다.

GPIO mapping source
SourceMapping 위치·방식
Device TreeConsumer node의 <function>-gpios property
ACPI_CRS resource와 _DSD property
Software nodePROPERTY_ENTRY_GPIO() memory property
Platform datagpiod_lookup_table과 GPIO hog table

Platform hardware description 방식별 GPIO mapping 위치입니다.

Device Tree GPIO mapping

13-59

Device Tree에서는 GPIO를 device와 function에 쉽게 mapping할 수 있습니다. 정확한 방식은 GPIO를 제공하는 controller에 따라 다르므로 해당 controller의 Device Tree binding을 확인해야 합니다.

Mapping은 consumer device node의 `<function>-gpios` property에 정의합니다. `<function>`은 driver가 `gpiod_get()`으로 요청할 function name입니다.

foo_device {
        compatible = "acme,foo";
        ...
        led-gpios = <&gpio 15 GPIO_ACTIVE_HIGH>, /* red */
                    <&gpio 16 GPIO_ACTIVE_HIGH>, /* green */
                    <&gpio 17 GPIO_ACTIVE_HIGH>; /* blue */

        power-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
};

단수 suffix인 `<function>-gpio`도 구 binding과의 compatibility를 위해 지원하지만 deprecated되었으므로 새 binding에는 사용하지 않아야 합니다.

예제 property는 GPIO 15, 16, 17을 `led` function으로, GPIO 1을 `power` function으로 driver에 제공합니다.

struct gpio_desc *red, *green, *blue, *power;

red = gpiod_get_index(dev, "led", 0, GPIOD_OUT_HIGH);
green = gpiod_get_index(dev, "led", 1, GPIOD_OUT_HIGH);
blue = gpiod_get_index(dev, "led", 2, GPIOD_OUT_HIGH);

power = gpiod_get(dev, "power", GPIOD_OUT_HIGH);

LED GPIO는 active high이고 power GPIO는 active low이므로 `gpiod_is_active_low(power)`는 true입니다.

`gpiod_get()` 계열의 두 번째 parameter인 `con_id`는 Device Tree suffix `gpios` 또는 `gpio` 앞의 `<function>` prefix와 일치해야 합니다. `led-gpios`에서는 hyphen을 제외한 `led`를 사용합니다.

내부적으로 GPIO subsystem은 `con_id`와 GPIO suffix를 `snprintf(... "%s-%s", con_id, gpio_suffixes[])` 방식으로 결합해 실제 property name을 만듭니다.

Device Tree GPIO 예제 mapping
Property entryFunction·indexPolarityRequest
GPIO 15led[0] redActive highgpiod_get_index(..., 0, ...)
GPIO 16led[1] greenActive highgpiod_get_index(..., 1, ...)
GPIO 17led[2] blueActive highgpiod_get_index(..., 2, ...)
GPIO 1powerActive lowgpiod_get(..., "power", ...)

Property entry와 descriptor request의 대응입니다.

ACPI GPIO mapping

60-96

ACPI도 Device Tree와 비슷한 방식으로 GPIO function name을 지원합니다. 앞의 DT 예제는 ACPI 5.1에서 도입된 `_DSD` Device Specific Data를 사용해 다음과 같은 동등한 ACPI description으로 바꿀 수 있습니다.

Device (FOO) {
        Name (_CRS, ResourceTemplate () {
                GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
                        "\\_SB.GPI0", 0, ResourceConsumer) { 15 } // red
                GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
                        "\\_SB.GPI0", 0, ResourceConsumer) { 16 } // green
                GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
                        "\\_SB.GPI0", 0, ResourceConsumer) { 17 } // blue
                GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionOutputOnly,
                        "\\_SB.GPI0", 0, ResourceConsumer) { 1 } // power
        })

        Name (_DSD, Package () {
                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                Package () {
                        Package () {
                                "led-gpios",
                                Package () {
                                        ^FOO, 0, 0, 1,
                                        ^FOO, 1, 0, 1,
                                        ^FOO, 2, 0, 1,
                                }
                        },
                        Package () { "power-gpios", Package () { ^FOO, 3, 0, 0 } },
                }
        })
}

`_CRS`의 네 `GpioIo` resource는 red, green, blue, power line을 기술하고 `_DSD`의 `led-gpios`와 `power-gpios` package가 consumer function에 연결합니다.

ACPI GPIO binding의 자세한 내용은 `Documentation/firmware-guide/acpi/gpio-properties.rst`를 참조합니다.

Software node 기반 GPIO

97-161

Software node를 사용하면 board-specific code가 `struct software_node`와 `struct property_entry`로 memory 안에 Device Tree와 비슷한 구조를 만들 수 있습니다. 이를 platform device에 연결하면 driver는 ACPI나 Device Tree system과 동일하게 표준 device properties API로 설정을 조회할 수 있습니다.

Software-node-backed GPIO는 `PROPERTY_ENTRY_GPIO()` macro로 기술합니다. 이 macro는 GPIO controller를 나타내는 software node와 consumer device를 연결해 consumer가 `gpiod_get()`, `gpiod_get_optional()` 같은 일반 gpiolib API를 사용하게 합니다.

GPIO controller를 나타내는 software node를 controller device 자체에 attach할 필요는 없습니다. Node가 등록되어 있고 그 name이 GPIO controller label과 일치하기만 하면 됩니다.

다음은 legacy system에서 `platform_data` 대신 GPIO-connected LED 하나를 기술하는 예제입니다.

.. code-block:: c

        #include <linux/property.h>
        #include <linux/gpio/machine.h>
        #include <linux/gpio/property.h>

        /*
         * 1. Define a node for the GPIO controller. Its .name must match the
         *    controller's label.
         */
        static const struct software_node gpio_controller_node = {
                .name = "gpio-foo",
        };

        /* 2. Define the properties for the LED device. */
        static const struct property_entry led_device_props[] = {
                PROPERTY_ENTRY_STRING("label", "myboard:green:status"),
                PROPERTY_ENTRY_STRING("linux,default-trigger", "heartbeat"),
                PROPERTY_ENTRY_GPIO("gpios", &gpio_controller_node, 42, GPIO_ACTIVE_HIGH),
                { }
        };

        /* 3. Define the software node for the LED device. */
        static const struct software_node led_device_swnode = {
                .name = "status-led",
                .properties = led_device_props,
        };

        /*
         * 4. Register the software nodes and the platform device.
         */
        const struct software_node *swnodes[] = {
                &gpio_controller_node,
                &led_device_swnode,
                NULL
        };
        software_node_register_node_group(swnodes);

        // Then register a platform_device for "leds-gpio" and associate
        // it with &led_device_swnode via .fwnode.

예제는 controller label과 일치하는 node를 만들고 LED property에 label, default trigger, active-high GPIO 42를 넣습니다. 두 software node를 group으로 등록한 뒤 `leds-gpio` platform device의 `.fwnode`에 LED node를 연결합니다.

Board file을 software node로 변환하는 전체 지침은 `Documentation/driver-api/gpio/legacy-boards.rst`를 참조합니다.

Software node GPIO 구성 순서
Controller label과 같은 name의 software_node 정의PROPERTY_ENTRY_GPIO()를 포함한 consumer property 작성Consumer software_node에 property 연결software_node_register_node_group() 호출Platform device .fwnode에 consumer node 연결Driver가 gpiod_get()으로 GPIO 요청

Controller node에서 consumer platform device까지의 연결입니다.

Platform data lookup 정의

162-200

마지막으로 platform data로 GPIO를 device와 function에 binding할 수 있습니다. 이를 사용하는 board file은 source path `include/linux/gpio/machine.h`의 header를 include해야 합니다.

#include <linux/gpio/machine.h>

GPIO는 `gpiod_lookup` instance로 구성된 lookup table로 mapping합니다. 두 helper macro는 다음과 같습니다.

GPIO_LOOKUP(key, chip_hwnum, con_id, flags)
GPIO_LOOKUP_IDX(key, chip_hwnum, con_id, idx, flags)

`key`는 GPIO를 제공하는 `gpiod_chip` instance label 또는 GPIO line name입니다. `chip_hwnum`은 chip 안의 hardware GPIO 번호이며, `key`가 GPIO line name임을 나타낼 때는 `U16_MAX`를 사용합니다.

`con_id`는 device 관점의 GPIO function name이며 `NULL`이면 모든 function과 일치합니다. `idx`는 해당 function 안에서 GPIO의 index입니다.

`flags`는 polarity와 electrical·power-state 특성을 지정합니다.

  • `GPIO_ACTIVE_HIGH`: GPIO line이 active high
  • `GPIO_ACTIVE_LOW`: GPIO line이 active low
  • `GPIO_OPEN_DRAIN`: open drain으로 설정
  • `GPIO_OPEN_SOURCE`: open source로 설정
  • `GPIO_PERSISTENT`: suspend/resume 동안 값을 유지
  • `GPIO_TRANSITORY`: suspend/resume 동안 electrical state를 잃을 수 있음

향후 flag는 더 많은 property를 지원하도록 확장될 수 있습니다. GPIO line name은 전역적으로 unique하다고 보장되지 않으므로 첫 번째 match를 사용합니다. `GPIO_LOOKUP()`은 `idx = 0`인 `GPIO_LOOKUP_IDX()`의 shortcut입니다.

gpiod lookup field
Field의미
keygpiochip label 또는 GPIO line name
chip_hwnumChip-local line number, line name이면 U16_MAX
con_idConsumer function name, NULL이면 wildcard
idxFunction 안의 GPIO index
flagsPolarity, open drain/source, persistence

Lookup macro parameter의 의미입니다.

Lookup table 등록과 사용

201-241

Lookup table은 빈 entry로 끝나며 `dev_id`는 이 GPIO를 사용할 device identifier입니다. `dev_id`가 `NULL`이면 device가 `NULL`인 `gpiod_get()` call과 일치합니다.

.. code-block:: c

        struct gpiod_lookup_table gpios_table = {
                .dev_id = "foo.0",
                .table = {
                        GPIO_LOOKUP_IDX("gpio.0", 15, "led", 0, GPIO_ACTIVE_HIGH),
                        GPIO_LOOKUP_IDX("gpio.0", 16, "led", 1, GPIO_ACTIVE_HIGH),
                        GPIO_LOOKUP_IDX("gpio.0", 17, "led", 2, GPIO_ACTIVE_HIGH),
                        GPIO_LOOKUP("gpio.0", 1, "power", GPIO_ACTIVE_LOW),
                        { },
                },
        };

Board code는 다음과 같이 table을 등록합니다.

gpiod_add_lookup_table(&gpios_table);

그러면 `foo.0`을 제어하는 driver가 다음과 같이 descriptor를 얻을 수 있습니다.

struct gpio_desc *red, *green, *blue, *power;

red = gpiod_get_index(dev, "led", 0, GPIOD_OUT_HIGH);
green = gpiod_get_index(dev, "led", 1, GPIOD_OUT_HIGH);
blue = gpiod_get_index(dev, "led", 2, GPIOD_OUT_HIGH);

power = gpiod_get(dev, "power", GPIOD_OUT_HIGH);

`led` GPIO는 active high로 mapping되므로 `GPIOD_OUT_HIGH` 요청 후 실제 signal이 1이 되어 LED가 켜집니다. `power` GPIO는 active low이므로 실제 signal은 0입니다.

Legacy integer GPIO interface와 달리 active-low property는 mapping 단계에서 처리되므로 GPIO consumer에는 투명합니다. 새 descriptor-oriented interface에서는 `gpiod_set_value()` 같은 function 집합을 사용합니다.

Lookup table과 consumer request 대응
LookupConsumer call실제 high request
led[0..2], active highgpiod_get_index()Signal 1
power, active lowgpiod_get()Signal 0

Board mapping이 driver descriptor 요청으로 해석되는 방식입니다.

Platform data GPIO hog

242-257

Platform data를 사용하는 board는 GPIO hog table을 정의해 line을 hog할 수도 있습니다.

.. code-block:: c

        struct gpiod_hog gpio_hog_table[] = {
                GPIO_HOG("gpio.0", 10, "foo", GPIO_ACTIVE_LOW, GPIOD_OUT_HIGH),
                { }
        };

Board code는 다음과 같이 hog table을 등록합니다.

gpiod_add_hogs(gpio_hog_table);

Line은 gpiochip이 생성되는 즉시 hog됩니다. Chip이 먼저 생성된 경우에는 hog table이 등록될 때 hog됩니다.

GPIO hog 적용 시점
GPIO_HOG entry와 빈 terminator 정의gpiod_add_hogs()로 table 등록gpiochip이 나중에 생성되면 생성 시 hoggpiochip이 이미 있으면 table 등록 시 즉시 hog

gpiochip과 hog table 등록 순서에 따른 적용 시점입니다.

Pin array와 fast bitmap path

258-281

Device는 function에 속한 pin을 하나씩 요청하는 대신 전체 pin array를 요청할 수 있습니다. Device에 mapping된 방식에 따라 array가 fast bitmap processing 대상인지 결정됩니다.

Fast path 대상이면 caller와 GPIO chip의 `.get/set_multiple()` callback 사이에서 bitmap을 직접 전달합니다.

Fast bitmap processing을 사용하려면 array member 0의 hardware pin number가 0이어야 하며, member 0과 같은 chip에 속하는 연속 member의 hardware number가 array index와 일치해야 합니다.

조건을 만족하지 않으면 같은 chip의 연속 pin이지만 hardware order가 아닌 pin을 따로 처리하는 것을 피하기 위해 fast path를 사용하지 않습니다.

Array가 fast path 대상이어도 member 0과 다른 chip에 속한 pin, index와 hardware pin number가 다른 pin은 input·output fast path에서 제외됩니다. Open drain과 open source pin도 fast bitmap output 처리에서 제외됩니다.

Pin array fast bitmap 조건
조건결과
Member 0 hardware number = 0필수
같은 chip의 연속 member: hardware number = array index필수
Member 0과 다른 chipFast input·output 제외
Index와 hardware number 불일치Fast input·output 제외
Open drain 또는 open sourceFast output 제외

Fast path 포함·제외 조건을 정리했습니다.