Documentation/firmware-guide/acpi/gpio-properties.rst

Source file repositories/reference/linux-study-clean/Documentation/firmware-guide/acpi/gpio-properties.rst

File Facts

System
Linux kernel
Corpus path
Documentation/firmware-guide/acpi/gpio-properties.rst
Extension
.rst
Size
13753 bytes
Lines
337
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

Package () { "reset-gpios", Package () { ^BTH, 1, 1, 0 } },
              Package () { "shutdown-gpios", Package () { ^BTH, 0, 0, 0 } },
          }
      })
  }

The format of the supported GPIO property is::

  Package () { "name", Package () { ref, index, pin, active_low }}

ref
  The device that has _CRS containing GpioIo()/GpioInt() resources,
  typically this is the device itself (BTH in our case).
index
  Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin
  Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low
  If 1, the GPIO is marked as active-low.

Since ACPI GpioIo() resource does not have a field saying whether it is
active-low or active-high, the "active_low" argument can be used here.
Setting it to 1 marks the GPIO as active-low.

Note, active_low in _DSD does not make sense for GpioInt() resource and
must be 0. GpioInt() resource has its own means of defining it.

In our Bluetooth example the "reset-gpios" refers to the second GpioIo()
resource, second pin in that resource with the GPIO number of 31.

The GpioIo() resource unfortunately doesn't explicitly provide an initial
state of the output pin which driver should use during its initialization.

Linux tries to use common sense here and derives the state from the bias
and polarity settings. The table below shows the expectations:

+-------------+-------------+-----------------------------------------------+
| Pull Bias   | Polarity    | Requested...                                  |
+=============+=============+===============================================+
| Implicit                                                                  |
+-------------+-------------+-----------------------------------------------+
| **Default** | x           | AS IS (assumed firmware configured it for us) |
+-------------+-------------+-----------------------------------------------+
| Explicit                                                                  |
+-------------+-------------+-----------------------------------------------+
| **None**    | x           | AS IS (assumed firmware configured it for us) |
|             |             | with no Pull Bias                             |
+-------------+-------------+-----------------------------------------------+
| **Up**      | x (no _DSD) |                                               |
|             +-------------+ as high, assuming non-active                  |
|             | Low         |                                               |
|             +-------------+-----------------------------------------------+
|             | High        | as high, assuming active                      |
+-------------+-------------+-----------------------------------------------+
| **Down**    | x (no _DSD) |                                               |
|             +-------------+ as low, assuming non-active                   |
|             | High        |                                               |
|             +-------------+-----------------------------------------------+
|             | Low         | as low, assuming active                       |
+-------------+-------------+-----------------------------------------------+

That said, for our above example, since the bias setting is explicit and
_DSD is present, both GPIOs will be treated as active with a high
polarity and Linux will configure the pins in this state until a driver
reprograms them differently.

It is possible to leave holes in the array of GPIOs. This is useful in
cases like with SPI host controllers where some chip selects may be
implemented as GPIOs and some as native signals. For example a SPI host
controller can have chip selects 0 and 2 implemented as GPIOs and 1 as

Annotation

Implementation Notes