forked from luck/tmp_suning_uos_patched
ad824783fb
Change the format of the platform GPIO lookup tables to make them less confusing and improve lookup efficiency. The previous format was a single linked-list that required to compare the device name and function ID of every single GPIO defined for each lookup. Switch that to a list of per-device tables, so that the lookup can be done in two steps, omitting the GPIOs that are not relevant for a particular device. The matching rules are now defined as follows: - The device name must match *exactly*, and can be NULL for GPIOs not assigned to a particular device, - If the function ID in the lookup table is NULL, the con_id argument of gpiod_get() will not be used for lookup. However, if it is defined, it must match exactly. - The index must always match. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
122 lines
4.5 KiB
Plaintext
122 lines
4.5 KiB
Plaintext
GPIO Mappings
|
|
=============
|
|
|
|
This document explains how GPIOs can be assigned to given devices and functions.
|
|
Note that it only applies to the new descriptor-based interface. For a
|
|
description of the deprecated integer-based GPIO interface please refer to
|
|
gpio-legacy.txt (actually, there is no real mapping possible with the old
|
|
interface; you just fetch an integer from somewhere and request the
|
|
corresponding GPIO.
|
|
|
|
Platforms that make use of GPIOs must select ARCH_REQUIRE_GPIOLIB (if GPIO usage
|
|
is mandatory) or ARCH_WANT_OPTIONAL_GPIOLIB (if GPIO support can be omitted) in
|
|
their Kconfig. Then, how GPIOs are mapped depends on what the platform uses to
|
|
describe its hardware layout. Currently, mappings can be defined through device
|
|
tree, ACPI, and platform data.
|
|
|
|
Device Tree
|
|
-----------
|
|
GPIOs can easily be mapped to devices and functions in the device tree. The
|
|
exact way to do it depends on the GPIO controller providing the GPIOs, see the
|
|
device tree bindings for your controller.
|
|
|
|
GPIOs mappings are defined in the consumer device's node, in a property named
|
|
<function>-gpios, where <function> is the function the driver will request
|
|
through gpiod_get(). For example:
|
|
|
|
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-gpio = <&gpio 1 GPIO_ACTIVE_LOW>;
|
|
};
|
|
|
|
This property will make GPIOs 15, 16 and 17 available to the driver under the
|
|
"led" function, and GPIO 1 as the "power" GPIO:
|
|
|
|
struct gpio_desc *red, *green, *blue, *power;
|
|
|
|
red = gpiod_get_index(dev, "led", 0);
|
|
green = gpiod_get_index(dev, "led", 1);
|
|
blue = gpiod_get_index(dev, "led", 2);
|
|
|
|
power = gpiod_get(dev, "power");
|
|
|
|
The led GPIOs will be active-high, while the power GPIO will be active-low (i.e.
|
|
gpiod_is_active_low(power) will be true).
|
|
|
|
ACPI
|
|
----
|
|
ACPI does not support function names for GPIOs. Therefore, only the "idx"
|
|
argument of gpiod_get_index() is useful to discriminate between GPIOs assigned
|
|
to a device. The "con_id" argument can still be set for debugging purposes (it
|
|
will appear under error messages as well as debug and sysfs nodes).
|
|
|
|
Platform Data
|
|
-------------
|
|
Finally, GPIOs can be bound to devices and functions using platform data. Board
|
|
files that desire to do so need to include the following header:
|
|
|
|
#include <linux/gpio/driver.h>
|
|
|
|
GPIOs are mapped by the means of tables of lookups, containing instances of the
|
|
gpiod_lookup structure. Two macros are defined to help declaring such mappings:
|
|
|
|
GPIO_LOOKUP(chip_label, chip_hwnum, dev_id, con_id, flags)
|
|
GPIO_LOOKUP_IDX(chip_label, chip_hwnum, dev_id, con_id, idx, flags)
|
|
|
|
where
|
|
|
|
- chip_label is the label of the gpiod_chip instance providing the GPIO
|
|
- chip_hwnum is the hardware number of the GPIO within the chip
|
|
- dev_id is the identifier of the device that will make use of this GPIO. It
|
|
can be NULL, in which case it will be matched for calls to gpiod_get()
|
|
with a NULL device.
|
|
- con_id is the name of the GPIO function from the device point of view. It
|
|
can be NULL, in which case it will match any function.
|
|
- idx is the index of the GPIO within the function.
|
|
- flags is defined to specify the following properties:
|
|
* GPIOF_ACTIVE_LOW - to configure the GPIO as active-low
|
|
* GPIOF_OPEN_DRAIN - GPIO pin is open drain type.
|
|
* GPIOF_OPEN_SOURCE - GPIO pin is open source type.
|
|
|
|
In the future, these flags might be extended to support more properties.
|
|
|
|
Note that GPIO_LOOKUP() is just a shortcut to GPIO_LOOKUP_IDX() where idx = 0.
|
|
|
|
A lookup table can then be defined as follows, with an empty entry defining its
|
|
end:
|
|
|
|
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),
|
|
{ },
|
|
},
|
|
};
|
|
|
|
And the table can be added by the board code as follows:
|
|
|
|
gpiod_add_lookup_table(&gpios_table);
|
|
|
|
The driver controlling "foo.0" will then be able to obtain its GPIOs as follows:
|
|
|
|
struct gpio_desc *red, *green, *blue, *power;
|
|
|
|
red = gpiod_get_index(dev, "led", 0);
|
|
green = gpiod_get_index(dev, "led", 1);
|
|
blue = gpiod_get_index(dev, "led", 2);
|
|
|
|
power = gpiod_get(dev, "power");
|
|
gpiod_direction_output(power, 1);
|
|
|
|
Since the "power" GPIO is mapped as active-low, its actual signal will be 0
|
|
after this code. Contrary to the legacy integer GPIO interface, the active-low
|
|
property is handled during mapping and is thus transparent to GPIO consumers.
|