Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Fri, Apr 12, 2013 at 12:35:05AM +0200, Linus Walleij wrote: > On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg > 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. -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Fri, Apr 12, 2013 at 12:35:05AM +0200, Linus Walleij wrote: On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg mika.westerb...@linux.intel.com 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. -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Friday, April 12, 2013 12:33:55 AM Linus Walleij wrote: > On Wed, Apr 3, 2013 at 12:56 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 > > 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. -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg 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 -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Wed, Apr 3, 2013 at 12:56 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 Patch applied with Rafael's ACK and pushed. Thanks, Linus Walleij -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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 > > Acked-by: Rafael J. Wysocki Grant and Linus W, Do you have any comments on this patch? Could it still be merged for 3.10? Thanks. -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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 mika.westerb...@linux.intel.com Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Grant and Linus W, Do you have any comments on this patch? Could it still be merged for 3.10? Thanks. -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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 Patch applied with Rafael's ACK and pushed. Thanks, Linus Walleij -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Thu, Apr 11, 2013 at 9:29 AM, Mika Westerberg mika.westerb...@linux.intel.com 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 -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Friday, April 12, 2013 12:33:55 AM Linus Walleij wrote: 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 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. -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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 :-/ -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Thu, Apr 4, 2013 at 11:57 AM, Mika Westerberg
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
>> 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
>> >> 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
>> >> > ---
>> >> > 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, 0x, 0x,
>> >> > 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,
>> >> > +0x, "\\_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
--
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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Thu, Apr 04, 2013 at 11:42:11AM +0200, Benjamin Tissoires wrote:
> On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
> 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
> >> 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
> >> > ---
> >> > 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, 0x, 0x,
> >> > 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,
> >> > +0x, "\\_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).
--
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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
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
>> 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
>> > ---
>> > 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, 0x, 0x,
>> > 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,
>> > +0x, "\\_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
--
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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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
> 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
> > ---
> > 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, 0x, 0x,
> > 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,
> > +0x, "\\_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.
--
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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
Hi Mika,
On Wed, Apr 3, 2013 at 12:56 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
> ---
> 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, 0x, 0x,
> 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,
> +0x, "\\_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
> 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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, 0x, 0x,
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,
+0x, \\_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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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
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, 0x, 0x,
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,
+0x, \\_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.
--
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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
mika.westerb...@linux.intel.com 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
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, 0x, 0x,
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,
+0x, \\_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
--
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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Thu, Apr 04, 2013 at 11:42:11AM +0200, Benjamin Tissoires wrote:
On Thu, Apr 4, 2013 at 11:38 AM, Mika Westerberg
mika.westerb...@linux.intel.com 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
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, 0x, 0x,
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,
+0x, \\_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).
--
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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
On Thu, Apr 4, 2013 at 11:57 AM, Mika Westerberg
mika.westerb...@linux.intel.com 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
mika.westerb...@linux.intel.com 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
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, 0x, 0x,
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,
+0x, \\_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
--
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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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 :-/ -- 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/
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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
Acked-by: Rafael J. Wysocki
> ---
> 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, 0x, 0x,
> 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,
> + 0x, "\\_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
> 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 = >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,
Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper
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 mika.westerb...@linux.intel.com
Acked-by: Rafael J. Wysocki rafael.j.wyso...@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, 0x, 0x,
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,
+ 0x, \\_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)
+{
