Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759265Ab3DDJmQ (ORCPT ); Thu, 4 Apr 2013 05:42:16 -0400 Received: from mail-lb0-f171.google.com ([209.85.217.171]:44307 "EHLO mail-lb0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759122Ab3DDJmN (ORCPT ); Thu, 4 Apr 2013 05:42:13 -0400 MIME-Version: 1.0 In-Reply-To: <20130404093820.GI21804@intel.com> References: <1364986614-15711-1-git-send-email-mika.westerberg@linux.intel.com> <20130404093820.GI21804@intel.com> Date: Thu, 4 Apr 2013 11:42:11 +0200 Message-ID: Subject: Re: [PATCH] gpiolib-acpi: introduce acpi_get_gpio_by_index() helper From: Benjamin Tissoires To: Mika Westerberg Cc: linux-kernel@vger.kernel.org, Grant Likely , Linus Walleij , "Rafael J. Wysocki" , Mathias Nyman , linux-acpi@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3589 Lines: 77 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, 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/