summaryrefslogtreecommitdiffstats
path: root/Documentation/acpi/gpio-properties.txt (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Documentation: ACPI: move gpio-properties.txt to firmware-guide/acpi and ↵Changbin Du2019-04-251-223/+0
| | | | | | | | | | | | | convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du <changbin.du@gmail.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* gpio: acpi: Explain how to get GPIO descriptors in ACPI caseAndy Shevchenko2017-05-291-0/+65
| | | | | | | | | | | | | Documentation lacks of explanation how we actually use device properties for GPIO resources. Add a section to the documentation about that. Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* ACPI / gpio: Add support for naming GPIOsMika Westerberg2016-10-241-0/+12
| | | | | | | | | Now that we have the new helper function that sets nice names for GPIO lines based on "gpio-line-names" device property, we can take advantage of this in acpi_gpiochip_add(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* ACPI / gpio: Add hogging supportMika Westerberg2016-10-241-0/+35
| | | | | | | | | | | | | GPIO hogging means that the GPIO controller can "hog" and configure certain GPIOs without need for a driver or userspace to do that. This is useful in open-connected boards where BIOS cannot possibly know beforehand which devices will be connected to the board. This adds GPIO hogging mechanism to ACPI analogous to Device Tree. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* ACPI / gpio: Allow holes in list of GPIOs for a deviceMika Westerberg2016-10-241-0/+15
| | | | | | | | | | | | | | | Make it possible to have an empty GPIOs in a GPIO list for device. For example a SPI master may use both GPIOs and native pins as chip selects and we need to be able to distinguish between the two. This makes it mandatory to have exactly 3 arguments for GPIOs and then converts gpiolib to use of __acpi_node_get_property_reference() instead. In addition we make acpi_gpio_package_count() to handle holes as well (this matches the DT version). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* ACPI / documentation: Use recommended name in GPIO property namesMika Westerberg2016-09-291-5/+5
| | | | | | | | | The recommended property name for all kinds of GPIOs is to end it with "-gpios" even if there is only one GPIO. Update the documentation to follow this fact. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / documentation: Fix ambiguity in the GPIO properties documentRafael J. Wysocki2015-05-041-3/+3
| | | | | | | | | | The first paragraph in Documentation/acpi/gpio-properties.txt is ambiguous, so make it more clear. Reported-by: Antonio Ospite <ao2@ao2.it> Acked-by: Antonio Ospite <ao2@ao2.it> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* ACPI / GPIO: Document ACPI GPIO mappings APIRafael J. Wysocki2014-11-041-0/+44
| | | | | | | | | Document the previously introduced method that can be used by device drivers to provide the GPIO subsystem with mappings between GPIO names (connection IDs) and GpioIo()/GpioInt() resources in _CRS. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* gpio / ACPI: Add support for _DSD device propertiesMika Westerberg2014-11-041-0/+52
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and other things as well) returned by _CRS. Previously we were only able to use integer index to find the corresponding GPIO, which is pretty error prone if the order changes. With _DSD we can now query GPIOs using name instead of an integer index, like the below example shows: // Bluetooth device with reset and shutdown GPIOs Device (BTH) { Name (_HID, ...) Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {15} GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} }) Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }}, Package () {"shutdown-gpio", 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 field saying whether it is active low or high, the "active_low" argument can be used here. Setting it to 1 marks the GPIO as active low. In our Bluetooth example the "reset-gpio" refers to the second GpioIo() resource, second pin in that resource with the GPIO number of 31. This patch implements necessary support to gpiolib for extracting GPIOs using _DSD device properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>