Re: [PATCH] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Monday, November 17, 2014 01:28:54 PM Alexandre Courbot wrote: > On Fri, Nov 14, 2014 at 5:58 PM, Linus Walleij > wrote: > > On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki > > wrote: > >> On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote: > > > >>> With that change: > >>> Reviewed-by: Linus Walleij > >> > >> OK, made the changes and added your Reviewed-by. > >> > >> One semi-related question though. Alexandre ACKed the patch before, so > >> what did that mean from the GPIO subsystem's perspective? Was the patch > >> approved, not approved, semi-approved? > > > > It just means we are not always entirely aligned, it's not like > > Alexandre and I have meetings on the side and decide what to > > say, it's just these mails. I do trust him, I wouldn't get mad if it > > had been merged just wanted some polishing when I could get > > it... > > In case of conflicting feedback between me and Linus, it goes without > saying that Linus' opinion should prevail. I am trying to help a bit > and take some of the burden off his shoulders, but have neither his > skill nor his experience (which shows when you compare our patch > reviews). So for important stuff it is a good idea to wait until both > of us give a ack - the most likely conflict scenario being that I give > a pass overlooking something that Linus will catch. Thanks for the clarification! Rafael -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Monday, November 17, 2014 01:28:54 PM Alexandre Courbot wrote: On Fri, Nov 14, 2014 at 5:58 PM, Linus Walleij linus.wall...@linaro.org wrote: On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote: With that change: Reviewed-by: Linus Walleij linus.wall...@linaro.org OK, made the changes and added your Reviewed-by. One semi-related question though. Alexandre ACKed the patch before, so what did that mean from the GPIO subsystem's perspective? Was the patch approved, not approved, semi-approved? It just means we are not always entirely aligned, it's not like Alexandre and I have meetings on the side and decide what to say, it's just these mails. I do trust him, I wouldn't get mad if it had been merged just wanted some polishing when I could get it... In case of conflicting feedback between me and Linus, it goes without saying that Linus' opinion should prevail. I am trying to help a bit and take some of the burden off his shoulders, but have neither his skill nor his experience (which shows when you compare our patch reviews). So for important stuff it is a good idea to wait until both of us give a ack - the most likely conflict scenario being that I give a pass overlooking something that Linus will catch. Thanks for the clarification! Rafael -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Fri, Nov 14, 2014 at 5:58 PM, Linus Walleij wrote: > On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki wrote: >> On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote: > >>> With that change: >>> Reviewed-by: Linus Walleij >> >> OK, made the changes and added your Reviewed-by. >> >> One semi-related question though. Alexandre ACKed the patch before, so >> what did that mean from the GPIO subsystem's perspective? Was the patch >> approved, not approved, semi-approved? > > It just means we are not always entirely aligned, it's not like > Alexandre and I have meetings on the side and decide what to > say, it's just these mails. I do trust him, I wouldn't get mad if it > had been merged just wanted some polishing when I could get > it... In case of conflicting feedback between me and Linus, it goes without saying that Linus' opinion should prevail. I am trying to help a bit and take some of the burden off his shoulders, but have neither his skill nor his experience (which shows when you compare our patch reviews). So for important stuff it is a good idea to wait until both of us give a ack - the most likely conflict scenario being that I give a pass overlooking something that Linus will catch. -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Fri, Nov 14, 2014 at 5:58 PM, Linus Walleij linus.wall...@linaro.org wrote: On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote: With that change: Reviewed-by: Linus Walleij linus.wall...@linaro.org OK, made the changes and added your Reviewed-by. One semi-related question though. Alexandre ACKed the patch before, so what did that mean from the GPIO subsystem's perspective? Was the patch approved, not approved, semi-approved? It just means we are not always entirely aligned, it's not like Alexandre and I have meetings on the side and decide what to say, it's just these mails. I do trust him, I wouldn't get mad if it had been merged just wanted some polishing when I could get it... In case of conflicting feedback between me and Linus, it goes without saying that Linus' opinion should prevail. I am trying to help a bit and take some of the burden off his shoulders, but have neither his skill nor his experience (which shows when you compare our patch reviews). So for important stuff it is a good idea to wait until both of us give a ack - the most likely conflict scenario being that I give a pass overlooking something that Linus will catch. -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Friday, November 14, 2014 09:58:41 AM Linus Walleij wrote: > On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki wrote: > > On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote: > > >> With that change: > >> Reviewed-by: Linus Walleij > > > > OK, made the changes and added your Reviewed-by. > > > > One semi-related question though. Alexandre ACKed the patch before, so > > what did that mean from the GPIO subsystem's perspective? Was the patch > > approved, not approved, semi-approved? > > It just means we are not always entirely aligned, it's not like > Alexandre and I have meetings on the side and decide what to > say, it's just these mails. I do trust him, I wouldn't get mad if it > had been merged just wanted some polishing when I could get > it... I see, thanks! Rafael -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki wrote: > On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote: >> With that change: >> Reviewed-by: Linus Walleij > > OK, made the changes and added your Reviewed-by. > > One semi-related question though. Alexandre ACKed the patch before, so > what did that mean from the GPIO subsystem's perspective? Was the patch > approved, not approved, semi-approved? It just means we are not always entirely aligned, it's not like Alexandre and I have meetings on the side and decide what to say, it's just these mails. I do trust him, I wouldn't get mad if it had been merged just wanted some polishing when I could get it... Yours, 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote: With that change: Reviewed-by: Linus Walleij linus.wall...@linaro.org OK, made the changes and added your Reviewed-by. One semi-related question though. Alexandre ACKed the patch before, so what did that mean from the GPIO subsystem's perspective? Was the patch approved, not approved, semi-approved? It just means we are not always entirely aligned, it's not like Alexandre and I have meetings on the side and decide what to say, it's just these mails. I do trust him, I wouldn't get mad if it had been merged just wanted some polishing when I could get it... Yours, 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Friday, November 14, 2014 09:58:41 AM Linus Walleij wrote: On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote: With that change: Reviewed-by: Linus Walleij linus.wall...@linaro.org OK, made the changes and added your Reviewed-by. One semi-related question though. Alexandre ACKed the patch before, so what did that mean from the GPIO subsystem's perspective? Was the patch approved, not approved, semi-approved? It just means we are not always entirely aligned, it's not like Alexandre and I have meetings on the side and decide what to say, it's just these mails. I do trust him, I wouldn't get mad if it had been merged just wanted some polishing when I could get it... I see, thanks! Rafael -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote:
> On Sat, Oct 25, 2014 at 12:05 AM, Rafael J. Wysocki
> wrote:
>
> > From: Rafael J. Wysocki
> >
> > Provide a way for device drivers using GPIOs described by ACPI
> > GpioIo resources in _CRS to tell the GPIO subsystem what names
> > (connection IDs) to associate with specific GPIO pins defined
> > in there.
> >
> > To do that, a driver needs to define a mapping table as a
> > NULL-terminated array of struct acpi_gpio_mapping objects
> > that each contain a name, a pointer to an array of pin data
> > (struct acpi_gpio_params) objects and the size of that array.
> >
> > Each struct acpi_gpio_params object consists of three fields,
> > crs_entry_index, pin_index, active_low, representing the index of
>
> I prefer that you call the second thing "line_index" rather than
> "pin_index". Not all GPIOs in the world are tied to physical pins.
> Also it is easy to confuse stuff with the pin control terminology
> if it's called "pin".
>
> > the target GpioIo()/GpioInt() resource in _CRS starting from zero,
> > the index of the target pin in that resource starting from zero,
> > and the active-low flag for that pin, respectively.
> >
> > Next, the mapping table needs to be passed as the second argument to
> > acpi_dev_add_driver_gpios() that will register it with the ACPI device
> > object pointed to by its first argument. That object must represent
> > the ACPI namespace node containing the _CRS object referred to by the
> > GPIO mapping. That should be done in the driver's .probe() routine.
> >
> > On removal, the driver should unregister its GPIO mapping table
> > by calling acpi_dev_remove_driver_gpios() on the ACPI device
> > object where that table was previously registered.
> >
> > Included are fixes from Mika Westerberg.
> >
> > Signed-off-by: Rafael J. Wysocki
>
> And "pin" is mentioned several times in the commit message.
> I prefer that we talk about "lines".
>
> (...)
>
> > +struct acpi_gpio_params {
> > + unsigned int crs_entry_index;
> > + unsigned int pin_index;
>
> So line_index;
>
> > + bool active_low;
> > +};
>
> With that change:
> Reviewed-by: Linus Walleij
OK, made the changes and added your Reviewed-by.
One semi-related question though. Alexandre ACKed the patch before, so
what did that mean from the GPIO subsystem's perspective? Was the patch
approved, not approved, semi-approved?
Rafael
--
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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Sat, Oct 25, 2014 at 12:05 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Provide a way for device drivers using GPIOs described by ACPI
> GpioIo resources in _CRS to tell the GPIO subsystem what names
> (connection IDs) to associate with specific GPIO pins defined
> in there.
>
> To do that, a driver needs to define a mapping table as a
> NULL-terminated array of struct acpi_gpio_mapping objects
> that each contain a name, a pointer to an array of pin data
> (struct acpi_gpio_params) objects and the size of that array.
>
> Each struct acpi_gpio_params object consists of three fields,
> crs_entry_index, pin_index, active_low, representing the index of
I prefer that you call the second thing "line_index" rather than
"pin_index". Not all GPIOs in the world are tied to physical pins.
Also it is easy to confuse stuff with the pin control terminology
if it's called "pin".
> the target GpioIo()/GpioInt() resource in _CRS starting from zero,
> the index of the target pin in that resource starting from zero,
> and the active-low flag for that pin, respectively.
>
> Next, the mapping table needs to be passed as the second argument to
> acpi_dev_add_driver_gpios() that will register it with the ACPI device
> object pointed to by its first argument. That object must represent
> the ACPI namespace node containing the _CRS object referred to by the
> GPIO mapping. That should be done in the driver's .probe() routine.
>
> On removal, the driver should unregister its GPIO mapping table
> by calling acpi_dev_remove_driver_gpios() on the ACPI device
> object where that table was previously registered.
>
> Included are fixes from Mika Westerberg.
>
> Signed-off-by: Rafael J. Wysocki
And "pin" is mentioned several times in the commit message.
I prefer that we talk about "lines".
(...)
> +struct acpi_gpio_params {
> + unsigned int crs_entry_index;
> + unsigned int pin_index;
So line_index;
> + bool active_low;
> +};
With that change:
Reviewed-by: Linus Walleij
Yours,
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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Sat, Oct 25, 2014 at 12:05 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.
To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of pin data
(struct acpi_gpio_params) objects and the size of that array.
Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, pin_index, active_low, representing the index of
I prefer that you call the second thing line_index rather than
pin_index. Not all GPIOs in the world are tied to physical pins.
Also it is easy to confuse stuff with the pin control terminology
if it's called pin.
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target pin in that resource starting from zero,
and the active-low flag for that pin, respectively.
Next, the mapping table needs to be passed as the second argument to
acpi_dev_add_driver_gpios() that will register it with the ACPI device
object pointed to by its first argument. That object must represent
the ACPI namespace node containing the _CRS object referred to by the
GPIO mapping. That should be done in the driver's .probe() routine.
On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.
Included are fixes from Mika Westerberg.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
And pin is mentioned several times in the commit message.
I prefer that we talk about lines.
(...)
+struct acpi_gpio_params {
+ unsigned int crs_entry_index;
+ unsigned int pin_index;
So line_index;
+ bool active_low;
+};
With that change:
Reviewed-by: Linus Walleij linus.wall...@linaro.org
Yours,
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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote:
On Sat, Oct 25, 2014 at 12:05 AM, Rafael J. Wysocki r...@rjwysocki.net
wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.
To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of pin data
(struct acpi_gpio_params) objects and the size of that array.
Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, pin_index, active_low, representing the index of
I prefer that you call the second thing line_index rather than
pin_index. Not all GPIOs in the world are tied to physical pins.
Also it is easy to confuse stuff with the pin control terminology
if it's called pin.
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target pin in that resource starting from zero,
and the active-low flag for that pin, respectively.
Next, the mapping table needs to be passed as the second argument to
acpi_dev_add_driver_gpios() that will register it with the ACPI device
object pointed to by its first argument. That object must represent
the ACPI namespace node containing the _CRS object referred to by the
GPIO mapping. That should be done in the driver's .probe() routine.
On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.
Included are fixes from Mika Westerberg.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
And pin is mentioned several times in the commit message.
I prefer that we talk about lines.
(...)
+struct acpi_gpio_params {
+ unsigned int crs_entry_index;
+ unsigned int pin_index;
So line_index;
+ bool active_low;
+};
With that change:
Reviewed-by: Linus Walleij linus.wall...@linaro.org
OK, made the changes and added your Reviewed-by.
One semi-related question though. Alexandre ACKed the patch before, so
what did that mean from the GPIO subsystem's perspective? Was the patch
approved, not approved, semi-approved?
Rafael
--
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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Thu, Oct 30, 2014 at 01:45:09AM +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > Subject: ACPI / GPIO: Document ACPI GPIO mappings API > > Document the previously introduced method that can be used by device > drivers to provide the GPIO subsystem with mappings between GPIO names > (connection IDs) and GpioIo()/GpioInt() resources in _CRS. > > Signed-off-by: Rafael J. Wysocki Looks really good to me, Reviewed-by: Mika Westerberg -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Thu, Oct 30, 2014 at 01:45:09AM +0100, Rafael J. Wysocki wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com Subject: ACPI / GPIO: Document ACPI GPIO mappings API Document the previously introduced method that can be used by device drivers to provide the GPIO subsystem with mappings between GPIO names (connection IDs) and GpioIo()/GpioInt() resources in _CRS. Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Looks really good to me, Reviewed-by: Mika Westerberg mika.westerb...@linux.intel.com -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Tuesday, October 28, 2014 01:11:50 PM Alexandre Courbot wrote:
> On Tue, Oct 28, 2014 at 7:34 AM, Rafael J. Wysocki wrote:
> > On Monday, October 27, 2014 02:21:23 PM Alexandre Courbot wrote:
[cut]
> > Yes, I'm going to provide documentation.
> >
> > One question, though. We're already adding gpio-properties.txt under
> > Documentation/acpi/ containing analogous information for _DSD-based
> > mappings. I thought I'd add a section to that file and a short paragraph
> > pointing to it into consumer.txt, would that work?
>
> Definitely yes, since this is ACPI-specific. Thanks!
OK, so what about this (on top of the device-properties branch at
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=device-properties):
---
From: Rafael J. Wysocki
Subject: ACPI / GPIO: Document ACPI GPIO mappings API
Document the previously introduced method that can be used by device
drivers to provide the GPIO subsystem with mappings between GPIO names
(connection IDs) and GpioIo()/GpioInt() resources in _CRS.
Signed-off-by: Rafael J. Wysocki
---
Documentation/acpi/gpio-properties.txt | 44 +
Documentation/gpio/consumer.txt| 18 +
2 files changed, 62 insertions(+)
Index: linux-pm/Documentation/acpi/gpio-properties.txt
===
--- linux-pm.orig/Documentation/acpi/gpio-properties.txt
+++ linux-pm/Documentation/acpi/gpio-properties.txt
@@ -50,3 +50,47 @@ it to 1 marks the GPIO as active low.
In our Bluetooth example the "reset-gpio" refers to the second GpioIo()
resource, second pin in that resource with the GPIO number of 31.
+
+ACPI GPIO Mappings Provided by Drivers
+--
+
+There are systems in which the ACPI tables do not contain _DSD but provide _CRS
+with GpioIo()/GpioInt() resources and device drivers still need to work with
+them.
+
+In those cases ACPI device identification objects, _HID, _CID, _CLS, _SUB,
_HRV,
+available to the driver can be used to identify the device and that is supposed
+to be sufficient to determine the meaning and purpose of all of the GPIO pins
+listed by the GpioIo()/GpioInt() resources returned by _CRS. In other words,
+the driver is supposed to know what to use the GpioIo()/GpioInt() resources for
+once it has identified the device. Having done that, it can simply assign
names
+to the GPIO pins it is going to use and provide the GPIO subsystem with a
+mapping between those names and the ACPI GPIO resources corresponding to them.
+
+To do that, the driver needs to define a mapping table as a NULL-terminated
+array of struct acpi_gpio_mapping objects that each contain a name, a pointer
+to an array of pin data (struct acpi_gpio_params) objects and the size of that
+array. Each struct acpi_gpio_params object consists of three fields,
+crs_entry_index, pin_index, active_low, representing the index of the target
+GpioIo()/GpioInt() resource in _CRS starting from zero, the index of the target
+pin in that resource starting from zero, and the active-low flag for that pin,
+respectively, in analogy with the _DSD GPIO property format specified above.
+
+For the example Bluetooth device discussed previously the data structures in
+question would look like this:
+
+static const struct acpi_gpio_params reset_gpio = { 1, 1, false };
+static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false };
+
+static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
+ { "reset-gpio", _gpio, 1 },
+ { "shutdown-gpio", _gpio, 1 },
+ { },
+};
+
+Next, the mapping table needs to be passed as the second argument to
+acpi_dev_add_driver_gpios() that will register it with the ACPI device object
+pointed to by its first argument. That should be done in the driver's .probe()
+routine. On removal, the driver should unregister its GPIO mapping table by
+calling acpi_dev_remove_driver_gpios() on the ACPI device object where that
+table was previously registered.
Index: linux-pm/Documentation/gpio/consumer.txt
===
--- linux-pm.orig/Documentation/gpio/consumer.txt
+++ linux-pm/Documentation/gpio/consumer.txt
@@ -219,6 +219,24 @@ part of the IRQ interface, e.g. IRQF_TRI
capabilities.
+GPIOs and ACPI
+==
+
+On ACPI systems, GPIOs are described by GpioIo()/GpioInt() resources listed by
+the _CRS configuration objects of devices. Those resources do not provide
+connection IDs (names) for GPIOs, so it is necessary to use an additional
+mechanism for this purpose.
+
+Systems compliant with ACPI 5.1 or newer may provide a _DSD configuration
object
+which, among other things, may be used to provide connection IDs for specific
+GPIOs described by the GpioIo()/GpioInt() resources in _CRS. If that is the
+case, it will be handled by the GPIO subsystem automatically. However, if the
+_DSD is not present, the mappings between GpioIo()/GpioInt() resources
Re: [PATCH] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Tuesday, October 28, 2014 01:11:50 PM Alexandre Courbot wrote:
On Tue, Oct 28, 2014 at 7:34 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, October 27, 2014 02:21:23 PM Alexandre Courbot wrote:
[cut]
Yes, I'm going to provide documentation.
One question, though. We're already adding gpio-properties.txt under
Documentation/acpi/ containing analogous information for _DSD-based
mappings. I thought I'd add a section to that file and a short paragraph
pointing to it into consumer.txt, would that work?
Definitely yes, since this is ACPI-specific. Thanks!
OK, so what about this (on top of the device-properties branch at
http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/log/?h=device-properties):
---
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Subject: ACPI / GPIO: Document ACPI GPIO mappings API
Document the previously introduced method that can be used by device
drivers to provide the GPIO subsystem with mappings between GPIO names
(connection IDs) and GpioIo()/GpioInt() resources in _CRS.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
Documentation/acpi/gpio-properties.txt | 44 +
Documentation/gpio/consumer.txt| 18 +
2 files changed, 62 insertions(+)
Index: linux-pm/Documentation/acpi/gpio-properties.txt
===
--- linux-pm.orig/Documentation/acpi/gpio-properties.txt
+++ linux-pm/Documentation/acpi/gpio-properties.txt
@@ -50,3 +50,47 @@ it to 1 marks the GPIO as active low.
In our Bluetooth example the reset-gpio refers to the second GpioIo()
resource, second pin in that resource with the GPIO number of 31.
+
+ACPI GPIO Mappings Provided by Drivers
+--
+
+There are systems in which the ACPI tables do not contain _DSD but provide _CRS
+with GpioIo()/GpioInt() resources and device drivers still need to work with
+them.
+
+In those cases ACPI device identification objects, _HID, _CID, _CLS, _SUB,
_HRV,
+available to the driver can be used to identify the device and that is supposed
+to be sufficient to determine the meaning and purpose of all of the GPIO pins
+listed by the GpioIo()/GpioInt() resources returned by _CRS. In other words,
+the driver is supposed to know what to use the GpioIo()/GpioInt() resources for
+once it has identified the device. Having done that, it can simply assign
names
+to the GPIO pins it is going to use and provide the GPIO subsystem with a
+mapping between those names and the ACPI GPIO resources corresponding to them.
+
+To do that, the driver needs to define a mapping table as a NULL-terminated
+array of struct acpi_gpio_mapping objects that each contain a name, a pointer
+to an array of pin data (struct acpi_gpio_params) objects and the size of that
+array. Each struct acpi_gpio_params object consists of three fields,
+crs_entry_index, pin_index, active_low, representing the index of the target
+GpioIo()/GpioInt() resource in _CRS starting from zero, the index of the target
+pin in that resource starting from zero, and the active-low flag for that pin,
+respectively, in analogy with the _DSD GPIO property format specified above.
+
+For the example Bluetooth device discussed previously the data structures in
+question would look like this:
+
+static const struct acpi_gpio_params reset_gpio = { 1, 1, false };
+static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false };
+
+static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
+ { reset-gpio, reset_gpio, 1 },
+ { shutdown-gpio, shutdown_gpio, 1 },
+ { },
+};
+
+Next, the mapping table needs to be passed as the second argument to
+acpi_dev_add_driver_gpios() that will register it with the ACPI device object
+pointed to by its first argument. That should be done in the driver's .probe()
+routine. On removal, the driver should unregister its GPIO mapping table by
+calling acpi_dev_remove_driver_gpios() on the ACPI device object where that
+table was previously registered.
Index: linux-pm/Documentation/gpio/consumer.txt
===
--- linux-pm.orig/Documentation/gpio/consumer.txt
+++ linux-pm/Documentation/gpio/consumer.txt
@@ -219,6 +219,24 @@ part of the IRQ interface, e.g. IRQF_TRI
capabilities.
+GPIOs and ACPI
+==
+
+On ACPI systems, GPIOs are described by GpioIo()/GpioInt() resources listed by
+the _CRS configuration objects of devices. Those resources do not provide
+connection IDs (names) for GPIOs, so it is necessary to use an additional
+mechanism for this purpose.
+
+Systems compliant with ACPI 5.1 or newer may provide a _DSD configuration
object
+which, among other things, may be used to provide connection IDs for specific
+GPIOs described by the GpioIo()/GpioInt() resources in _CRS. If that is the
+case, it will be handled by the GPIO subsystem automatically. However, if the
+_DSD is not
Re: [PATCH] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Tue, Oct 28, 2014 at 7:34 AM, Rafael J. Wysocki wrote: > On Monday, October 27, 2014 02:21:23 PM Alexandre Courbot wrote: >> On Sat, Oct 25, 2014 at 7:05 AM, Rafael J. Wysocki >> wrote: >> > From: Rafael J. Wysocki >> > >> > Provide a way for device drivers using GPIOs described by ACPI >> > GpioIo resources in _CRS to tell the GPIO subsystem what names >> > (connection IDs) to associate with specific GPIO pins defined >> > in there. >> > >> > To do that, a driver needs to define a mapping table as a >> > NULL-terminated array of struct acpi_gpio_mapping objects >> > that each contain a name, a pointer to an array of pin data >> > (struct acpi_gpio_params) objects and the size of that array. >> > >> > Each struct acpi_gpio_params object consists of three fields, >> > crs_entry_index, pin_index, active_low, representing the index of >> > the target GpioIo()/GpioInt() resource in _CRS starting from zero, >> > the index of the target pin in that resource starting from zero, >> > and the active-low flag for that pin, respectively. >> > >> > Next, the mapping table needs to be passed as the second argument to >> > acpi_dev_add_driver_gpios() that will register it with the ACPI device >> > object pointed to by its first argument. That object must represent >> > the ACPI namespace node containing the _CRS object referred to by the >> > GPIO mapping. That should be done in the driver's .probe() routine. >> > >> > On removal, the driver should unregister its GPIO mapping table >> > by calling acpi_dev_remove_driver_gpios() on the ACPI device >> > object where that table was previously registered. >> > >> > Included are fixes from Mika Westerberg. >> >> Acked-by: Alexandre Courbot >> >> As we discussed already, this is a great idea. The only thing that is >> missing is a paragraph in Documentation/gpio/consumer.txt with an >> explanation of the global mechanism and a simple example to illustrate >> how and when this should be used. > > Yes, I'm going to provide documentation. > > One question, though. We're already adding gpio-properties.txt under > Documentation/acpi/ containing analogous information for _DSD-based > mappings. I thought I'd add a section to that file and a short paragraph > pointing to it into consumer.txt, would that work? Definitely yes, since this is ACPI-specific. 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Monday, October 27, 2014 02:21:23 PM Alexandre Courbot wrote: > On Sat, Oct 25, 2014 at 7:05 AM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Provide a way for device drivers using GPIOs described by ACPI > > GpioIo resources in _CRS to tell the GPIO subsystem what names > > (connection IDs) to associate with specific GPIO pins defined > > in there. > > > > To do that, a driver needs to define a mapping table as a > > NULL-terminated array of struct acpi_gpio_mapping objects > > that each contain a name, a pointer to an array of pin data > > (struct acpi_gpio_params) objects and the size of that array. > > > > Each struct acpi_gpio_params object consists of three fields, > > crs_entry_index, pin_index, active_low, representing the index of > > the target GpioIo()/GpioInt() resource in _CRS starting from zero, > > the index of the target pin in that resource starting from zero, > > and the active-low flag for that pin, respectively. > > > > Next, the mapping table needs to be passed as the second argument to > > acpi_dev_add_driver_gpios() that will register it with the ACPI device > > object pointed to by its first argument. That object must represent > > the ACPI namespace node containing the _CRS object referred to by the > > GPIO mapping. That should be done in the driver's .probe() routine. > > > > On removal, the driver should unregister its GPIO mapping table > > by calling acpi_dev_remove_driver_gpios() on the ACPI device > > object where that table was previously registered. > > > > Included are fixes from Mika Westerberg. > > Acked-by: Alexandre Courbot > > As we discussed already, this is a great idea. The only thing that is > missing is a paragraph in Documentation/gpio/consumer.txt with an > explanation of the global mechanism and a simple example to illustrate > how and when this should be used. Yes, I'm going to provide documentation. One question, though. We're already adding gpio-properties.txt under Documentation/acpi/ containing analogous information for _DSD-based mappings. I thought I'd add a section to that file and a short paragraph pointing to it into consumer.txt, would that work? Rafael -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Monday, October 27, 2014 02:21:23 PM Alexandre Courbot wrote: On Sat, Oct 25, 2014 at 7:05 AM, Rafael J. Wysocki r...@rjwysocki.net wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com Provide a way for device drivers using GPIOs described by ACPI GpioIo resources in _CRS to tell the GPIO subsystem what names (connection IDs) to associate with specific GPIO pins defined in there. To do that, a driver needs to define a mapping table as a NULL-terminated array of struct acpi_gpio_mapping objects that each contain a name, a pointer to an array of pin data (struct acpi_gpio_params) objects and the size of that array. Each struct acpi_gpio_params object consists of three fields, crs_entry_index, pin_index, active_low, representing the index of the target GpioIo()/GpioInt() resource in _CRS starting from zero, the index of the target pin in that resource starting from zero, and the active-low flag for that pin, respectively. Next, the mapping table needs to be passed as the second argument to acpi_dev_add_driver_gpios() that will register it with the ACPI device object pointed to by its first argument. That object must represent the ACPI namespace node containing the _CRS object referred to by the GPIO mapping. That should be done in the driver's .probe() routine. On removal, the driver should unregister its GPIO mapping table by calling acpi_dev_remove_driver_gpios() on the ACPI device object where that table was previously registered. Included are fixes from Mika Westerberg. Acked-by: Alexandre Courbot acour...@nvidia.com As we discussed already, this is a great idea. The only thing that is missing is a paragraph in Documentation/gpio/consumer.txt with an explanation of the global mechanism and a simple example to illustrate how and when this should be used. Yes, I'm going to provide documentation. One question, though. We're already adding gpio-properties.txt under Documentation/acpi/ containing analogous information for _DSD-based mappings. I thought I'd add a section to that file and a short paragraph pointing to it into consumer.txt, would that work? Rafael -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Tue, Oct 28, 2014 at 7:34 AM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, October 27, 2014 02:21:23 PM Alexandre Courbot wrote: On Sat, Oct 25, 2014 at 7:05 AM, Rafael J. Wysocki r...@rjwysocki.net wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com Provide a way for device drivers using GPIOs described by ACPI GpioIo resources in _CRS to tell the GPIO subsystem what names (connection IDs) to associate with specific GPIO pins defined in there. To do that, a driver needs to define a mapping table as a NULL-terminated array of struct acpi_gpio_mapping objects that each contain a name, a pointer to an array of pin data (struct acpi_gpio_params) objects and the size of that array. Each struct acpi_gpio_params object consists of three fields, crs_entry_index, pin_index, active_low, representing the index of the target GpioIo()/GpioInt() resource in _CRS starting from zero, the index of the target pin in that resource starting from zero, and the active-low flag for that pin, respectively. Next, the mapping table needs to be passed as the second argument to acpi_dev_add_driver_gpios() that will register it with the ACPI device object pointed to by its first argument. That object must represent the ACPI namespace node containing the _CRS object referred to by the GPIO mapping. That should be done in the driver's .probe() routine. On removal, the driver should unregister its GPIO mapping table by calling acpi_dev_remove_driver_gpios() on the ACPI device object where that table was previously registered. Included are fixes from Mika Westerberg. Acked-by: Alexandre Courbot acour...@nvidia.com As we discussed already, this is a great idea. The only thing that is missing is a paragraph in Documentation/gpio/consumer.txt with an explanation of the global mechanism and a simple example to illustrate how and when this should be used. Yes, I'm going to provide documentation. One question, though. We're already adding gpio-properties.txt under Documentation/acpi/ containing analogous information for _DSD-based mappings. I thought I'd add a section to that file and a short paragraph pointing to it into consumer.txt, would that work? Definitely yes, since this is ACPI-specific. 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Sat, Oct 25, 2014 at 7:05 AM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Provide a way for device drivers using GPIOs described by ACPI > GpioIo resources in _CRS to tell the GPIO subsystem what names > (connection IDs) to associate with specific GPIO pins defined > in there. > > To do that, a driver needs to define a mapping table as a > NULL-terminated array of struct acpi_gpio_mapping objects > that each contain a name, a pointer to an array of pin data > (struct acpi_gpio_params) objects and the size of that array. > > Each struct acpi_gpio_params object consists of three fields, > crs_entry_index, pin_index, active_low, representing the index of > the target GpioIo()/GpioInt() resource in _CRS starting from zero, > the index of the target pin in that resource starting from zero, > and the active-low flag for that pin, respectively. > > Next, the mapping table needs to be passed as the second argument to > acpi_dev_add_driver_gpios() that will register it with the ACPI device > object pointed to by its first argument. That object must represent > the ACPI namespace node containing the _CRS object referred to by the > GPIO mapping. That should be done in the driver's .probe() routine. > > On removal, the driver should unregister its GPIO mapping table > by calling acpi_dev_remove_driver_gpios() on the ACPI device > object where that table was previously registered. > > Included are fixes from Mika Westerberg. Acked-by: Alexandre Courbot As we discussed already, this is a great idea. The only thing that is missing is a paragraph in Documentation/gpio/consumer.txt with an explanation of the global mechanism and a simple example to illustrate how and when this should be used. -- 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] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
On Sat, Oct 25, 2014 at 7:05 AM, Rafael J. Wysocki r...@rjwysocki.net wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com Provide a way for device drivers using GPIOs described by ACPI GpioIo resources in _CRS to tell the GPIO subsystem what names (connection IDs) to associate with specific GPIO pins defined in there. To do that, a driver needs to define a mapping table as a NULL-terminated array of struct acpi_gpio_mapping objects that each contain a name, a pointer to an array of pin data (struct acpi_gpio_params) objects and the size of that array. Each struct acpi_gpio_params object consists of three fields, crs_entry_index, pin_index, active_low, representing the index of the target GpioIo()/GpioInt() resource in _CRS starting from zero, the index of the target pin in that resource starting from zero, and the active-low flag for that pin, respectively. Next, the mapping table needs to be passed as the second argument to acpi_dev_add_driver_gpios() that will register it with the ACPI device object pointed to by its first argument. That object must represent the ACPI namespace node containing the _CRS object referred to by the GPIO mapping. That should be done in the driver's .probe() routine. On removal, the driver should unregister its GPIO mapping table by calling acpi_dev_remove_driver_gpios() on the ACPI device object where that table was previously registered. Included are fixes from Mika Westerberg. Acked-by: Alexandre Courbot acour...@nvidia.com As we discussed already, this is a great idea. The only thing that is missing is a paragraph in Documentation/gpio/consumer.txt with an explanation of the global mechanism and a simple example to illustrate how and when this should be used. -- 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/
[PATCH] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
From: Rafael J. Wysocki
Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.
To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of pin data
(struct acpi_gpio_params) objects and the size of that array.
Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, pin_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target pin in that resource starting from zero,
and the active-low flag for that pin, respectively.
Next, the mapping table needs to be passed as the second argument to
acpi_dev_add_driver_gpios() that will register it with the ACPI device
object pointed to by its first argument. That object must represent
the ACPI namespace node containing the _CRS object referred to by the
GPIO mapping. That should be done in the driver's .probe() routine.
On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.
Included are fixes from Mika Westerberg.
Signed-off-by: Rafael J. Wysocki
---
On top of the device-properties branch of the linux-pm.git tree at kernel.org.
---
drivers/gpio/gpiolib-acpi.c | 43 +--
include/acpi/acpi_bus.h |3 +++
include/linux/acpi.h| 30 ++
3 files changed, 74 insertions(+), 2 deletions(-)
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -345,6 +345,8 @@ struct acpi_device_data {
const union acpi_object *of_compatible;
};
+struct acpi_gpio_mapping;
+
/* Device */
struct acpi_device {
int device_type;
@@ -366,6 +368,7 @@ struct acpi_device {
struct acpi_scan_handler *handler;
struct acpi_hotplug_context *hp;
struct acpi_driver *driver;
+ const struct acpi_gpio_mapping *driver_gpios;
void *driver_data;
struct device dev;
unsigned int physical_node_count;
Index: linux-pm/include/linux/acpi.h
===
--- linux-pm.orig/include/linux/acpi.h
+++ linux-pm/include/linux/acpi.h
@@ -672,6 +672,36 @@ do {
\
#endif
#endif
+struct acpi_gpio_params {
+ unsigned int crs_entry_index;
+ unsigned int pin_index;
+ bool active_low;
+};
+
+struct acpi_gpio_mapping {
+ const char *name;
+ const struct acpi_gpio_params *data;
+ unsigned int size;
+};
+
+#if defined(CONFIG_ACPI) && defined(CONFIG_GPIOLIB)
+int acpi_dev_add_driver_gpios(struct acpi_device *adev,
+ const struct acpi_gpio_mapping *gpios);
+
+static inline void acpi_dev_remove_driver_gpios(struct acpi_device *adev)
+{
+ if (adev)
+ adev->driver_gpios = NULL;
+}
+#else
+static inline int acpi_dev_add_driver_gpios(struct acpi_device *adev,
+ const struct acpi_gpio_mapping *gpios)
+{
+ return -ENXIO;
+}
+static inline void acpi_dev_remove_driver_gpios(struct acpi_device *adev) {}
+#endif
+
/* Device properties */
#define MAX_ACPI_REFERENCE_ARGS8
Index: linux-pm/drivers/gpio/gpiolib-acpi.c
===
--- linux-pm.orig/drivers/gpio/gpiolib-acpi.c
+++ linux-pm/drivers/gpio/gpiolib-acpi.c
@@ -287,6 +287,41 @@ void acpi_gpiochip_free_interrupts(struc
}
}
+int acpi_dev_add_driver_gpios(struct acpi_device *adev,
+ const struct acpi_gpio_mapping *gpios)
+{
+ if (adev && gpios) {
+ adev->driver_gpios = gpios;
+ return 0;
+ }
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(acpi_dev_add_driver_gpios);
+
+static bool acpi_get_driver_gpio_data(struct acpi_device *adev,
+ const char *name, int index,
+ struct acpi_reference_args *args)
+{
+ const struct acpi_gpio_mapping *gm;
+
+ if (!adev->driver_gpios)
+ return false;
+
+ for (gm = adev->driver_gpios; gm->name; gm++)
+ if (!strcmp(name, gm->name) && gm->data && index < gm->size) {
+ const struct acpi_gpio_params *par = gm->data + index;
+
+ args->adev = adev;
+ args->args[0] = par->crs_entry_index;
+ args->args[1] = par->pin_index;
+ args->args[2] = par->active_low;
+ args->nargs = 3;
+
[PATCH] ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.
To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of pin data
(struct acpi_gpio_params) objects and the size of that array.
Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, pin_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target pin in that resource starting from zero,
and the active-low flag for that pin, respectively.
Next, the mapping table needs to be passed as the second argument to
acpi_dev_add_driver_gpios() that will register it with the ACPI device
object pointed to by its first argument. That object must represent
the ACPI namespace node containing the _CRS object referred to by the
GPIO mapping. That should be done in the driver's .probe() routine.
On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.
Included are fixes from Mika Westerberg.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
On top of the device-properties branch of the linux-pm.git tree at kernel.org.
---
drivers/gpio/gpiolib-acpi.c | 43 +--
include/acpi/acpi_bus.h |3 +++
include/linux/acpi.h| 30 ++
3 files changed, 74 insertions(+), 2 deletions(-)
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -345,6 +345,8 @@ struct acpi_device_data {
const union acpi_object *of_compatible;
};
+struct acpi_gpio_mapping;
+
/* Device */
struct acpi_device {
int device_type;
@@ -366,6 +368,7 @@ struct acpi_device {
struct acpi_scan_handler *handler;
struct acpi_hotplug_context *hp;
struct acpi_driver *driver;
+ const struct acpi_gpio_mapping *driver_gpios;
void *driver_data;
struct device dev;
unsigned int physical_node_count;
Index: linux-pm/include/linux/acpi.h
===
--- linux-pm.orig/include/linux/acpi.h
+++ linux-pm/include/linux/acpi.h
@@ -672,6 +672,36 @@ do {
\
#endif
#endif
+struct acpi_gpio_params {
+ unsigned int crs_entry_index;
+ unsigned int pin_index;
+ bool active_low;
+};
+
+struct acpi_gpio_mapping {
+ const char *name;
+ const struct acpi_gpio_params *data;
+ unsigned int size;
+};
+
+#if defined(CONFIG_ACPI) defined(CONFIG_GPIOLIB)
+int acpi_dev_add_driver_gpios(struct acpi_device *adev,
+ const struct acpi_gpio_mapping *gpios);
+
+static inline void acpi_dev_remove_driver_gpios(struct acpi_device *adev)
+{
+ if (adev)
+ adev-driver_gpios = NULL;
+}
+#else
+static inline int acpi_dev_add_driver_gpios(struct acpi_device *adev,
+ const struct acpi_gpio_mapping *gpios)
+{
+ return -ENXIO;
+}
+static inline void acpi_dev_remove_driver_gpios(struct acpi_device *adev) {}
+#endif
+
/* Device properties */
#define MAX_ACPI_REFERENCE_ARGS8
Index: linux-pm/drivers/gpio/gpiolib-acpi.c
===
--- linux-pm.orig/drivers/gpio/gpiolib-acpi.c
+++ linux-pm/drivers/gpio/gpiolib-acpi.c
@@ -287,6 +287,41 @@ void acpi_gpiochip_free_interrupts(struc
}
}
+int acpi_dev_add_driver_gpios(struct acpi_device *adev,
+ const struct acpi_gpio_mapping *gpios)
+{
+ if (adev gpios) {
+ adev-driver_gpios = gpios;
+ return 0;
+ }
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(acpi_dev_add_driver_gpios);
+
+static bool acpi_get_driver_gpio_data(struct acpi_device *adev,
+ const char *name, int index,
+ struct acpi_reference_args *args)
+{
+ const struct acpi_gpio_mapping *gm;
+
+ if (!adev-driver_gpios)
+ return false;
+
+ for (gm = adev-driver_gpios; gm-name; gm++)
+ if (!strcmp(name, gm-name) gm-data index gm-size) {
+ const struct acpi_gpio_params *par = gm-data + index;
+
+ args-adev = adev;
+ args-args[0] = par-crs_entry_index;
+ args-args[1] = par-pin_index;
+ args-args[2] = par-active_low;
+
