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 <[email protected]>
---
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,,)
+ {
+ // 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.
diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index a063eb0..b66df3b 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -54,6 +54,83 @@ int acpi_get_gpio(char *path, int pin)
}
EXPORT_SYMBOL_GPL(acpi_get_gpio);
+struct acpi_gpio_lookup {
+ struct acpi_gpio_info info;
+ int index;
+ int gpio;
+ int n;
+};
+
+static int acpi_find_gpio(struct acpi_resource *ares, void *data)
+{
+ struct acpi_gpio_lookup *lookup = data;
+
+ if (ares->type != ACPI_RESOURCE_TYPE_GPIO)
+ return 1;
+
+ if (lookup->n++ == lookup->index && lookup->gpio < 0) {
+ const struct acpi_resource_gpio *agpio = &ares->data.gpio;
+
+ lookup->gpio = acpi_get_gpio(agpio->resource_source.string_ptr,
+ agpio->pin_table[0]);
+ lookup->info.gpioint =
+ agpio->connection_type == ACPI_RESOURCE_GPIO_TYPE_INT;
+ }
+
+ return 1;
+}
+
+/**
+ * acpi_get_gpio_by_index() - get a GPIO number from device resources
+ * @dev: pointer to a device to get GPIO from
+ * @index: index of GpioIo/GpioInt resource (starting from %0)
+ * @info: info pointer to fill in (optional)
+ *
+ * Function goes through ACPI resources for @dev and based on @index looks
+ * up a GpioIo/GpioInt resource, translates it to the Linux GPIO number,
+ * and returns it. @index matches GpioIo/GpioInt resources only so if there
+ * are total %3 GPIO resources, the index goes from %0 to %2.
+ *
+ * If the GPIO cannot be translated or there is an error, negative errno is
+ * returned.
+ *
+ * Note: if the GPIO resource has multiple entries in the pin list, this
+ * function only returns the first.
+ */
+int acpi_get_gpio_by_index(struct device *dev, int index,
+ struct acpi_gpio_info *info)
+{
+ struct acpi_gpio_lookup lookup;
+ struct list_head resource_list;
+ struct acpi_device *adev;
+ acpi_handle handle;
+ int ret;
+
+ if (!dev)
+ return -EINVAL;
+
+ handle = ACPI_HANDLE(dev);
+ if (!handle || acpi_bus_get_device(handle, &adev))
+ return -ENODEV;
+
+ memset(&lookup, 0, sizeof(lookup));
+ lookup.index = index;
+ lookup.gpio = -ENODEV;
+
+ INIT_LIST_HEAD(&resource_list);
+ ret = acpi_dev_get_resources(adev, &resource_list, acpi_find_gpio,
+ &lookup);
+ if (ret < 0)
+ return ret;
+
+ acpi_dev_free_resource_list(&resource_list);
+
+ if (lookup.gpio >= 0 && info)
+ *info = lookup.info;
+
+ return lookup.gpio;
+}
+EXPORT_SYMBOL_GPL(acpi_get_gpio_by_index);
static irqreturn_t acpi_gpio_irq_handler(int irq, void *data)
{
diff --git a/include/linux/acpi_gpio.h b/include/linux/acpi_gpio.h
index b76ebd0..598ea41 100644
--- a/include/linux/acpi_gpio.h
+++ b/include/linux/acpi_gpio.h
@@ -1,12 +1,23 @@
#ifndef _LINUX_ACPI_GPIO_H_
#define _LINUX_ACPI_GPIO_H_
+#include <linux/device.h>
#include <linux/errno.h>
#include <linux/gpio.h>
+/**
+ * struct acpi_gpio_info - ACPI GPIO specific information
+ * @gpioint: if %true this GPIO is of type GpioInt otherwise type is GpioIo
+ */
+struct acpi_gpio_info {
+ bool gpioint;
+};
+
#ifdef CONFIG_GPIO_ACPI
int acpi_get_gpio(char *path, int pin);
+int acpi_get_gpio_by_index(struct device *dev, int index,
+ struct acpi_gpio_info *info);
void acpi_gpiochip_request_interrupts(struct gpio_chip *chip);
#else /* CONFIG_GPIO_ACPI */
@@ -16,6 +27,12 @@ static inline int acpi_get_gpio(char *path, int pin)
return -ENODEV;
}
+static inline int acpi_get_gpio_by_index(struct device *dev, int index,
+ struct acpi_gpio_info *info)
+{
+ return -ENODEV;
+}
+
static inline void acpi_gpiochip_request_interrupts(struct gpio_chip *chip) { }
#endif /* CONFIG_GPIO_ACPI */
--
1.7.10.4
On Wednesday, April 03, 2013 01:56:54 PM Mika Westerberg 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 <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
> ---
> 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,,)
> + {
> + // 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.
>
> diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
> index a063eb0..b66df3b 100644
> --- a/drivers/gpio/gpiolib-acpi.c
> +++ b/drivers/gpio/gpiolib-acpi.c
> @@ -54,6 +54,83 @@ int acpi_get_gpio(char *path, int pin)
> }
> EXPORT_SYMBOL_GPL(acpi_get_gpio);
>
> +struct acpi_gpio_lookup {
> + struct acpi_gpio_info info;
> + int index;
> + int gpio;
> + int n;
> +};
> +
> +static int acpi_find_gpio(struct acpi_resource *ares, void *data)
> +{
> + struct acpi_gpio_lookup *lookup = data;
> +
> + if (ares->type != ACPI_RESOURCE_TYPE_GPIO)
> + return 1;
> +
> + if (lookup->n++ == lookup->index && lookup->gpio < 0) {
> + const struct acpi_resource_gpio *agpio = &ares->data.gpio;
> +
> + lookup->gpio = acpi_get_gpio(agpio->resource_source.string_ptr,
> + agpio->pin_table[0]);
> + lookup->info.gpioint =
> + agpio->connection_type == ACPI_RESOURCE_GPIO_TYPE_INT;
> + }
> +
> + return 1;
> +}
> +
> +/**
> + * acpi_get_gpio_by_index() - get a GPIO number from device resources
> + * @dev: pointer to a device to get GPIO from
> + * @index: index of GpioIo/GpioInt resource (starting from %0)
> + * @info: info pointer to fill in (optional)
> + *
> + * Function goes through ACPI resources for @dev and based on @index looks
> + * up a GpioIo/GpioInt resource, translates it to the Linux GPIO number,
> + * and returns it. @index matches GpioIo/GpioInt resources only so if there
> + * are total %3 GPIO resources, the index goes from %0 to %2.
> + *
> + * If the GPIO cannot be translated or there is an error, negative errno is
> + * returned.
> + *
> + * Note: if the GPIO resource has multiple entries in the pin list, this
> + * function only returns the first.
> + */
> +int acpi_get_gpio_by_index(struct device *dev, int index,
> + struct acpi_gpio_info *info)
> +{
> + struct acpi_gpio_lookup lookup;
> + struct list_head resource_list;
> + struct acpi_device *adev;
> + acpi_handle handle;
> + int ret;
> +
> + if (!dev)
> + return -EINVAL;
> +
> + handle = ACPI_HANDLE(dev);
> + if (!handle || acpi_bus_get_device(handle, &adev))
> + return -ENODEV;
> +
> + memset(&lookup, 0, sizeof(lookup));
> + lookup.index = index;
> + lookup.gpio = -ENODEV;
> +
> + INIT_LIST_HEAD(&resource_list);
> + ret = acpi_dev_get_resources(adev, &resource_list, acpi_find_gpio,
> + &lookup);
> + if (ret < 0)
> + return ret;
> +
> + acpi_dev_free_resource_list(&resource_list);
> +
> + if (lookup.gpio >= 0 && info)
> + *info = lookup.info;
> +
> + return lookup.gpio;
> +}
> +EXPORT_SYMBOL_GPL(acpi_get_gpio_by_index);
>
> static irqreturn_t acpi_gpio_irq_handler(int irq, void *data)
> {
> diff --git a/include/linux/acpi_gpio.h b/include/linux/acpi_gpio.h
> index b76ebd0..598ea41 100644
> --- a/include/linux/acpi_gpio.h
> +++ b/include/linux/acpi_gpio.h
> @@ -1,12 +1,23 @@
> #ifndef _LINUX_ACPI_GPIO_H_
> #define _LINUX_ACPI_GPIO_H_
>
> +#include <linux/device.h>
> #include <linux/errno.h>
> #include <linux/gpio.h>
>
> +/**
> + * struct acpi_gpio_info - ACPI GPIO specific information
> + * @gpioint: if %true this GPIO is of type GpioInt otherwise type is GpioIo
> + */
> +struct acpi_gpio_info {
> + bool gpioint;
> +};
> +
> #ifdef CONFIG_GPIO_ACPI
>
> int acpi_get_gpio(char *path, int pin);
> +int acpi_get_gpio_by_index(struct device *dev, int index,
> + struct acpi_gpio_info *info);
> void acpi_gpiochip_request_interrupts(struct gpio_chip *chip);
>
> #else /* CONFIG_GPIO_ACPI */
> @@ -16,6 +27,12 @@ static inline int acpi_get_gpio(char *path, int pin)
> return -ENODEV;
> }
>
> +static inline int acpi_get_gpio_by_index(struct device *dev, int index,
> + struct acpi_gpio_info *info)
> +{
> + return -ENODEV;
> +}
> +
> static inline void acpi_gpiochip_request_interrupts(struct gpio_chip *chip) { }
>
> #endif /* CONFIG_GPIO_ACPI */
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
Hi Mika,
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
<[email protected]> 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 <[email protected]>
> ---
> 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]
On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
> Hi Mika,
>
> On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
> <[email protected]> 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 <[email protected]>
> > ---
> > 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.
Why not. But then again you can always check the type returned in the
acpi_gpio_info structure and pick the first GpioInt (if you have multiple
GPIO resources).
> 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).
Well, index is the only thing we can rely on unfortunately. There's nothing
like names or anything like that.
What I've seen from ACPI enumerated i2c-hid devices there is only one GPIO
resource (GpioInt) declared.
On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
<[email protected]> wrote:
> On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
>> Hi Mika,
>>
>> On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
>> <[email protected]> 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 <[email protected]>
>> > ---
>> > 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.
>
> Why not. But then again you can always check the type returned in the
> acpi_gpio_info structure and pick the first GpioInt (if you have multiple
> GPIO resources).
>
>> 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).
>
> Well, index is the only thing we can rely on unfortunately. There's nothing
> like names or anything like that.
>
> What I've seen from ACPI enumerated i2c-hid devices there is only one GPIO
> resource (GpioInt) declared.
Ok, thanks for the answer. I guess the idea would be to pick the index
0, check the type, and try indexes 1 or 2 if it's not GpioInt. I bet
there will be devices with more than one Gpio as most of I2C input
device have a reset line (except if Microsoft forces them not to have
one).
Cheers,
Benjamin
On Thu, Apr 04, 2013 at 11:42:11AM +0200, Benjamin Tissoires wrote:
> On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
> <[email protected]> wrote:
> > On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
> >> Hi Mika,
> >>
> >> On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
> >> <[email protected]> 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 <[email protected]>
> >> > ---
> >> > 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.
> >
> > Why not. But then again you can always check the type returned in the
> > acpi_gpio_info structure and pick the first GpioInt (if you have multiple
> > GPIO resources).
> >
> >> 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).
> >
> > Well, index is the only thing we can rely on unfortunately. There's nothing
> > like names or anything like that.
> >
> > What I've seen from ACPI enumerated i2c-hid devices there is only one GPIO
> > resource (GpioInt) declared.
>
> Ok, thanks for the answer. I guess the idea would be to pick the index
> 0, check the type, and try indexes 1 or 2 if it's not GpioInt. I bet
> there will be devices with more than one Gpio as most of I2C input
> device have a reset line (except if Microsoft forces them not to have
> one).
One option is to provide acpi_get_gpio_all() that returns all GPIOs and
their corresponding types. That should allow clients like i2c-hid to find
the right GPIO (I'm hoping that there will be only one GpioInt associated
with these devices).
On Thu, Apr 4, 2013 at 11:57 AM, Mika Westerberg
<[email protected]> wrote:
> On Thu, Apr 04, 2013 at 11:42:11AM +0200, Benjamin Tissoires wrote:
>> On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
>> <[email protected]> wrote:
>> > On Thu, Apr 04, 2013 at 11:19:53AM +0200, Benjamin Tissoires wrote:
>> >> Hi Mika,
>> >>
>> >> On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
>> >> <[email protected]> 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 <[email protected]>
>> >> > ---
>> >> > 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.
>> >
>> > Why not. But then again you can always check the type returned in the
>> > acpi_gpio_info structure and pick the first GpioInt (if you have multiple
>> > GPIO resources).
>> >
>> >> 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).
>> >
>> > Well, index is the only thing we can rely on unfortunately. There's nothing
>> > like names or anything like that.
>> >
>> > What I've seen from ACPI enumerated i2c-hid devices there is only one GPIO
>> > resource (GpioInt) declared.
>>
>> Ok, thanks for the answer. I guess the idea would be to pick the index
>> 0, check the type, and try indexes 1 or 2 if it's not GpioInt. I bet
>> there will be devices with more than one Gpio as most of I2C input
>> device have a reset line (except if Microsoft forces them not to have
>> one).
>
> One option is to provide acpi_get_gpio_all() that returns all GPIOs and
> their corresponding types. That should allow clients like i2c-hid to find
> the right GPIO (I'm hoping that there will be only one GpioInt associated
> with these devices).
That could do the trick.
However, I won't be able to test it. I still don't have access to any
ACPI 5 device with i2c-hid devices...
As for the multiple GpioInt: I hope too. But I can not see why would
somebody put several GpioInt to a HID device (GpioIo are more expected
to be present). The spec is not compliant with this idea, but we never
know :)
Cheers,
Benjamin
On Thu, Apr 04, 2013 at 12:01:23PM +0200, Benjamin Tissoires wrote:
> > One option is to provide acpi_get_gpio_all() that returns all GPIOs and
> > their corresponding types. That should allow clients like i2c-hid to find
> > the right GPIO (I'm hoping that there will be only one GpioInt associated
> > with these devices).
>
> That could do the trick.
Great.
> However, I won't be able to test it. I still don't have access to any
> ACPI 5 device with i2c-hid devices...
I have few such devices but none of them has GpioInt resources (they have
the interrupt line routed to ioapic), so I can't test the i2c-hid with
GpioInt either :-/
On Wed, Apr 03, 2013 at 01:04:26PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 03, 2013 01:56:54 PM Mika Westerberg 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 <[email protected]>
>
> Acked-by: Rafael J. Wysocki <[email protected]>
Grant and Linus W,
Do you have any comments on this patch? Could it still be merged for 3.10?
Thanks.
On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
<[email protected]> 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 <[email protected]>
Patch applied with Rafael's ACK and pushed.
Thanks,
Linus Walleij
On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg
<[email protected]> wrote:
> Grant and Linus W,
>
> Do you have any comments on this patch? Could it still be merged for 3.10?
No and yes.
Applied and pushed for linux-next now.
Sorry for taking so long, I was confused by the discussion.
I had to use some fuzzing to apply the patch, please check the
result in linux-next.
Linus
On Friday, April 12, 2013 12:33:55 AM Linus Walleij wrote:
> On Wed, Apr 3, 2013 at 12:56 PM, Mika Westerberg
> <[email protected]> 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 <[email protected]>
>
> Patch applied with Rafael's ACK and pushed.
Thanks a lot Linus!
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
On Fri, Apr 12, 2013 at 12:35:05AM +0200, Linus Walleij wrote:
> On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg
> <[email protected]> wrote:
>
> > Grant and Linus W,
> >
> > Do you have any comments on this patch? Could it still be merged for 3.10?
>
> No and yes.
>
> Applied and pushed for linux-next now.
Thanks!
> Sorry for taking so long, I was confused by the discussion.
np. We probably need to add another ACPI GPIO helper function to get all
the GPIOs but I guess we can do that once a need emerges. For a single GPIO
(like the patch here does) we know already from internal discussion that it
will be needed.
> I had to use some fuzzing to apply the patch, please check the
> result in linux-next.
Looks good to me.