diff options
-rw-r--r-- | Documentation/acpi/gpio-properties.txt | 44 | ||||
-rw-r--r-- | Documentation/gpio/consumer.txt | 18 |
2 files changed, 62 insertions, 0 deletions
diff --git a/Documentation/acpi/gpio-properties.txt b/Documentation/acpi/gpio-properties.txt index 3e45b8b7e4f2..ae36fcf86dc7 100644 --- a/Documentation/acpi/gpio-properties.txt +++ b/Documentation/acpi/gpio-properties.txt | |||
@@ -50,3 +50,47 @@ it to 1 marks the GPIO as active low. | |||
50 | 50 | ||
51 | In our Bluetooth example the "reset-gpio" refers to the second GpioIo() | 51 | In our Bluetooth example the "reset-gpio" refers to the second GpioIo() |
52 | resource, second pin in that resource with the GPIO number of 31. | 52 | resource, second pin in that resource with the GPIO number of 31. |
53 | |||
54 | ACPI GPIO Mappings Provided by Drivers | ||
55 | -------------------------------------- | ||
56 | |||
57 | There are systems in which the ACPI tables do not contain _DSD but provide _CRS | ||
58 | with GpioIo()/GpioInt() resources and device drivers still need to work with | ||
59 | them. | ||
60 | |||
61 | In those cases ACPI device identification objects, _HID, _CID, _CLS, _SUB, _HRV, | ||
62 | available to the driver can be used to identify the device and that is supposed | ||
63 | to be sufficient to determine the meaning and purpose of all of the GPIO lines | ||
64 | listed by the GpioIo()/GpioInt() resources returned by _CRS. In other words, | ||
65 | the driver is supposed to know what to use the GpioIo()/GpioInt() resources for | ||
66 | once it has identified the device. Having done that, it can simply assign names | ||
67 | to the GPIO lines it is going to use and provide the GPIO subsystem with a | ||
68 | mapping between those names and the ACPI GPIO resources corresponding to them. | ||
69 | |||
70 | To do that, the driver needs to define a mapping table as a NULL-terminated | ||
71 | array of struct acpi_gpio_mapping objects that each contain a name, a pointer | ||
72 | to an array of line data (struct acpi_gpio_params) objects and the size of that | ||
73 | array. Each struct acpi_gpio_params object consists of three fields, | ||
74 | crs_entry_index, line_index, active_low, representing the index of the target | ||
75 | GpioIo()/GpioInt() resource in _CRS starting from zero, the index of the target | ||
76 | line in that resource starting from zero, and the active-low flag for that line, | ||
77 | respectively, in analogy with the _DSD GPIO property format specified above. | ||
78 | |||
79 | For the example Bluetooth device discussed previously the data structures in | ||
80 | question would look like this: | ||
81 | |||
82 | static const struct acpi_gpio_params reset_gpio = { 1, 1, false }; | ||
83 | static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false }; | ||
84 | |||
85 | static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = { | ||
86 | { "reset-gpio", &reset_gpio, 1 }, | ||
87 | { "shutdown-gpio", &shutdown_gpio, 1 }, | ||
88 | { }, | ||
89 | }; | ||
90 | |||
91 | Next, the mapping table needs to be passed as the second argument to | ||
92 | acpi_dev_add_driver_gpios() that will register it with the ACPI device object | ||
93 | pointed to by its first argument. That should be done in the driver's .probe() | ||
94 | routine. On removal, the driver should unregister its GPIO mapping table by | ||
95 | calling acpi_dev_remove_driver_gpios() on the ACPI device object where that | ||
96 | table was previously registered. | ||
diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt index 6ce544191ca6..859918db36b8 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/gpio/consumer.txt | |||
@@ -219,6 +219,24 @@ part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are system wakeup | |||
219 | capabilities. | 219 | capabilities. |
220 | 220 | ||
221 | 221 | ||
222 | GPIOs and ACPI | ||
223 | ============== | ||
224 | |||
225 | On ACPI systems, GPIOs are described by GpioIo()/GpioInt() resources listed by | ||
226 | the _CRS configuration objects of devices. Those resources do not provide | ||
227 | connection IDs (names) for GPIOs, so it is necessary to use an additional | ||
228 | mechanism for this purpose. | ||
229 | |||
230 | Systems compliant with ACPI 5.1 or newer may provide a _DSD configuration object | ||
231 | which, among other things, may be used to provide connection IDs for specific | ||
232 | GPIOs described by the GpioIo()/GpioInt() resources in _CRS. If that is the | ||
233 | case, it will be handled by the GPIO subsystem automatically. However, if the | ||
234 | _DSD is not present, the mappings between GpioIo()/GpioInt() resources and GPIO | ||
235 | connection IDs need to be provided by device drivers. | ||
236 | |||
237 | For details refer to Documentation/acpi/gpio-properties.txt | ||
238 | |||
239 | |||
222 | Interacting With the Legacy GPIO Subsystem | 240 | Interacting With the Legacy GPIO Subsystem |
223 | ========================================== | 241 | ========================================== |
224 | Many kernel subsystems still handle GPIOs using the legacy integer-based | 242 | Many kernel subsystems still handle GPIOs using the legacy integer-based |