Hi Mika,

On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
<mika.westerb...@linux.intel.com> wrote:
> Instead of open-coding ACPI GPIO resource lookup in each driver, we provide
> a helper function analogous to Device Tree version that allows drivers to
> specify which GPIO resource they are interested (using an index to the GPIO
> resources). The function then finds out the correct resource, translates
> the ACPI GPIO number to the corresponding Linux GPIO number and returns
> that.
>
> Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
> ---
>  Documentation/acpi/enumeration.txt |   32 ++++++++++++++-
>  drivers/gpio/gpiolib-acpi.c        |   77 
> ++++++++++++++++++++++++++++++++++++
>  include/linux/acpi_gpio.h          |   17 ++++++++
>  3 files changed, 125 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/acpi/enumeration.txt 
> b/Documentation/acpi/enumeration.txt
> index 94a6561..b0d5410 100644
> --- a/Documentation/acpi/enumeration.txt
> +++ b/Documentation/acpi/enumeration.txt
> @@ -199,6 +199,8 @@ the device to the driver. For example:
>         {
>                 Name (SBUF, ResourceTemplate()
>                 {
> +                       ...
> +                       // Used to power on/off the device
>                         GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
>                                 IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
>                                 0x00, ResourceConsumer,,)
> @@ -206,10 +208,20 @@ the device to the driver. For example:
>                                 // Pin List
>                                 0x0055
>                         }
> +
> +                       // Interrupt for the device
> +                       GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
> +                                0x0000, "\\_SB.PCI0.GPI0", 0x00, 
> ResourceConsumer,,)

Sorry for coming late in the GPIO ACPI discussion, but when I see this
documentation, I wonder:
wouldn't it be feasible to find the correct GPIO by its type? Here, we
have a GpioIo and a GpioInt, and I bet this would be sometime more
useful to request the first GpioInt without knowing the correct order
of declarations.

It may be feasible by walking the tree, but a helper would be of great
help (thinking at i2c-hid here, which can not rely on indexes in the
DSDT).

Cheers,
Benjamin

> +                       {
> +                               // Pin list
> +                               0x0058
> +                       }
> +
>                         ...
>
> -                       Return (SBUF)
>                 }
> +
> +               Return (SBUF)
>         }
>
>  These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
> @@ -220,6 +232,24 @@ The driver can do this by including <linux/acpi_gpio.h> 
> and then calling
>  acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
>  negative errno if there was no translation found.
>
> +In a simple case of just getting the Linux GPIO number from device
> +resources one can use acpi_get_gpio_by_index() helper function. It takes
> +pointer to the device and index of the GpioIo/GpioInt descriptor in the
> +device resources list. For example:
> +
> +       int gpio_irq, gpio_power;
> +       int ret;
> +
> +       gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
> +       if (gpio_irq < 0)
> +               /* handle error */
> +
> +       gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
> +       if (gpio_power < 0)
> +               /* handle error */
> +
> +       /* Now we can use the GPIO numbers */
> +
>  Other GpioIo parameters must be converted first by the driver to be
>  suitable to the gpiolib before passing them.
>
[snipped]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to