2018-09-25 15:08:48 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2012-11-30 19:37:36 +08:00
|
|
|
/*
|
|
|
|
* ACPI helpers for GPIO API
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012, Intel Corporation
|
|
|
|
* Authors: Mathias Nyman <mathias.nyman@linux.intel.com>
|
|
|
|
* Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
|
|
*/
|
|
|
|
|
2019-08-28 04:28:35 +08:00
|
|
|
#include <linux/dmi.h>
|
2012-11-30 19:37:36 +08:00
|
|
|
#include <linux/errno.h>
|
2013-10-10 16:01:08 +08:00
|
|
|
#include <linux/gpio/consumer.h>
|
2014-01-08 18:40:56 +08:00
|
|
|
#include <linux/gpio/driver.h>
|
2016-10-03 16:40:03 +08:00
|
|
|
#include <linux/gpio/machine.h>
|
2012-11-30 19:37:36 +08:00
|
|
|
#include <linux/export.h>
|
|
|
|
#include <linux/acpi.h>
|
2013-01-28 22:23:10 +08:00
|
|
|
#include <linux/interrupt.h>
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
#include <linux/mutex.h>
|
2014-11-03 19:01:32 +08:00
|
|
|
#include <linux/pinctrl/pinctrl.h>
|
2012-11-30 19:37:36 +08:00
|
|
|
|
2014-01-08 18:40:56 +08:00
|
|
|
#include "gpiolib.h"
|
2019-07-30 18:43:36 +08:00
|
|
|
#include "gpiolib-acpi.h"
|
2014-01-08 18:40:56 +08:00
|
|
|
|
2019-08-28 04:28:35 +08:00
|
|
|
static int run_edge_events_on_boot = -1;
|
|
|
|
module_param(run_edge_events_on_boot, int, 0444);
|
|
|
|
MODULE_PARM_DESC(run_edge_events_on_boot,
|
|
|
|
"Run edge _AEI event-handlers at boot: 0=no, 1=yes, -1=auto");
|
|
|
|
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
static char *ignore_wake;
|
|
|
|
module_param(ignore_wake, charp, 0444);
|
|
|
|
MODULE_PARM_DESC(ignore_wake,
|
|
|
|
"controller@pin combos on which to ignore the ACPI wake flag "
|
|
|
|
"ignore_wake=controller@pin[,controller@pin[,...]]");
|
|
|
|
|
|
|
|
struct acpi_gpiolib_dmi_quirk {
|
|
|
|
bool no_edge_events_on_boot;
|
|
|
|
char *ignore_wake;
|
|
|
|
};
|
2020-01-06 00:03:57 +08:00
|
|
|
|
2018-11-29 00:57:55 +08:00
|
|
|
/**
|
|
|
|
* struct acpi_gpio_event - ACPI GPIO event handler data
|
|
|
|
*
|
|
|
|
* @node: list-entry of the events list of the struct acpi_gpio_chip
|
|
|
|
* @handle: handle of ACPI method to execute when the IRQ triggers
|
2019-03-30 05:33:45 +08:00
|
|
|
* @handler: handler function to pass to request_irq() when requesting the IRQ
|
|
|
|
* @pin: GPIO pin number on the struct gpio_chip
|
|
|
|
* @irq: Linux IRQ number for the event, for request_irq() / free_irq()
|
|
|
|
* @irqflags: flags to pass to request_irq() when requesting the IRQ
|
2018-11-29 00:57:55 +08:00
|
|
|
* @irq_is_wake: If the ACPI flags indicate the IRQ is a wakeup source
|
2019-03-30 05:33:45 +08:00
|
|
|
* @irq_requested:True if request_irq() has been done
|
|
|
|
* @desc: struct gpio_desc for the GPIO pin for this event
|
2018-11-29 00:57:55 +08:00
|
|
|
*/
|
2014-03-10 20:54:52 +08:00
|
|
|
struct acpi_gpio_event {
|
2013-04-09 21:57:25 +08:00
|
|
|
struct list_head node;
|
2014-03-10 20:54:52 +08:00
|
|
|
acpi_handle handle;
|
2018-11-29 00:57:55 +08:00
|
|
|
irq_handler_t handler;
|
2013-04-09 21:57:25 +08:00
|
|
|
unsigned int pin;
|
|
|
|
unsigned int irq;
|
2018-11-29 00:57:55 +08:00
|
|
|
unsigned long irqflags;
|
|
|
|
bool irq_is_wake;
|
|
|
|
bool irq_requested;
|
2014-08-20 01:06:08 +08:00
|
|
|
struct gpio_desc *desc;
|
2013-04-09 21:57:25 +08:00
|
|
|
};
|
|
|
|
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
struct acpi_gpio_connection {
|
|
|
|
struct list_head node;
|
2014-08-20 01:06:08 +08:00
|
|
|
unsigned int pin;
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
struct gpio_desc *desc;
|
|
|
|
};
|
|
|
|
|
2014-03-10 20:54:51 +08:00
|
|
|
struct acpi_gpio_chip {
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
/*
|
|
|
|
* ACPICA requires that the first field of the context parameter
|
|
|
|
* passed to acpi_install_address_space_handler() is large enough
|
|
|
|
* to hold struct acpi_connection_info.
|
|
|
|
*/
|
|
|
|
struct acpi_connection_info conn_info;
|
|
|
|
struct list_head conns;
|
|
|
|
struct mutex conn_lock;
|
2014-03-10 20:54:51 +08:00
|
|
|
struct gpio_chip *chip;
|
2014-03-10 20:54:52 +08:00
|
|
|
struct list_head events;
|
2018-08-14 22:07:03 +08:00
|
|
|
struct list_head deferred_req_irqs_list_entry;
|
2014-03-10 20:54:51 +08:00
|
|
|
};
|
|
|
|
|
2018-08-14 22:07:03 +08:00
|
|
|
/*
|
2019-03-30 05:33:45 +08:00
|
|
|
* For GPIO chips which call acpi_gpiochip_request_interrupts() before late_init
|
2018-11-29 00:57:55 +08:00
|
|
|
* (so builtin drivers) we register the ACPI GpioInt IRQ handlers from a
|
2019-03-30 05:33:45 +08:00
|
|
|
* late_initcall_sync() handler, so that other builtin drivers can register their
|
|
|
|
* OpRegions before the event handlers can run. This list contains GPIO chips
|
2018-11-29 00:57:55 +08:00
|
|
|
* for which the acpi_gpiochip_request_irqs() call has been deferred.
|
2018-08-14 22:07:03 +08:00
|
|
|
*/
|
|
|
|
static DEFINE_MUTEX(acpi_gpio_deferred_req_irqs_lock);
|
|
|
|
static LIST_HEAD(acpi_gpio_deferred_req_irqs_list);
|
|
|
|
static bool acpi_gpio_deferred_req_irqs_done;
|
gpiolib-acpi: make sure we trigger edge events at least once on boot
On some systems using edge triggered ACPI Event Interrupts, the initial
state at boot is not setup by the firmware, instead relying on the edge
irq event handler running at least once to setup the initial state.
2 known examples of this are:
1) The Surface 3 has its _LID state controlled by an ACPI operation region
triggered by a GPIO event:
OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
Field (GPOR, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Shared, PullNone, 0x0000, 0x0000, IoRestrictionNone,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x004C
}
),
HELD, 1
}
Method (_E4C, 0, Serialized) // _Exx: Edge-Triggered GPE
{
If ((HELD == One))
{
^^LID.LIDB = One
}
Else
{
^^LID.LIDB = Zero
Notify (LID, 0x80) // Status Change
}
Notify (^^PCI0.SPI1.NTRG, One) // Device Check
}
Currently, the state of LIDB is wrong until the user actually closes or
open the cover. We need to trigger the GPIO event once to update the
internal ACPI state.
Coincidentally, this also enables the Surface 2 integrated HID sensor hub
which also requires an ACPI gpio operation region to start initialization.
2) Various Bay Trail based tablets come with an external USB mux and
TI T1210B USB phy to enable USB gadget mode. The mux is controlled by a
GPIO which is controlled by an edge triggered ACPI Event Interrupt which
monitors the micro-USB ID pin.
When the tablet is connected to a PC (or no cable is plugged in), the ID
pin is high and the tablet should be in gadget mode. But the GPIO
controlling the mux is initialized by the firmware so that the USB data
lines are muxed to the host controller.
This means that if the user wants to use gadget mode, the user needs to
first plug in a host-cable to force the ID pin low and then unplug it
and connect the tablet to a PC, to get the ACPI event handler to run and
switch the mux to device mode,
This commit fixes both by running the event-handler once on boot.
Note that the running of the event-handler is done from a late_initcall,
this is done because the handler AML code may rely on OperationRegions
registered by other builtin drivers. This avoids errors like these:
[ 0.133026] ACPI Error: No handler for Region [XSCG] ((____ptrval____)) [GenericSerialBus] (20180531/evregion-132)
[ 0.133036] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20180531/exfldio-265)
[ 0.133046] ACPI Error: Method parse/execution failed \_SB.GPO2._E12, AE_NOT_EXIST (20180531/psparse-516)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
[hdegoede: Document BYT USB mux reliance on initial trigger]
[hdegoede: Run event handler from a late_initcall, rather then immediately]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-07-12 23:25:06 +08:00
|
|
|
|
2012-11-30 19:37:36 +08:00
|
|
|
static int acpi_gpiochip_find(struct gpio_chip *gc, void *data)
|
|
|
|
{
|
2021-10-14 21:47:56 +08:00
|
|
|
return gc->parent && device_match_acpi_handle(gc->parent, data);
|
2012-11-30 19:37:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2013-10-10 16:01:08 +08:00
|
|
|
* acpi_get_gpiod() - Translate ACPI GPIO pin to GPIO descriptor usable with GPIO API
|
2012-11-30 19:37:36 +08:00
|
|
|
* @path: ACPI GPIO controller full path name, (e.g. "\\_SB.GPO1")
|
|
|
|
* @pin: ACPI GPIO pin number (0-based, controller-relative)
|
|
|
|
*
|
2015-06-10 21:05:05 +08:00
|
|
|
* Return: GPIO descriptor to use with Linux generic GPIO API, or ERR_PTR
|
|
|
|
* error value. Specifically returns %-EPROBE_DEFER if the referenced GPIO
|
2019-03-30 05:33:45 +08:00
|
|
|
* controller does not have GPIO chip registered at the moment. This is to
|
2015-06-10 21:05:05 +08:00
|
|
|
* support probe deferral.
|
2012-11-30 19:37:36 +08:00
|
|
|
*/
|
2013-10-10 16:01:08 +08:00
|
|
|
static struct gpio_desc *acpi_get_gpiod(char *path, int pin)
|
2012-11-30 19:37:36 +08:00
|
|
|
{
|
|
|
|
struct gpio_chip *chip;
|
|
|
|
acpi_handle handle;
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
status = acpi_get_handle(NULL, path, &handle);
|
|
|
|
if (ACPI_FAILURE(status))
|
2013-10-10 16:01:08 +08:00
|
|
|
return ERR_PTR(-ENODEV);
|
2012-11-30 19:37:36 +08:00
|
|
|
|
|
|
|
chip = gpiochip_find(handle, acpi_gpiochip_find);
|
|
|
|
if (!chip)
|
2015-06-10 21:05:05 +08:00
|
|
|
return ERR_PTR(-EPROBE_DEFER);
|
2012-11-30 19:37:36 +08:00
|
|
|
|
2017-11-27 21:54:42 +08:00
|
|
|
return gpiochip_get_desc(chip, pin);
|
2012-11-30 19:37:36 +08:00
|
|
|
}
|
2013-01-28 22:23:10 +08:00
|
|
|
|
2021-06-04 06:40:04 +08:00
|
|
|
/**
|
|
|
|
* acpi_get_and_request_gpiod - Translate ACPI GPIO pin to GPIO descriptor and
|
|
|
|
* hold a refcount to the GPIO device.
|
|
|
|
* @path: ACPI GPIO controller full path name, (e.g. "\\_SB.GPO1")
|
|
|
|
* @pin: ACPI GPIO pin number (0-based, controller-relative)
|
|
|
|
* @label: Label to pass to gpiod_request()
|
|
|
|
*
|
|
|
|
* This function is a simple pass-through to acpi_get_gpiod(), except that
|
|
|
|
* as it is intended for use outside of the GPIO layer (in a similar fashion to
|
|
|
|
* gpiod_get_index() for example) it also holds a reference to the GPIO device.
|
|
|
|
*/
|
|
|
|
struct gpio_desc *acpi_get_and_request_gpiod(char *path, int pin, char *label)
|
|
|
|
{
|
|
|
|
struct gpio_desc *gpio;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
gpio = acpi_get_gpiod(path, pin);
|
|
|
|
if (IS_ERR(gpio))
|
|
|
|
return gpio;
|
|
|
|
|
|
|
|
ret = gpiod_request(gpio, label);
|
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
|
|
|
return gpio;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_get_and_request_gpiod);
|
|
|
|
|
2013-01-28 22:23:10 +08:00
|
|
|
static irqreturn_t acpi_gpio_irq_handler(int irq, void *data)
|
|
|
|
{
|
2014-03-10 20:54:53 +08:00
|
|
|
struct acpi_gpio_event *event = data;
|
2013-01-28 22:23:10 +08:00
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
acpi_evaluate_object(event->handle, NULL, NULL, NULL);
|
2013-01-28 22:23:10 +08:00
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
2013-04-09 21:57:25 +08:00
|
|
|
static irqreturn_t acpi_gpio_irq_handler_evt(int irq, void *data)
|
|
|
|
{
|
2014-03-10 20:54:52 +08:00
|
|
|
struct acpi_gpio_event *event = data;
|
2013-04-09 21:57:25 +08:00
|
|
|
|
2014-03-10 20:54:52 +08:00
|
|
|
acpi_execute_simple_method(event->handle, NULL, event->pin);
|
2013-04-09 21:57:25 +08:00
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
2014-03-10 20:54:51 +08:00
|
|
|
static void acpi_gpio_chip_dh(acpi_handle handle, void *data)
|
2013-04-09 21:57:25 +08:00
|
|
|
{
|
|
|
|
/* The address of this function is used as a key. */
|
|
|
|
}
|
|
|
|
|
2017-05-24 01:03:24 +08:00
|
|
|
bool acpi_gpio_get_irq_resource(struct acpi_resource *ares,
|
|
|
|
struct acpi_resource_gpio **agpio)
|
|
|
|
{
|
|
|
|
struct acpi_resource_gpio *gpio;
|
|
|
|
|
|
|
|
if (ares->type != ACPI_RESOURCE_TYPE_GPIO)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
gpio = &ares->data.gpio;
|
|
|
|
if (gpio->connection_type != ACPI_RESOURCE_GPIO_TYPE_INT)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
*agpio = gpio;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_gpio_get_irq_resource);
|
|
|
|
|
2021-06-04 06:40:05 +08:00
|
|
|
/**
|
|
|
|
* acpi_gpio_get_io_resource - Fetch details of an ACPI resource if it is a GPIO
|
|
|
|
* I/O resource or return False if not.
|
|
|
|
* @ares: Pointer to the ACPI resource to fetch
|
|
|
|
* @agpio: Pointer to a &struct acpi_resource_gpio to store the output pointer
|
|
|
|
*/
|
|
|
|
bool acpi_gpio_get_io_resource(struct acpi_resource *ares,
|
|
|
|
struct acpi_resource_gpio **agpio)
|
|
|
|
{
|
|
|
|
struct acpi_resource_gpio *gpio;
|
|
|
|
|
|
|
|
if (ares->type != ACPI_RESOURCE_TYPE_GPIO)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
gpio = &ares->data.gpio;
|
|
|
|
if (gpio->connection_type != ACPI_RESOURCE_GPIO_TYPE_IO)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
*agpio = gpio;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_gpio_get_io_resource);
|
|
|
|
|
2018-11-29 00:57:55 +08:00
|
|
|
static void acpi_gpiochip_request_irq(struct acpi_gpio_chip *acpi_gpio,
|
|
|
|
struct acpi_gpio_event *event)
|
|
|
|
{
|
2021-11-23 18:18:37 +08:00
|
|
|
struct device *parent = acpi_gpio->chip->parent;
|
2018-11-29 00:57:55 +08:00
|
|
|
int ret, value;
|
|
|
|
|
|
|
|
ret = request_threaded_irq(event->irq, NULL, event->handler,
|
2021-02-23 16:35:58 +08:00
|
|
|
event->irqflags | IRQF_ONESHOT, "ACPI:Event", event);
|
2018-11-29 00:57:55 +08:00
|
|
|
if (ret) {
|
2021-11-23 18:18:37 +08:00
|
|
|
dev_err(parent, "Failed to setup interrupt handler for %d\n", event->irq);
|
2018-11-29 00:57:55 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (event->irq_is_wake)
|
|
|
|
enable_irq_wake(event->irq);
|
|
|
|
|
|
|
|
event->irq_requested = true;
|
|
|
|
|
|
|
|
/* Make sure we trigger the initial state of edge-triggered IRQs */
|
2019-08-28 04:28:35 +08:00
|
|
|
if (run_edge_events_on_boot &&
|
|
|
|
(event->irqflags & (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING))) {
|
|
|
|
value = gpiod_get_raw_value_cansleep(event->desc);
|
|
|
|
if (((event->irqflags & IRQF_TRIGGER_RISING) && value == 1) ||
|
|
|
|
((event->irqflags & IRQF_TRIGGER_FALLING) && value == 0))
|
|
|
|
event->handler(event->irq, event);
|
|
|
|
}
|
2018-11-29 00:57:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_gpiochip_request_irqs(struct acpi_gpio_chip *acpi_gpio)
|
|
|
|
{
|
|
|
|
struct acpi_gpio_event *event;
|
|
|
|
|
|
|
|
list_for_each_entry(event, &acpi_gpio->events, node)
|
|
|
|
acpi_gpiochip_request_irq(acpi_gpio, event);
|
|
|
|
}
|
|
|
|
|
2020-11-10 04:53:27 +08:00
|
|
|
static enum gpiod_flags
|
2020-10-02 01:12:12 +08:00
|
|
|
acpi_gpio_to_gpiod_flags(const struct acpi_resource_gpio *agpio, int polarity)
|
2020-11-10 04:53:27 +08:00
|
|
|
{
|
2020-11-10 04:53:28 +08:00
|
|
|
/* GpioInt() implies input configuration */
|
|
|
|
if (agpio->connection_type == ACPI_RESOURCE_GPIO_TYPE_INT)
|
|
|
|
return GPIOD_IN;
|
|
|
|
|
2020-11-10 04:53:27 +08:00
|
|
|
switch (agpio->io_restriction) {
|
|
|
|
case ACPI_IO_RESTRICT_INPUT:
|
|
|
|
return GPIOD_IN;
|
|
|
|
case ACPI_IO_RESTRICT_OUTPUT:
|
|
|
|
/*
|
|
|
|
* ACPI GPIO resources don't contain an initial value for the
|
|
|
|
* GPIO. Therefore we deduce that value from the pull field
|
2020-10-02 01:12:12 +08:00
|
|
|
* and the polarity instead. If the pin is pulled up we assume
|
|
|
|
* default to be high, if it is pulled down we assume default
|
|
|
|
* to be low, otherwise we leave pin untouched. For active low
|
|
|
|
* polarity values will be switched. See also
|
|
|
|
* Documentation/firmware-guide/acpi/gpio-properties.rst.
|
2020-11-10 04:53:27 +08:00
|
|
|
*/
|
|
|
|
switch (agpio->pin_config) {
|
|
|
|
case ACPI_PIN_CONFIG_PULLUP:
|
2020-10-02 01:12:12 +08:00
|
|
|
return polarity == GPIO_ACTIVE_LOW ? GPIOD_OUT_LOW : GPIOD_OUT_HIGH;
|
2020-11-10 04:53:27 +08:00
|
|
|
case ACPI_PIN_CONFIG_PULLDOWN:
|
2020-10-02 01:12:12 +08:00
|
|
|
return polarity == GPIO_ACTIVE_LOW ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
|
2020-11-10 04:53:27 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2020-12-09 22:17:24 +08:00
|
|
|
break;
|
2020-11-10 04:53:27 +08:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Assume that the BIOS has configured the direction and pull
|
|
|
|
* accordingly.
|
|
|
|
*/
|
|
|
|
return GPIOD_ASIS;
|
|
|
|
}
|
|
|
|
|
2020-11-12 05:35:33 +08:00
|
|
|
static struct gpio_desc *acpi_request_own_gpiod(struct gpio_chip *chip,
|
|
|
|
struct acpi_resource_gpio *agpio,
|
|
|
|
unsigned int index,
|
|
|
|
const char *label)
|
|
|
|
{
|
|
|
|
int polarity = GPIO_ACTIVE_HIGH;
|
|
|
|
enum gpiod_flags flags = acpi_gpio_to_gpiod_flags(agpio, polarity);
|
|
|
|
unsigned int pin = agpio->pin_table[index];
|
|
|
|
struct gpio_desc *desc;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
desc = gpiochip_request_own_desc(chip, pin, label, polarity, flags);
|
|
|
|
if (IS_ERR(desc))
|
|
|
|
return desc;
|
|
|
|
|
|
|
|
ret = gpio_set_debounce_timeout(desc, agpio->debounce_timeout);
|
|
|
|
if (ret)
|
2021-08-16 18:41:19 +08:00
|
|
|
dev_warn(chip->parent,
|
|
|
|
"Failed to set debounce-timeout for pin 0x%04X, err %d\n",
|
|
|
|
pin, ret);
|
2020-11-12 05:35:33 +08:00
|
|
|
|
2021-08-16 18:41:19 +08:00
|
|
|
return desc;
|
2020-11-12 05:35:33 +08:00
|
|
|
}
|
|
|
|
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
static bool acpi_gpio_in_ignore_list(const char *controller_in, int pin_in)
|
|
|
|
{
|
|
|
|
const char *controller, *pin_str;
|
|
|
|
int len, pin;
|
|
|
|
char *endp;
|
|
|
|
|
|
|
|
controller = ignore_wake;
|
|
|
|
while (controller) {
|
|
|
|
pin_str = strchr(controller, '@');
|
|
|
|
if (!pin_str)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
len = pin_str - controller;
|
|
|
|
if (len == strlen(controller_in) &&
|
|
|
|
strncmp(controller, controller_in, len) == 0) {
|
|
|
|
pin = simple_strtoul(pin_str + 1, &endp, 10);
|
|
|
|
if (*endp != 0 && *endp != ',')
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
if (pin == pin_in)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
controller = strchr(controller, ',');
|
|
|
|
if (controller)
|
|
|
|
controller++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
err:
|
2021-11-23 18:18:37 +08:00
|
|
|
pr_err_once("Error: Invalid value for gpiolib_acpi.ignore_wake: %s\n", ignore_wake);
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool acpi_gpio_irq_is_wake(struct device *parent,
|
|
|
|
struct acpi_resource_gpio *agpio)
|
|
|
|
{
|
|
|
|
int pin = agpio->pin_table[0];
|
|
|
|
|
|
|
|
if (agpio->wake_capable != ACPI_WAKE_CAPABLE)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (acpi_gpio_in_ignore_list(dev_name(parent), pin)) {
|
|
|
|
dev_info(parent, "Ignoring wakeup on pin %d\n", pin);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-11-14 18:26:00 +08:00
|
|
|
/* Always returns AE_OK so that we keep looping over the resources */
|
2018-11-29 00:57:55 +08:00
|
|
|
static acpi_status acpi_gpiochip_alloc_event(struct acpi_resource *ares,
|
|
|
|
void *context)
|
2013-01-28 22:23:10 +08:00
|
|
|
{
|
2014-03-10 20:54:53 +08:00
|
|
|
struct acpi_gpio_chip *acpi_gpio = context;
|
2014-03-10 20:54:51 +08:00
|
|
|
struct gpio_chip *chip = acpi_gpio->chip;
|
2014-03-10 20:54:53 +08:00
|
|
|
struct acpi_resource_gpio *agpio;
|
2013-04-09 21:57:25 +08:00
|
|
|
acpi_handle handle, evt_handle;
|
2014-03-10 20:54:53 +08:00
|
|
|
struct acpi_gpio_event *event;
|
|
|
|
irq_handler_t handler = NULL;
|
|
|
|
struct gpio_desc *desc;
|
2018-11-29 00:57:55 +08:00
|
|
|
int ret, pin, irq;
|
2013-01-28 22:23:10 +08:00
|
|
|
|
2017-05-24 01:03:24 +08:00
|
|
|
if (!acpi_gpio_get_irq_resource(ares, &agpio))
|
2014-03-10 20:54:53 +08:00
|
|
|
return AE_OK;
|
2013-01-28 22:23:10 +08:00
|
|
|
|
2015-11-04 16:56:26 +08:00
|
|
|
handle = ACPI_HANDLE(chip->parent);
|
2014-03-10 20:54:53 +08:00
|
|
|
pin = agpio->pin_table[0];
|
|
|
|
|
|
|
|
if (pin <= 255) {
|
|
|
|
char ev_name[5];
|
gpio: acpi: work around false-positive -Wstring-overflow warning
gcc-7 notices that the pin_table is an array of 16-bit numbers,
but fails to take the following range check into account:
drivers/gpio/gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt':
drivers/gpio/gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=]
sprintf(ev_name, "_%c%02X",
^~~~
drivers/gpio/gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535]
sprintf(ev_name, "_%c%02X",
^~~~~~~~~
drivers/gpio/gpiolib-acpi.c:206:3: note: 'sprintf' output between 5 and 7 bytes into a destination of size 5
sprintf(ev_name, "_%c%02X",
^~~~~~~~~~~~~~~~~~~~~~~~~~~
agpio->triggering == ACPI_EDGE_SENSITIVE ? 'E' : 'L',
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pin);
~~~~
As suggested by Andy, this changes the format string to have a fixed length.
Since modifying the range check did not help, I also opened a bug against
gcc, see link below.
Fixes: 0d1c28a449c6 ("gpiolib-acpi: Add ACPI5 event model support to gpio.")
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patchwork.kernel.org/patch/9840801/
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82123
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-09-06 23:47:45 +08:00
|
|
|
sprintf(ev_name, "_%c%02hhX",
|
2014-03-10 20:54:53 +08:00
|
|
|
agpio->triggering == ACPI_EDGE_SENSITIVE ? 'E' : 'L',
|
|
|
|
pin);
|
|
|
|
if (ACPI_SUCCESS(acpi_get_handle(handle, ev_name, &evt_handle)))
|
|
|
|
handler = acpi_gpio_irq_handler;
|
|
|
|
}
|
|
|
|
if (!handler) {
|
|
|
|
if (ACPI_SUCCESS(acpi_get_handle(handle, "_EVT", &evt_handle)))
|
|
|
|
handler = acpi_gpio_irq_handler_evt;
|
|
|
|
}
|
|
|
|
if (!handler)
|
2017-06-23 15:26:13 +08:00
|
|
|
return AE_OK;
|
2013-01-28 22:23:10 +08:00
|
|
|
|
2020-11-12 05:35:33 +08:00
|
|
|
desc = acpi_request_own_gpiod(chip, agpio, 0, "ACPI:Event");
|
2014-03-10 20:54:53 +08:00
|
|
|
if (IS_ERR(desc)) {
|
2019-11-14 18:25:59 +08:00
|
|
|
dev_err(chip->parent,
|
|
|
|
"Failed to request GPIO for pin 0x%04X, err %ld\n",
|
|
|
|
pin, PTR_ERR(desc));
|
2019-11-14 18:26:00 +08:00
|
|
|
return AE_OK;
|
2014-03-10 20:54:53 +08:00
|
|
|
}
|
2013-01-28 22:23:10 +08:00
|
|
|
|
2014-10-23 16:27:07 +08:00
|
|
|
ret = gpiochip_lock_as_irq(chip, pin);
|
2014-03-10 20:54:53 +08:00
|
|
|
if (ret) {
|
2019-11-14 18:25:59 +08:00
|
|
|
dev_err(chip->parent,
|
|
|
|
"Failed to lock GPIO pin 0x%04X as interrupt, err %d\n",
|
|
|
|
pin, ret);
|
2014-03-10 20:54:53 +08:00
|
|
|
goto fail_free_desc;
|
|
|
|
}
|
2013-01-28 22:23:10 +08:00
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
irq = gpiod_to_irq(desc);
|
|
|
|
if (irq < 0) {
|
2019-11-14 18:25:59 +08:00
|
|
|
dev_err(chip->parent,
|
|
|
|
"Failed to translate GPIO pin 0x%04X to IRQ, err %d\n",
|
|
|
|
pin, irq);
|
2014-03-10 20:54:53 +08:00
|
|
|
goto fail_unlock_irq;
|
|
|
|
}
|
2013-04-09 21:57:25 +08:00
|
|
|
|
2018-11-29 00:57:55 +08:00
|
|
|
event = kzalloc(sizeof(*event), GFP_KERNEL);
|
|
|
|
if (!event)
|
|
|
|
goto fail_unlock_irq;
|
|
|
|
|
|
|
|
event->irqflags = IRQF_ONESHOT;
|
2014-03-10 20:54:53 +08:00
|
|
|
if (agpio->triggering == ACPI_LEVEL_SENSITIVE) {
|
|
|
|
if (agpio->polarity == ACPI_ACTIVE_HIGH)
|
2018-11-29 00:57:55 +08:00
|
|
|
event->irqflags |= IRQF_TRIGGER_HIGH;
|
2014-03-10 20:54:53 +08:00
|
|
|
else
|
2018-11-29 00:57:55 +08:00
|
|
|
event->irqflags |= IRQF_TRIGGER_LOW;
|
2014-03-10 20:54:53 +08:00
|
|
|
} else {
|
|
|
|
switch (agpio->polarity) {
|
|
|
|
case ACPI_ACTIVE_HIGH:
|
2018-11-29 00:57:55 +08:00
|
|
|
event->irqflags |= IRQF_TRIGGER_RISING;
|
2014-03-10 20:54:53 +08:00
|
|
|
break;
|
|
|
|
case ACPI_ACTIVE_LOW:
|
2018-11-29 00:57:55 +08:00
|
|
|
event->irqflags |= IRQF_TRIGGER_FALLING;
|
2014-03-10 20:54:53 +08:00
|
|
|
break;
|
|
|
|
default:
|
2018-11-29 00:57:55 +08:00
|
|
|
event->irqflags |= IRQF_TRIGGER_RISING |
|
|
|
|
IRQF_TRIGGER_FALLING;
|
2014-03-10 20:54:53 +08:00
|
|
|
break;
|
2013-04-09 21:57:25 +08:00
|
|
|
}
|
2014-03-10 20:54:53 +08:00
|
|
|
}
|
2014-03-10 20:54:51 +08:00
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
event->handle = evt_handle;
|
2018-11-29 00:57:55 +08:00
|
|
|
event->handler = handler;
|
2014-03-10 20:54:53 +08:00
|
|
|
event->irq = irq;
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
event->irq_is_wake = acpi_gpio_irq_is_wake(chip->parent, agpio);
|
2014-03-10 20:54:53 +08:00
|
|
|
event->pin = pin;
|
2014-08-20 01:06:08 +08:00
|
|
|
event->desc = desc;
|
2013-04-09 21:57:25 +08:00
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
list_add_tail(&event->node, &acpi_gpio->events);
|
gpiolib-acpi: make sure we trigger edge events at least once on boot
On some systems using edge triggered ACPI Event Interrupts, the initial
state at boot is not setup by the firmware, instead relying on the edge
irq event handler running at least once to setup the initial state.
2 known examples of this are:
1) The Surface 3 has its _LID state controlled by an ACPI operation region
triggered by a GPIO event:
OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
Field (GPOR, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Shared, PullNone, 0x0000, 0x0000, IoRestrictionNone,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x004C
}
),
HELD, 1
}
Method (_E4C, 0, Serialized) // _Exx: Edge-Triggered GPE
{
If ((HELD == One))
{
^^LID.LIDB = One
}
Else
{
^^LID.LIDB = Zero
Notify (LID, 0x80) // Status Change
}
Notify (^^PCI0.SPI1.NTRG, One) // Device Check
}
Currently, the state of LIDB is wrong until the user actually closes or
open the cover. We need to trigger the GPIO event once to update the
internal ACPI state.
Coincidentally, this also enables the Surface 2 integrated HID sensor hub
which also requires an ACPI gpio operation region to start initialization.
2) Various Bay Trail based tablets come with an external USB mux and
TI T1210B USB phy to enable USB gadget mode. The mux is controlled by a
GPIO which is controlled by an edge triggered ACPI Event Interrupt which
monitors the micro-USB ID pin.
When the tablet is connected to a PC (or no cable is plugged in), the ID
pin is high and the tablet should be in gadget mode. But the GPIO
controlling the mux is initialized by the firmware so that the USB data
lines are muxed to the host controller.
This means that if the user wants to use gadget mode, the user needs to
first plug in a host-cable to force the ID pin low and then unplug it
and connect the tablet to a PC, to get the ACPI event handler to run and
switch the mux to device mode,
This commit fixes both by running the event-handler once on boot.
Note that the running of the event-handler is done from a late_initcall,
this is done because the handler AML code may rely on OperationRegions
registered by other builtin drivers. This avoids errors like these:
[ 0.133026] ACPI Error: No handler for Region [XSCG] ((____ptrval____)) [GenericSerialBus] (20180531/evregion-132)
[ 0.133036] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20180531/exfldio-265)
[ 0.133046] ACPI Error: Method parse/execution failed \_SB.GPO2._E12, AE_NOT_EXIST (20180531/psparse-516)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
[hdegoede: Document BYT USB mux reliance on initial trigger]
[hdegoede: Run event handler from a late_initcall, rather then immediately]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-07-12 23:25:06 +08:00
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
return AE_OK;
|
|
|
|
|
|
|
|
fail_unlock_irq:
|
2014-10-23 16:27:07 +08:00
|
|
|
gpiochip_unlock_as_irq(chip, pin);
|
2014-03-10 20:54:53 +08:00
|
|
|
fail_free_desc:
|
|
|
|
gpiochip_free_own_desc(desc);
|
|
|
|
|
2019-11-14 18:26:00 +08:00
|
|
|
return AE_OK;
|
2013-01-28 22:23:10 +08:00
|
|
|
}
|
2013-04-09 21:57:25 +08:00
|
|
|
|
2013-10-10 16:01:07 +08:00
|
|
|
/**
|
2014-03-10 20:54:53 +08:00
|
|
|
* acpi_gpiochip_request_interrupts() - Register isr for gpio chip ACPI events
|
2014-07-25 14:54:48 +08:00
|
|
|
* @chip: GPIO chip
|
2013-10-10 16:01:07 +08:00
|
|
|
*
|
2014-03-10 20:54:53 +08:00
|
|
|
* ACPI5 platforms can use GPIO signaled ACPI events. These GPIO interrupts are
|
|
|
|
* handled by ACPI event methods which need to be called from the GPIO
|
2019-03-30 05:33:45 +08:00
|
|
|
* chip's interrupt handler. acpi_gpiochip_request_interrupts() finds out which
|
|
|
|
* GPIO pins have ACPI event methods and assigns interrupt handlers that calls
|
|
|
|
* the ACPI event methods for those pins.
|
2014-03-10 20:54:53 +08:00
|
|
|
*/
|
2014-07-25 14:54:48 +08:00
|
|
|
void acpi_gpiochip_request_interrupts(struct gpio_chip *chip)
|
2014-03-10 20:54:53 +08:00
|
|
|
{
|
2014-07-25 14:54:48 +08:00
|
|
|
struct acpi_gpio_chip *acpi_gpio;
|
|
|
|
acpi_handle handle;
|
|
|
|
acpi_status status;
|
2018-08-14 22:07:03 +08:00
|
|
|
bool defer;
|
2014-07-25 14:54:48 +08:00
|
|
|
|
2015-11-04 16:56:26 +08:00
|
|
|
if (!chip->parent || !chip->to_irq)
|
2014-07-25 14:54:48 +08:00
|
|
|
return;
|
2014-03-10 20:54:53 +08:00
|
|
|
|
2015-11-04 16:56:26 +08:00
|
|
|
handle = ACPI_HANDLE(chip->parent);
|
2014-07-25 14:54:48 +08:00
|
|
|
if (!handle)
|
|
|
|
return;
|
|
|
|
|
|
|
|
status = acpi_get_data(handle, acpi_gpio_chip_dh, (void **)&acpi_gpio);
|
|
|
|
if (ACPI_FAILURE(status))
|
2014-03-10 20:54:53 +08:00
|
|
|
return;
|
|
|
|
|
2018-11-29 00:57:55 +08:00
|
|
|
acpi_walk_resources(handle, "_AEI",
|
|
|
|
acpi_gpiochip_alloc_event, acpi_gpio);
|
|
|
|
|
2018-08-14 22:07:03 +08:00
|
|
|
mutex_lock(&acpi_gpio_deferred_req_irqs_lock);
|
|
|
|
defer = !acpi_gpio_deferred_req_irqs_done;
|
|
|
|
if (defer)
|
|
|
|
list_add(&acpi_gpio->deferred_req_irqs_list_entry,
|
|
|
|
&acpi_gpio_deferred_req_irqs_list);
|
|
|
|
mutex_unlock(&acpi_gpio_deferred_req_irqs_lock);
|
|
|
|
|
|
|
|
if (defer)
|
|
|
|
return;
|
|
|
|
|
2018-11-29 00:57:55 +08:00
|
|
|
acpi_gpiochip_request_irqs(acpi_gpio);
|
2014-03-10 20:54:53 +08:00
|
|
|
}
|
2015-06-10 17:12:07 +08:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_gpiochip_request_interrupts);
|
2014-03-10 20:54:53 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_gpiochip_free_interrupts() - Free GPIO ACPI event interrupts.
|
2014-07-25 14:54:48 +08:00
|
|
|
* @chip: GPIO chip
|
2013-10-10 16:01:07 +08:00
|
|
|
*
|
2014-03-10 20:54:53 +08:00
|
|
|
* Free interrupts associated with GPIO ACPI event method for the given
|
|
|
|
* GPIO chip.
|
2013-10-10 16:01:07 +08:00
|
|
|
*/
|
2014-07-25 14:54:48 +08:00
|
|
|
void acpi_gpiochip_free_interrupts(struct gpio_chip *chip)
|
2013-10-10 16:01:07 +08:00
|
|
|
{
|
2014-07-25 14:54:48 +08:00
|
|
|
struct acpi_gpio_chip *acpi_gpio;
|
2014-03-10 20:54:52 +08:00
|
|
|
struct acpi_gpio_event *event, *ep;
|
2014-07-25 14:54:48 +08:00
|
|
|
acpi_handle handle;
|
|
|
|
acpi_status status;
|
|
|
|
|
2015-11-04 16:56:26 +08:00
|
|
|
if (!chip->parent || !chip->to_irq)
|
2014-07-25 14:54:48 +08:00
|
|
|
return;
|
2013-10-10 16:01:07 +08:00
|
|
|
|
2015-11-04 16:56:26 +08:00
|
|
|
handle = ACPI_HANDLE(chip->parent);
|
2014-07-25 14:54:48 +08:00
|
|
|
if (!handle)
|
|
|
|
return;
|
|
|
|
|
|
|
|
status = acpi_get_data(handle, acpi_gpio_chip_dh, (void **)&acpi_gpio);
|
|
|
|
if (ACPI_FAILURE(status))
|
2013-10-10 16:01:07 +08:00
|
|
|
return;
|
|
|
|
|
2018-08-14 22:07:03 +08:00
|
|
|
mutex_lock(&acpi_gpio_deferred_req_irqs_lock);
|
|
|
|
if (!list_empty(&acpi_gpio->deferred_req_irqs_list_entry))
|
|
|
|
list_del_init(&acpi_gpio->deferred_req_irqs_list_entry);
|
|
|
|
mutex_unlock(&acpi_gpio_deferred_req_irqs_lock);
|
|
|
|
|
2014-03-10 20:54:52 +08:00
|
|
|
list_for_each_entry_safe_reverse(event, ep, &acpi_gpio->events, node) {
|
2018-11-29 00:57:55 +08:00
|
|
|
if (event->irq_requested) {
|
|
|
|
if (event->irq_is_wake)
|
|
|
|
disable_irq_wake(event->irq);
|
|
|
|
|
|
|
|
free_irq(event->irq, event);
|
|
|
|
}
|
2017-03-24 18:08:47 +08:00
|
|
|
|
2014-10-23 16:27:07 +08:00
|
|
|
gpiochip_unlock_as_irq(chip, event->pin);
|
2018-11-29 00:57:56 +08:00
|
|
|
gpiochip_free_own_desc(event->desc);
|
2014-03-10 20:54:52 +08:00
|
|
|
list_del(&event->node);
|
|
|
|
kfree(event);
|
2013-10-10 16:01:07 +08:00
|
|
|
}
|
|
|
|
}
|
2015-06-10 17:12:07 +08:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_gpiochip_free_interrupts);
|
2013-10-10 16:01:07 +08:00
|
|
|
|
ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
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 line 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, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, 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
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 <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 06:39:41 +08:00
|
|
|
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);
|
|
|
|
|
2019-07-30 18:43:37 +08:00
|
|
|
void acpi_dev_remove_driver_gpios(struct acpi_device *adev)
|
|
|
|
{
|
|
|
|
if (adev)
|
|
|
|
adev->driver_gpios = NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_remove_driver_gpios);
|
|
|
|
|
2021-11-10 21:47:43 +08:00
|
|
|
static void acpi_dev_release_driver_gpios(void *adev)
|
2017-03-02 21:48:05 +08:00
|
|
|
{
|
2021-11-10 21:47:43 +08:00
|
|
|
acpi_dev_remove_driver_gpios(adev);
|
2017-03-02 21:48:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int devm_acpi_dev_add_driver_gpios(struct device *dev,
|
|
|
|
const struct acpi_gpio_mapping *gpios)
|
|
|
|
{
|
2021-11-10 21:47:43 +08:00
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
2017-03-02 21:48:05 +08:00
|
|
|
int ret;
|
|
|
|
|
2021-11-10 21:47:43 +08:00
|
|
|
ret = acpi_dev_add_driver_gpios(adev, gpios);
|
|
|
|
if (ret)
|
2017-03-02 21:48:05 +08:00
|
|
|
return ret;
|
2021-11-10 21:47:43 +08:00
|
|
|
|
|
|
|
return devm_add_action_or_reset(dev, acpi_dev_release_driver_gpios, adev);
|
2017-03-02 21:48:05 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(devm_acpi_dev_add_driver_gpios);
|
|
|
|
|
ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
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 line 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, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, 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
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 <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 06:39:41 +08:00
|
|
|
static bool acpi_get_driver_gpio_data(struct acpi_device *adev,
|
|
|
|
const char *name, int index,
|
2018-07-17 22:19:11 +08:00
|
|
|
struct fwnode_reference_args *args,
|
2017-11-10 21:40:32 +08:00
|
|
|
unsigned int *quirks)
|
ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
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 line 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, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, 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
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 <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 06:39:41 +08:00
|
|
|
{
|
|
|
|
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;
|
|
|
|
|
2018-07-17 22:19:11 +08:00
|
|
|
args->fwnode = acpi_fwnode_handle(adev);
|
ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
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 line 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, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, 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
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 <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 06:39:41 +08:00
|
|
|
args->args[0] = par->crs_entry_index;
|
|
|
|
args->args[1] = par->line_index;
|
|
|
|
args->args[2] = par->active_low;
|
|
|
|
args->nargs = 3;
|
2017-11-10 21:40:32 +08:00
|
|
|
|
|
|
|
*quirks = gm->quirks;
|
ACPI / GPIO: Driver GPIO mappings for ACPI GPIOs
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 line 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, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, 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
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 <acourbot@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-04 06:39:41 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-11-10 21:40:31 +08:00
|
|
|
static int
|
|
|
|
__acpi_gpio_update_gpiod_flags(enum gpiod_flags *flags, enum gpiod_flags update)
|
2017-05-24 01:03:23 +08:00
|
|
|
{
|
2019-01-01 04:55:21 +08:00
|
|
|
const enum gpiod_flags mask =
|
|
|
|
GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT |
|
|
|
|
GPIOD_FLAGS_BIT_DIR_VAL;
|
2017-05-24 01:03:23 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if the BIOS has IoRestriction with explicitly set direction
|
|
|
|
* and update @flags accordingly. Otherwise use whatever caller asked
|
|
|
|
* for.
|
|
|
|
*/
|
|
|
|
if (update & GPIOD_FLAGS_BIT_DIR_SET) {
|
|
|
|
enum gpiod_flags diff = *flags ^ update;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if caller supplied incompatible GPIO initialization
|
|
|
|
* flags.
|
|
|
|
*
|
|
|
|
* Return %-EINVAL to notify that firmware has different
|
|
|
|
* settings and we are going to use them.
|
|
|
|
*/
|
|
|
|
if (((*flags & GPIOD_FLAGS_BIT_DIR_SET) && (diff & GPIOD_FLAGS_BIT_DIR_OUT)) ||
|
|
|
|
((*flags & GPIOD_FLAGS_BIT_DIR_OUT) && (diff & GPIOD_FLAGS_BIT_DIR_VAL)))
|
|
|
|
ret = -EINVAL;
|
2019-01-01 04:55:21 +08:00
|
|
|
*flags = (*flags & ~mask) | (update & mask);
|
2017-05-24 01:03:23 +08:00
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-11-10 21:40:31 +08:00
|
|
|
int
|
|
|
|
acpi_gpio_update_gpiod_flags(enum gpiod_flags *flags, struct acpi_gpio_info *info)
|
|
|
|
{
|
|
|
|
struct device *dev = &info->adev->dev;
|
2017-11-10 21:40:33 +08:00
|
|
|
enum gpiod_flags old = *flags;
|
2017-11-10 21:40:31 +08:00
|
|
|
int ret;
|
|
|
|
|
2017-11-10 21:40:33 +08:00
|
|
|
ret = __acpi_gpio_update_gpiod_flags(&old, info->flags);
|
|
|
|
if (info->quirks & ACPI_GPIO_QUIRK_NO_IO_RESTRICTION) {
|
|
|
|
if (ret)
|
|
|
|
dev_warn(dev, FW_BUG "GPIO not in correct mode, fixing\n");
|
|
|
|
} else {
|
|
|
|
if (ret)
|
|
|
|
dev_dbg(dev, "Override GPIO initialization flags\n");
|
|
|
|
*flags = old;
|
|
|
|
}
|
2017-11-10 21:40:31 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-04-10 23:39:20 +08:00
|
|
|
int acpi_gpio_update_gpiod_lookup_flags(unsigned long *lookupflags,
|
|
|
|
struct acpi_gpio_info *info)
|
|
|
|
{
|
2019-04-10 23:39:21 +08:00
|
|
|
switch (info->pin_config) {
|
|
|
|
case ACPI_PIN_CONFIG_PULLUP:
|
|
|
|
*lookupflags |= GPIO_PULL_UP;
|
|
|
|
break;
|
|
|
|
case ACPI_PIN_CONFIG_PULLDOWN:
|
|
|
|
*lookupflags |= GPIO_PULL_DOWN;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-04-10 23:39:20 +08:00
|
|
|
if (info->polarity == GPIO_ACTIVE_LOW)
|
|
|
|
*lookupflags |= GPIO_ACTIVE_LOW;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-04-03 18:56:54 +08:00
|
|
|
struct acpi_gpio_lookup {
|
|
|
|
struct acpi_gpio_info info;
|
|
|
|
int index;
|
2020-11-10 04:53:30 +08:00
|
|
|
u16 pin_index;
|
2015-08-27 10:41:33 +08:00
|
|
|
bool active_low;
|
2013-10-10 16:01:08 +08:00
|
|
|
struct gpio_desc *desc;
|
2013-04-03 18:56:54 +08:00
|
|
|
int n;
|
|
|
|
};
|
|
|
|
|
2016-10-03 16:40:03 +08:00
|
|
|
static int acpi_populate_gpio_lookup(struct acpi_resource *ares, void *data)
|
2013-04-03 18:56:54 +08:00
|
|
|
{
|
|
|
|
struct acpi_gpio_lookup *lookup = data;
|
|
|
|
|
|
|
|
if (ares->type != ACPI_RESOURCE_TYPE_GPIO)
|
|
|
|
return 1;
|
|
|
|
|
2019-02-07 04:49:46 +08:00
|
|
|
if (!lookup->desc) {
|
2013-04-03 18:56:54 +08:00
|
|
|
const struct acpi_resource_gpio *agpio = &ares->data.gpio;
|
2019-02-07 04:49:46 +08:00
|
|
|
bool gpioint = agpio->connection_type == ACPI_RESOURCE_GPIO_TYPE_INT;
|
2021-02-26 00:33:18 +08:00
|
|
|
struct gpio_desc *desc;
|
2020-11-10 04:53:30 +08:00
|
|
|
u16 pin_index;
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
|
2019-02-07 04:49:46 +08:00
|
|
|
if (lookup->info.quirks & ACPI_GPIO_QUIRK_ONLY_GPIOIO && gpioint)
|
|
|
|
lookup->index++;
|
|
|
|
|
|
|
|
if (lookup->n++ != lookup->index)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
pin_index = lookup->pin_index;
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
if (pin_index >= agpio->pin_table_length)
|
|
|
|
return 1;
|
2013-04-03 18:56:54 +08:00
|
|
|
|
2021-02-26 00:33:18 +08:00
|
|
|
if (lookup->info.quirks & ACPI_GPIO_QUIRK_ABSOLUTE_NUMBER)
|
|
|
|
desc = gpio_to_desc(agpio->pin_table[pin_index]);
|
|
|
|
else
|
|
|
|
desc = acpi_get_gpiod(agpio->resource_source.string_ptr,
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
agpio->pin_table[pin_index]);
|
2021-02-26 00:33:18 +08:00
|
|
|
lookup->desc = desc;
|
2019-04-10 23:39:21 +08:00
|
|
|
lookup->info.pin_config = agpio->pin_config;
|
2020-11-10 04:53:26 +08:00
|
|
|
lookup->info.debounce = agpio->debounce_timeout;
|
2019-02-07 04:49:46 +08:00
|
|
|
lookup->info.gpioint = gpioint;
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
|
|
|
|
/*
|
2017-01-04 01:01:18 +08:00
|
|
|
* Polarity and triggering are only specified for GpioInt
|
|
|
|
* resource.
|
2015-12-24 06:25:34 +08:00
|
|
|
* Note: we expect here:
|
|
|
|
* - ACPI_ACTIVE_LOW == GPIO_ACTIVE_LOW
|
|
|
|
* - ACPI_ACTIVE_HIGH == GPIO_ACTIVE_HIGH
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
*/
|
2015-12-24 06:25:34 +08:00
|
|
|
if (lookup->info.gpioint) {
|
|
|
|
lookup->info.polarity = agpio->polarity;
|
|
|
|
lookup->info.triggering = agpio->triggering;
|
2017-05-24 01:03:23 +08:00
|
|
|
} else {
|
2017-11-10 21:40:28 +08:00
|
|
|
lookup->info.polarity = lookup->active_low;
|
2015-12-24 06:25:34 +08:00
|
|
|
}
|
2020-11-10 04:53:28 +08:00
|
|
|
|
|
|
|
lookup->info.flags = acpi_gpio_to_gpiod_flags(agpio, lookup->info.polarity);
|
2013-04-03 18:56:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2015-08-27 10:41:33 +08:00
|
|
|
static int acpi_gpio_resource_lookup(struct acpi_gpio_lookup *lookup,
|
|
|
|
struct acpi_gpio_info *info)
|
|
|
|
{
|
2017-11-10 21:40:30 +08:00
|
|
|
struct acpi_device *adev = lookup->info.adev;
|
2015-08-27 10:41:33 +08:00
|
|
|
struct list_head res_list;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&res_list);
|
|
|
|
|
2017-11-10 21:40:30 +08:00
|
|
|
ret = acpi_dev_get_resources(adev, &res_list,
|
2016-10-03 16:40:03 +08:00
|
|
|
acpi_populate_gpio_lookup,
|
2015-08-27 10:41:33 +08:00
|
|
|
lookup);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
acpi_dev_free_resource_list(&res_list);
|
|
|
|
|
|
|
|
if (!lookup->desc)
|
|
|
|
return -ENOENT;
|
|
|
|
|
2017-11-10 21:40:28 +08:00
|
|
|
if (info)
|
2015-08-27 10:41:33 +08:00
|
|
|
*info = lookup->info;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-08-27 10:42:33 +08:00
|
|
|
static int acpi_gpio_property_lookup(struct fwnode_handle *fwnode,
|
2015-08-27 10:41:33 +08:00
|
|
|
const char *propname, int index,
|
|
|
|
struct acpi_gpio_lookup *lookup)
|
|
|
|
{
|
2018-07-17 22:19:11 +08:00
|
|
|
struct fwnode_reference_args args;
|
2017-11-10 21:40:32 +08:00
|
|
|
unsigned int quirks = 0;
|
2015-08-27 10:41:33 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
memset(&args, 0, sizeof(args));
|
2016-10-21 22:21:29 +08:00
|
|
|
ret = __acpi_node_get_property_reference(fwnode, propname, index, 3,
|
|
|
|
&args);
|
2015-08-27 10:42:33 +08:00
|
|
|
if (ret) {
|
|
|
|
struct acpi_device *adev = to_acpi_device_node(fwnode);
|
2015-08-27 10:41:33 +08:00
|
|
|
|
2015-08-27 10:42:33 +08:00
|
|
|
if (!adev)
|
|
|
|
return ret;
|
|
|
|
|
2017-11-10 21:40:32 +08:00
|
|
|
if (!acpi_get_driver_gpio_data(adev, propname, index, &args,
|
|
|
|
&quirks))
|
2015-08-27 10:42:33 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2015-08-27 10:41:33 +08:00
|
|
|
/*
|
|
|
|
* The property was found and resolved, so need to lookup the GPIO based
|
|
|
|
* on returned args.
|
|
|
|
*/
|
2018-07-17 22:19:11 +08:00
|
|
|
if (!to_acpi_device_node(args.fwnode))
|
|
|
|
return -EINVAL;
|
2016-10-21 22:21:29 +08:00
|
|
|
if (args.nargs != 3)
|
|
|
|
return -EPROTO;
|
|
|
|
|
|
|
|
lookup->index = args.args[0];
|
|
|
|
lookup->pin_index = args.args[1];
|
|
|
|
lookup->active_low = !!args.args[2];
|
|
|
|
|
2018-07-17 22:19:11 +08:00
|
|
|
lookup->info.adev = to_acpi_device_node(args.fwnode);
|
2017-11-10 21:40:32 +08:00
|
|
|
lookup->info.quirks = quirks;
|
2018-07-17 22:19:11 +08:00
|
|
|
|
2015-08-27 10:41:33 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-04-03 18:56:54 +08:00
|
|
|
/**
|
2013-10-10 16:01:08 +08:00
|
|
|
* acpi_get_gpiod_by_index() - get a GPIO descriptor from device resources
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
* @adev: pointer to a ACPI device to get GPIO from
|
|
|
|
* @propname: Property name of the GPIO (optional)
|
2013-04-03 18:56:54 +08:00
|
|
|
* @index: index of GpioIo/GpioInt resource (starting from %0)
|
|
|
|
* @info: info pointer to fill in (optional)
|
|
|
|
*
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
* Function goes through ACPI resources for @adev and based on @index looks
|
2013-10-10 16:01:08 +08:00
|
|
|
* up a GpioIo/GpioInt resource, translates it to the Linux GPIO descriptor,
|
2013-04-03 18:56:54 +08:00
|
|
|
* and returns it. @index matches GpioIo/GpioInt resources only so if there
|
|
|
|
* are total %3 GPIO resources, the index goes from %0 to %2.
|
|
|
|
*
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
* If @propname is specified the GPIO is looked using device property. In
|
|
|
|
* that case @index is used to select the GPIO entry in the property value
|
|
|
|
* (in case of multiple).
|
|
|
|
*
|
2019-03-30 05:33:45 +08:00
|
|
|
* If the GPIO cannot be translated or there is an error, an ERR_PTR is
|
2013-04-03 18:56:54 +08:00
|
|
|
* returned.
|
|
|
|
*
|
|
|
|
* Note: if the GPIO resource has multiple entries in the pin list, this
|
|
|
|
* function only returns the first.
|
|
|
|
*/
|
2016-10-03 16:40:03 +08:00
|
|
|
static struct gpio_desc *acpi_get_gpiod_by_index(struct acpi_device *adev,
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
const char *propname, int index,
|
2013-10-10 16:01:08 +08:00
|
|
|
struct acpi_gpio_info *info)
|
2013-04-03 18:56:54 +08:00
|
|
|
{
|
|
|
|
struct acpi_gpio_lookup lookup;
|
|
|
|
int ret;
|
|
|
|
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
if (!adev)
|
2013-10-10 16:01:08 +08:00
|
|
|
return ERR_PTR(-ENODEV);
|
2013-04-03 18:56:54 +08:00
|
|
|
|
|
|
|
memset(&lookup, 0, sizeof(lookup));
|
|
|
|
lookup.index = index;
|
|
|
|
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
if (propname) {
|
|
|
|
dev_dbg(&adev->dev, "GPIO: looking up %s\n", propname);
|
|
|
|
|
2015-08-27 10:42:33 +08:00
|
|
|
ret = acpi_gpio_property_lookup(acpi_fwnode_handle(adev),
|
|
|
|
propname, index, &lookup);
|
2015-08-27 10:41:33 +08:00
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
|
2020-11-10 04:53:30 +08:00
|
|
|
dev_dbg(&adev->dev, "GPIO: _DSD returned %s %d %u %u\n",
|
2017-11-10 21:40:30 +08:00
|
|
|
dev_name(&lookup.info.adev->dev), lookup.index,
|
2015-08-27 10:41:33 +08:00
|
|
|
lookup.pin_index, lookup.active_low);
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
} else {
|
|
|
|
dev_dbg(&adev->dev, "GPIO: looking up %d in _CRS\n", index);
|
2017-11-10 21:40:30 +08:00
|
|
|
lookup.info.adev = adev;
|
gpio / ACPI: Add support for _DSD device properties
With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and
other things as well) returned by _CRS. Previously we were only able to
use integer index to find the corresponding GPIO, which is pretty error
prone if the order changes.
With _DSD we can now query GPIOs using name instead of an integer index,
like the below example shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
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.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-29 22:41:01 +08:00
|
|
|
}
|
|
|
|
|
2015-08-27 10:41:33 +08:00
|
|
|
ret = acpi_gpio_resource_lookup(&lookup, info);
|
|
|
|
return ret ? ERR_PTR(ret) : lookup.desc;
|
2013-04-03 18:56:54 +08:00
|
|
|
}
|
2014-01-08 18:40:54 +08:00
|
|
|
|
2019-09-05 01:26:24 +08:00
|
|
|
static bool acpi_can_fallback_to_crs(struct acpi_device *adev,
|
|
|
|
const char *con_id)
|
|
|
|
{
|
|
|
|
/* Never allow fallback if the device has properties */
|
|
|
|
if (acpi_dev_has_props(adev) || adev->driver_gpios)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return con_id == NULL;
|
|
|
|
}
|
|
|
|
|
2016-10-03 16:40:03 +08:00
|
|
|
struct gpio_desc *acpi_find_gpio(struct device *dev,
|
|
|
|
const char *con_id,
|
|
|
|
unsigned int idx,
|
2017-05-24 01:03:23 +08:00
|
|
|
enum gpiod_flags *dflags,
|
2019-04-10 23:39:16 +08:00
|
|
|
unsigned long *lookupflags)
|
2016-10-03 16:40:03 +08:00
|
|
|
{
|
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
|
|
|
struct acpi_gpio_info info;
|
|
|
|
struct gpio_desc *desc;
|
|
|
|
char propname[32];
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* Try first from _DSD */
|
|
|
|
for (i = 0; i < ARRAY_SIZE(gpio_suffixes); i++) {
|
2017-05-24 01:03:17 +08:00
|
|
|
if (con_id) {
|
2016-10-03 16:40:03 +08:00
|
|
|
snprintf(propname, sizeof(propname), "%s-%s",
|
|
|
|
con_id, gpio_suffixes[i]);
|
|
|
|
} else {
|
|
|
|
snprintf(propname, sizeof(propname), "%s",
|
|
|
|
gpio_suffixes[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
desc = acpi_get_gpiod_by_index(adev, propname, idx, &info);
|
2017-03-24 04:21:38 +08:00
|
|
|
if (!IS_ERR(desc))
|
2016-10-03 16:40:03 +08:00
|
|
|
break;
|
2017-03-24 04:21:38 +08:00
|
|
|
if (PTR_ERR(desc) == -EPROBE_DEFER)
|
|
|
|
return ERR_CAST(desc);
|
2016-10-03 16:40:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Then from plain _CRS GPIOs */
|
|
|
|
if (IS_ERR(desc)) {
|
|
|
|
if (!acpi_can_fallback_to_crs(adev, con_id))
|
|
|
|
return ERR_PTR(-ENOENT);
|
|
|
|
|
|
|
|
desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info);
|
|
|
|
if (IS_ERR(desc))
|
|
|
|
return desc;
|
2017-05-24 01:03:18 +08:00
|
|
|
}
|
2016-10-03 16:40:03 +08:00
|
|
|
|
2017-05-24 01:03:18 +08:00
|
|
|
if (info.gpioint &&
|
2017-05-24 01:03:23 +08:00
|
|
|
(*dflags == GPIOD_OUT_LOW || *dflags == GPIOD_OUT_HIGH)) {
|
2021-11-23 18:18:37 +08:00
|
|
|
dev_dbg(&adev->dev, "refusing GpioInt() entry when doing GPIOD_OUT_* lookup\n");
|
2017-05-24 01:03:18 +08:00
|
|
|
return ERR_PTR(-ENOENT);
|
2016-10-03 16:40:03 +08:00
|
|
|
}
|
|
|
|
|
2017-11-10 21:40:31 +08:00
|
|
|
acpi_gpio_update_gpiod_flags(dflags, &info);
|
2019-04-10 23:39:20 +08:00
|
|
|
acpi_gpio_update_gpiod_lookup_flags(lookupflags, &info);
|
2016-10-03 16:40:03 +08:00
|
|
|
return desc;
|
|
|
|
}
|
|
|
|
|
2015-08-27 10:42:33 +08:00
|
|
|
/**
|
|
|
|
* acpi_node_get_gpiod() - get a GPIO descriptor from ACPI resources
|
|
|
|
* @fwnode: pointer to an ACPI firmware node to get the GPIO information from
|
|
|
|
* @propname: Property name of the GPIO
|
|
|
|
* @index: index of GpioIo/GpioInt resource (starting from %0)
|
|
|
|
* @info: info pointer to fill in (optional)
|
|
|
|
*
|
2019-03-30 05:33:45 +08:00
|
|
|
* If @fwnode is an ACPI device object, call acpi_get_gpiod_by_index() for it.
|
|
|
|
* Otherwise (i.e. it is a data-only non-device object), use the property-based
|
2015-08-27 10:42:33 +08:00
|
|
|
* GPIO lookup to get to the GPIO resource with the relevant information and use
|
|
|
|
* that to obtain the GPIO descriptor to return.
|
2019-03-30 05:33:45 +08:00
|
|
|
*
|
|
|
|
* If the GPIO cannot be translated or there is an error an ERR_PTR is
|
|
|
|
* returned.
|
2015-08-27 10:42:33 +08:00
|
|
|
*/
|
|
|
|
struct gpio_desc *acpi_node_get_gpiod(struct fwnode_handle *fwnode,
|
|
|
|
const char *propname, int index,
|
|
|
|
struct acpi_gpio_info *info)
|
|
|
|
{
|
|
|
|
struct acpi_gpio_lookup lookup;
|
|
|
|
struct acpi_device *adev;
|
|
|
|
int ret;
|
2013-04-03 18:56:54 +08:00
|
|
|
|
2015-08-27 10:42:33 +08:00
|
|
|
adev = to_acpi_device_node(fwnode);
|
|
|
|
if (adev)
|
|
|
|
return acpi_get_gpiod_by_index(adev, propname, index, info);
|
2013-04-03 18:56:54 +08:00
|
|
|
|
2015-08-27 10:42:33 +08:00
|
|
|
if (!is_acpi_data_node(fwnode))
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
|
|
|
|
if (!propname)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
memset(&lookup, 0, sizeof(lookup));
|
|
|
|
lookup.index = index;
|
|
|
|
|
|
|
|
ret = acpi_gpio_property_lookup(fwnode, propname, index, &lookup);
|
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
2013-04-03 18:56:54 +08:00
|
|
|
|
2015-08-27 10:42:33 +08:00
|
|
|
ret = acpi_gpio_resource_lookup(&lookup, info);
|
|
|
|
return ret ? ERR_PTR(ret) : lookup.desc;
|
2013-04-03 18:56:54 +08:00
|
|
|
}
|
2014-01-08 18:40:54 +08:00
|
|
|
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
/**
|
2021-02-26 00:33:19 +08:00
|
|
|
* acpi_dev_gpio_irq_get_by() - Find GpioInt and translate it to Linux IRQ number
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
* @adev: pointer to a ACPI device to get IRQ from
|
2021-02-26 00:33:19 +08:00
|
|
|
* @name: optional name of GpioInt resource
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
* @index: index of GpioInt resource (starting from %0)
|
|
|
|
*
|
|
|
|
* If the device has one or more GpioInt resources, this function can be
|
|
|
|
* used to translate from the GPIO offset in the resource to the Linux IRQ
|
|
|
|
* number.
|
|
|
|
*
|
2017-05-24 01:03:23 +08:00
|
|
|
* The function is idempotent, though each time it runs it will configure GPIO
|
|
|
|
* pin direction according to the flags in GpioInt resource.
|
|
|
|
*
|
2021-02-26 00:33:19 +08:00
|
|
|
* The function takes optional @name parameter. If the resource has a property
|
|
|
|
* name, then only those will be taken into account.
|
|
|
|
*
|
2017-07-24 22:57:25 +08:00
|
|
|
* Return: Linux IRQ number (> %0) on success, negative errno on failure.
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
*/
|
2021-02-26 00:33:19 +08:00
|
|
|
int acpi_dev_gpio_irq_get_by(struct acpi_device *adev, const char *name, int index)
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
{
|
|
|
|
int idx, i;
|
2015-12-24 06:25:34 +08:00
|
|
|
unsigned int irq_flags;
|
2017-05-24 01:03:23 +08:00
|
|
|
int ret;
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
|
|
|
|
for (i = 0, idx = 0; idx <= index; i++) {
|
|
|
|
struct acpi_gpio_info info;
|
|
|
|
struct gpio_desc *desc;
|
|
|
|
|
2021-02-26 00:33:19 +08:00
|
|
|
desc = acpi_get_gpiod_by_index(adev, name, i, &info);
|
2017-03-14 06:04:21 +08:00
|
|
|
|
|
|
|
/* Ignore -EPROBE_DEFER, it only matters if idx matches */
|
|
|
|
if (IS_ERR(desc) && PTR_ERR(desc) != -EPROBE_DEFER)
|
|
|
|
return PTR_ERR(desc);
|
|
|
|
|
2015-12-24 06:25:34 +08:00
|
|
|
if (info.gpioint && idx++ == index) {
|
2019-04-10 23:39:17 +08:00
|
|
|
unsigned long lflags = GPIO_LOOKUP_FLAGS_DEFAULT;
|
2020-11-10 04:53:24 +08:00
|
|
|
enum gpiod_flags dflags = GPIOD_ASIS;
|
2017-05-24 01:03:23 +08:00
|
|
|
char label[32];
|
2017-03-14 06:04:21 +08:00
|
|
|
int irq;
|
2015-12-24 06:25:34 +08:00
|
|
|
|
2017-03-14 06:04:21 +08:00
|
|
|
if (IS_ERR(desc))
|
|
|
|
return PTR_ERR(desc);
|
2015-12-24 06:25:34 +08:00
|
|
|
|
2017-03-14 06:04:21 +08:00
|
|
|
irq = gpiod_to_irq(desc);
|
2015-12-24 06:25:34 +08:00
|
|
|
if (irq < 0)
|
|
|
|
return irq;
|
|
|
|
|
2020-11-10 04:53:24 +08:00
|
|
|
acpi_gpio_update_gpiod_flags(&dflags, &info);
|
|
|
|
acpi_gpio_update_gpiod_lookup_flags(&lflags, &info);
|
|
|
|
|
2017-05-24 01:03:23 +08:00
|
|
|
snprintf(label, sizeof(label), "GpioInt() %d", index);
|
2020-11-10 04:53:24 +08:00
|
|
|
ret = gpiod_configure_flags(desc, label, lflags, dflags);
|
2017-05-24 01:03:23 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2020-11-10 04:53:26 +08:00
|
|
|
ret = gpio_set_debounce_timeout(desc, info.debounce);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2015-12-24 06:25:34 +08:00
|
|
|
irq_flags = acpi_dev_get_irq_type(info.triggering,
|
|
|
|
info.polarity);
|
|
|
|
|
2021-11-26 04:30:10 +08:00
|
|
|
/*
|
|
|
|
* If the IRQ is not already in use then set type
|
|
|
|
* if specified and different than the current one.
|
|
|
|
*/
|
|
|
|
if (can_request_irq(irq, irq_flags)) {
|
|
|
|
if (irq_flags != IRQ_TYPE_NONE &&
|
|
|
|
irq_flags != irq_get_trigger_type(irq))
|
|
|
|
irq_set_irq_type(irq, irq_flags);
|
|
|
|
} else {
|
|
|
|
dev_dbg(&adev->dev, "IRQ %d already in use\n", irq);
|
|
|
|
}
|
2015-12-24 06:25:34 +08:00
|
|
|
|
|
|
|
return irq;
|
|
|
|
}
|
|
|
|
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
}
|
2017-03-14 06:04:21 +08:00
|
|
|
return -ENOENT;
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
}
|
2021-02-26 00:33:19 +08:00
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_gpio_irq_get_by);
|
gpio / ACPI: Add support for retrieving GpioInt resources from a device
ACPI specification knows two types of GPIOs: GpioIo and GpioInt. The latter
is used to describe that a given device interrupt line is connected to a
specific GPIO pin. Typical ACPI _CRS entry for such device looks like
below:
Name (_CRS, ResourceTemplate ()
{
I2cSerialBus (0x004A, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C6",
0x00, ResourceConsumer)
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.GPO0",
0x00, ResourceConsumer)
{
0x004B
}
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x004C
}
})
Currently drivers need to request a GPIO corresponding to the right GpioInt
and then translate that to Linux IRQ number. This adds unnecessary lines of
boiler-plate code.
We can ease this a bit by introducing acpi_dev_gpio_irq_get() analogous to
of_irq_get(). This function translates given GpioInt resource under the
device in question to the suitable Linux IRQ number.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-05-06 18:29:06 +08:00
|
|
|
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
static acpi_status
|
|
|
|
acpi_gpio_adr_space_handler(u32 function, acpi_physical_address address,
|
|
|
|
u32 bits, u64 *value, void *handler_context,
|
|
|
|
void *region_context)
|
|
|
|
{
|
|
|
|
struct acpi_gpio_chip *achip = region_context;
|
|
|
|
struct gpio_chip *chip = achip->chip;
|
|
|
|
struct acpi_resource_gpio *agpio;
|
|
|
|
struct acpi_resource *ares;
|
2020-11-10 04:53:30 +08:00
|
|
|
u16 pin_index = address;
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
acpi_status status;
|
gpio / ACPI: Use pin index and bit length
Fix code when the operation region callback is for an gpio, which
is not at index 0 and for partial pins in a GPIO definition.
For example:
Name (GMOD, ResourceTemplate ()
{
//3 Outputs that define the Power mode of the device
GpioIo (Exclusive, PullDown, , , , "\\_SB.GPI2") {10, 11, 12}
})
}
If opregion callback calls is for:
- Set pin 10, then address = 0 and bit length = 1
- Set pin 11, then address = 1 and bit length = 1
- Set for both pin 11 and pin 12, then address = 1, bit length = 2
This change requires updated ACPICA gpio operation handler code to
send the pin index and bit length.
Fixes: 473ed7be0da0 (gpio / ACPI: Add support for ACPI GPIO operation regions)
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 75ec6e55f138 ACPICA: Update to GPIO region handler interface.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-23 10:35:54 +08:00
|
|
|
int length;
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
int i;
|
|
|
|
|
|
|
|
status = acpi_buffer_to_resource(achip->conn_info.connection,
|
|
|
|
achip->conn_info.length, &ares);
|
|
|
|
if (ACPI_FAILURE(status))
|
|
|
|
return status;
|
|
|
|
|
|
|
|
if (WARN_ON(ares->type != ACPI_RESOURCE_TYPE_GPIO)) {
|
|
|
|
ACPI_FREE(ares);
|
|
|
|
return AE_BAD_PARAMETER;
|
|
|
|
}
|
|
|
|
|
|
|
|
agpio = &ares->data.gpio;
|
|
|
|
|
|
|
|
if (WARN_ON(agpio->io_restriction == ACPI_IO_RESTRICT_INPUT &&
|
|
|
|
function == ACPI_WRITE)) {
|
|
|
|
ACPI_FREE(ares);
|
|
|
|
return AE_BAD_PARAMETER;
|
|
|
|
}
|
|
|
|
|
2020-11-10 04:53:30 +08:00
|
|
|
length = min_t(u16, agpio->pin_table_length, pin_index + bits);
|
gpio / ACPI: Use pin index and bit length
Fix code when the operation region callback is for an gpio, which
is not at index 0 and for partial pins in a GPIO definition.
For example:
Name (GMOD, ResourceTemplate ()
{
//3 Outputs that define the Power mode of the device
GpioIo (Exclusive, PullDown, , , , "\\_SB.GPI2") {10, 11, 12}
})
}
If opregion callback calls is for:
- Set pin 10, then address = 0 and bit length = 1
- Set pin 11, then address = 1 and bit length = 1
- Set for both pin 11 and pin 12, then address = 1, bit length = 2
This change requires updated ACPICA gpio operation handler code to
send the pin index and bit length.
Fixes: 473ed7be0da0 (gpio / ACPI: Add support for ACPI GPIO operation regions)
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 75ec6e55f138 ACPICA: Update to GPIO region handler interface.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-23 10:35:54 +08:00
|
|
|
for (i = pin_index; i < length; ++i) {
|
2015-04-10 06:25:10 +08:00
|
|
|
int pin = agpio->pin_table[i];
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
struct acpi_gpio_connection *conn;
|
|
|
|
struct gpio_desc *desc;
|
|
|
|
bool found;
|
|
|
|
|
|
|
|
mutex_lock(&achip->conn_lock);
|
|
|
|
|
|
|
|
found = false;
|
|
|
|
list_for_each_entry(conn, &achip->conns, node) {
|
2014-08-20 01:06:08 +08:00
|
|
|
if (conn->pin == pin) {
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
found = true;
|
2014-08-20 01:06:08 +08:00
|
|
|
desc = conn->desc;
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
gpio / ACPI: Allow shared GPIO event to be read via operation region
In Microsoft Surface3 the GPIO detecting lid state is shared between GPIO
event and operation region. Below is simplied version of the DSDT from
Surface3 including relevant parts:
Scope (GPO0)
{
Name (_AEI, ResourceTemplate ()
{
GpioInt (Edge, ActiveBoth, Shared, PullNone, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x004C
}
})
OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
Field (GPOR, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Shared, PullNone, 0x0000, 0x0000,
IoRestrictionNone, "\\_SB.GPO0", 0x00,
ResourceConsumer,,)
{ // Pin list
0x004C
}
),
HELD, 1
}
Method (_E4C, 0, Serialized) // _Exx: Edge-Triggered GPE
{
If ((HELD == One))
{
^^LID.LIDB = One
}
Else
{
^^LID.LIDB = Zero
Notify (LID, 0x80) // Status Change
}
Notify (^^PCI0.SPI1.NTRG, One) // Device Check
}
}
When GPIO 0x4c changes we call ASL method _E4C which tries to read HELD
field (the same GPIO). This triggers following error on the console:
ACPI Error: Method parse/execution failed [\_SB.GPO0._E4C]
(Node ffff88013f4b4438), AE_ERROR (20150930/psparse-542)
The error happens because ACPI GPIO operation region handler
(acpi_gpio_adr_space_handler()) tries to acquire the very same GPIO which
returns an error (-EBUSY) because the GPIO is already reserved for the GPIO
event.
Fix this so that we "borrow" the event GPIO if we find the GPIO belongs to
an event. Allow this only for GPIOs that are read.
To be able to go through acpi_gpio->events list for operation region access
we need to make sure the list is properly initialized whenever GPIO chip is
registered.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106571
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-30 18:02:05 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The same GPIO can be shared between operation region and
|
|
|
|
* event but only if the access here is ACPI_READ. In that
|
|
|
|
* case we "borrow" the event GPIO instead.
|
|
|
|
*/
|
2019-02-16 05:36:19 +08:00
|
|
|
if (!found && agpio->shareable == ACPI_SHARED &&
|
gpio / ACPI: Allow shared GPIO event to be read via operation region
In Microsoft Surface3 the GPIO detecting lid state is shared between GPIO
event and operation region. Below is simplied version of the DSDT from
Surface3 including relevant parts:
Scope (GPO0)
{
Name (_AEI, ResourceTemplate ()
{
GpioInt (Edge, ActiveBoth, Shared, PullNone, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x004C
}
})
OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
Field (GPOR, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Shared, PullNone, 0x0000, 0x0000,
IoRestrictionNone, "\\_SB.GPO0", 0x00,
ResourceConsumer,,)
{ // Pin list
0x004C
}
),
HELD, 1
}
Method (_E4C, 0, Serialized) // _Exx: Edge-Triggered GPE
{
If ((HELD == One))
{
^^LID.LIDB = One
}
Else
{
^^LID.LIDB = Zero
Notify (LID, 0x80) // Status Change
}
Notify (^^PCI0.SPI1.NTRG, One) // Device Check
}
}
When GPIO 0x4c changes we call ASL method _E4C which tries to read HELD
field (the same GPIO). This triggers following error on the console:
ACPI Error: Method parse/execution failed [\_SB.GPO0._E4C]
(Node ffff88013f4b4438), AE_ERROR (20150930/psparse-542)
The error happens because ACPI GPIO operation region handler
(acpi_gpio_adr_space_handler()) tries to acquire the very same GPIO which
returns an error (-EBUSY) because the GPIO is already reserved for the GPIO
event.
Fix this so that we "borrow" the event GPIO if we find the GPIO belongs to
an event. Allow this only for GPIOs that are read.
To be able to go through acpi_gpio->events list for operation region access
we need to make sure the list is properly initialized whenever GPIO chip is
registered.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106571
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-30 18:02:05 +08:00
|
|
|
function == ACPI_READ) {
|
|
|
|
struct acpi_gpio_event *event;
|
|
|
|
|
|
|
|
list_for_each_entry(event, &achip->events, node) {
|
|
|
|
if (event->pin == pin) {
|
|
|
|
desc = event->desc;
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
if (!found) {
|
2020-11-12 05:35:33 +08:00
|
|
|
desc = acpi_request_own_gpiod(chip, agpio, i, "ACPI:OpRegion");
|
2014-08-20 01:06:08 +08:00
|
|
|
if (IS_ERR(desc)) {
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
mutex_unlock(&achip->conn_lock);
|
2020-11-12 02:01:52 +08:00
|
|
|
status = AE_ERROR;
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
conn = kzalloc(sizeof(*conn), GFP_KERNEL);
|
|
|
|
if (!conn) {
|
|
|
|
gpiochip_free_own_desc(desc);
|
|
|
|
mutex_unlock(&achip->conn_lock);
|
2020-11-12 02:01:52 +08:00
|
|
|
status = AE_NO_MEMORY;
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2014-08-20 01:06:08 +08:00
|
|
|
conn->pin = pin;
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
conn->desc = desc;
|
|
|
|
list_add_tail(&conn->node, &achip->conns);
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&achip->conn_lock);
|
|
|
|
|
|
|
|
if (function == ACPI_WRITE)
|
2020-11-10 04:53:31 +08:00
|
|
|
gpiod_set_raw_value_cansleep(desc, !!(*value & BIT(i)));
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
else
|
2014-05-20 17:07:38 +08:00
|
|
|
*value |= (u64)gpiod_get_raw_value_cansleep(desc) << i;
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
ACPI_FREE(ares);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_gpiochip_request_regions(struct acpi_gpio_chip *achip)
|
|
|
|
{
|
|
|
|
struct gpio_chip *chip = achip->chip;
|
2015-11-04 16:56:26 +08:00
|
|
|
acpi_handle handle = ACPI_HANDLE(chip->parent);
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&achip->conns);
|
|
|
|
mutex_init(&achip->conn_lock);
|
|
|
|
status = acpi_install_address_space_handler(handle, ACPI_ADR_SPACE_GPIO,
|
|
|
|
acpi_gpio_adr_space_handler,
|
|
|
|
NULL, achip);
|
|
|
|
if (ACPI_FAILURE(status))
|
2015-11-04 16:56:26 +08:00
|
|
|
dev_err(chip->parent,
|
|
|
|
"Failed to install GPIO OpRegion handler\n");
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_gpiochip_free_regions(struct acpi_gpio_chip *achip)
|
|
|
|
{
|
|
|
|
struct gpio_chip *chip = achip->chip;
|
2015-11-04 16:56:26 +08:00
|
|
|
acpi_handle handle = ACPI_HANDLE(chip->parent);
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
struct acpi_gpio_connection *conn, *tmp;
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
status = acpi_remove_address_space_handler(handle, ACPI_ADR_SPACE_GPIO,
|
|
|
|
acpi_gpio_adr_space_handler);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
2015-11-04 16:56:26 +08:00
|
|
|
dev_err(chip->parent,
|
|
|
|
"Failed to remove GPIO OpRegion handler\n");
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_for_each_entry_safe_reverse(conn, tmp, &achip->conns, node) {
|
|
|
|
gpiochip_free_own_desc(conn->desc);
|
|
|
|
list_del(&conn->node);
|
|
|
|
kfree(conn);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-10 23:39:16 +08:00
|
|
|
static struct gpio_desc *
|
|
|
|
acpi_gpiochip_parse_own_gpio(struct acpi_gpio_chip *achip,
|
|
|
|
struct fwnode_handle *fwnode,
|
|
|
|
const char **name,
|
|
|
|
unsigned long *lflags,
|
2019-04-10 23:39:18 +08:00
|
|
|
enum gpiod_flags *dflags)
|
2016-10-21 22:21:30 +08:00
|
|
|
{
|
|
|
|
struct gpio_chip *chip = achip->chip;
|
|
|
|
struct gpio_desc *desc;
|
|
|
|
u32 gpios[2];
|
|
|
|
int ret;
|
|
|
|
|
2019-04-10 23:39:17 +08:00
|
|
|
*lflags = GPIO_LOOKUP_FLAGS_DEFAULT;
|
2020-11-10 04:53:25 +08:00
|
|
|
*dflags = GPIOD_ASIS;
|
2016-11-08 21:40:06 +08:00
|
|
|
*name = NULL;
|
|
|
|
|
2016-10-21 22:21:30 +08:00
|
|
|
ret = fwnode_property_read_u32_array(fwnode, "gpios", gpios,
|
|
|
|
ARRAY_SIZE(gpios));
|
|
|
|
if (ret < 0)
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
2017-11-27 21:54:42 +08:00
|
|
|
desc = gpiochip_get_desc(chip, gpios[0]);
|
2016-10-21 22:21:30 +08:00
|
|
|
if (IS_ERR(desc))
|
|
|
|
return desc;
|
|
|
|
|
|
|
|
if (gpios[1])
|
|
|
|
*lflags |= GPIO_ACTIVE_LOW;
|
|
|
|
|
|
|
|
if (fwnode_property_present(fwnode, "input"))
|
|
|
|
*dflags |= GPIOD_IN;
|
|
|
|
else if (fwnode_property_present(fwnode, "output-low"))
|
|
|
|
*dflags |= GPIOD_OUT_LOW;
|
|
|
|
else if (fwnode_property_present(fwnode, "output-high"))
|
|
|
|
*dflags |= GPIOD_OUT_HIGH;
|
|
|
|
else
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
|
|
|
fwnode_property_read_string(fwnode, "line-name", name);
|
|
|
|
|
|
|
|
return desc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void acpi_gpiochip_scan_gpios(struct acpi_gpio_chip *achip)
|
|
|
|
{
|
|
|
|
struct gpio_chip *chip = achip->chip;
|
|
|
|
struct fwnode_handle *fwnode;
|
|
|
|
|
|
|
|
device_for_each_child_node(chip->parent, fwnode) {
|
2019-04-10 23:39:16 +08:00
|
|
|
unsigned long lflags;
|
2019-04-10 23:39:18 +08:00
|
|
|
enum gpiod_flags dflags;
|
2016-10-21 22:21:30 +08:00
|
|
|
struct gpio_desc *desc;
|
|
|
|
const char *name;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!fwnode_property_present(fwnode, "gpio-hog"))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
desc = acpi_gpiochip_parse_own_gpio(achip, fwnode, &name,
|
|
|
|
&lflags, &dflags);
|
|
|
|
if (IS_ERR(desc))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = gpiod_hog(desc, name, lflags, dflags);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(chip->parent, "Failed to hog GPIO\n");
|
2016-10-30 00:11:57 +08:00
|
|
|
fwnode_handle_put(fwnode);
|
2016-10-21 22:21:30 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-01-08 18:40:54 +08:00
|
|
|
void acpi_gpiochip_add(struct gpio_chip *chip)
|
|
|
|
{
|
2014-03-10 20:54:51 +08:00
|
|
|
struct acpi_gpio_chip *acpi_gpio;
|
2021-06-04 06:40:02 +08:00
|
|
|
struct acpi_device *adev;
|
2014-03-10 20:54:51 +08:00
|
|
|
acpi_status status;
|
|
|
|
|
2015-11-04 16:56:26 +08:00
|
|
|
if (!chip || !chip->parent)
|
2014-03-31 20:16:49 +08:00
|
|
|
return;
|
|
|
|
|
2021-06-04 06:40:02 +08:00
|
|
|
adev = ACPI_COMPANION(chip->parent);
|
|
|
|
if (!adev)
|
2014-03-10 20:54:51 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
acpi_gpio = kzalloc(sizeof(*acpi_gpio), GFP_KERNEL);
|
|
|
|
if (!acpi_gpio) {
|
2015-11-04 16:56:26 +08:00
|
|
|
dev_err(chip->parent,
|
2014-03-10 20:54:51 +08:00
|
|
|
"Failed to allocate memory for ACPI GPIO chip\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
acpi_gpio->chip = chip;
|
gpio / ACPI: Allow shared GPIO event to be read via operation region
In Microsoft Surface3 the GPIO detecting lid state is shared between GPIO
event and operation region. Below is simplied version of the DSDT from
Surface3 including relevant parts:
Scope (GPO0)
{
Name (_AEI, ResourceTemplate ()
{
GpioInt (Edge, ActiveBoth, Shared, PullNone, 0x0000,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x004C
}
})
OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
Field (GPOR, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Shared, PullNone, 0x0000, 0x0000,
IoRestrictionNone, "\\_SB.GPO0", 0x00,
ResourceConsumer,,)
{ // Pin list
0x004C
}
),
HELD, 1
}
Method (_E4C, 0, Serialized) // _Exx: Edge-Triggered GPE
{
If ((HELD == One))
{
^^LID.LIDB = One
}
Else
{
^^LID.LIDB = Zero
Notify (LID, 0x80) // Status Change
}
Notify (^^PCI0.SPI1.NTRG, One) // Device Check
}
}
When GPIO 0x4c changes we call ASL method _E4C which tries to read HELD
field (the same GPIO). This triggers following error on the console:
ACPI Error: Method parse/execution failed [\_SB.GPO0._E4C]
(Node ffff88013f4b4438), AE_ERROR (20150930/psparse-542)
The error happens because ACPI GPIO operation region handler
(acpi_gpio_adr_space_handler()) tries to acquire the very same GPIO which
returns an error (-EBUSY) because the GPIO is already reserved for the GPIO
event.
Fix this so that we "borrow" the event GPIO if we find the GPIO belongs to
an event. Allow this only for GPIOs that are read.
To be able to go through acpi_gpio->events list for operation region access
we need to make sure the list is properly initialized whenever GPIO chip is
registered.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106571
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-10-30 18:02:05 +08:00
|
|
|
INIT_LIST_HEAD(&acpi_gpio->events);
|
2018-08-14 22:07:03 +08:00
|
|
|
INIT_LIST_HEAD(&acpi_gpio->deferred_req_irqs_list_entry);
|
2014-03-10 20:54:51 +08:00
|
|
|
|
2021-06-04 06:40:02 +08:00
|
|
|
status = acpi_attach_data(adev->handle, acpi_gpio_chip_dh, acpi_gpio);
|
2014-03-10 20:54:51 +08:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2015-11-04 16:56:26 +08:00
|
|
|
dev_err(chip->parent, "Failed to attach ACPI GPIO chip\n");
|
2014-03-10 20:54:51 +08:00
|
|
|
kfree(acpi_gpio);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
acpi_gpiochip_request_regions(acpi_gpio);
|
2016-10-21 22:21:30 +08:00
|
|
|
acpi_gpiochip_scan_gpios(acpi_gpio);
|
2021-06-04 06:40:02 +08:00
|
|
|
acpi_dev_clear_dependencies(adev);
|
2014-01-08 18:40:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void acpi_gpiochip_remove(struct gpio_chip *chip)
|
|
|
|
{
|
2014-03-10 20:54:51 +08:00
|
|
|
struct acpi_gpio_chip *acpi_gpio;
|
|
|
|
acpi_handle handle;
|
|
|
|
acpi_status status;
|
|
|
|
|
2015-11-04 16:56:26 +08:00
|
|
|
if (!chip || !chip->parent)
|
2014-03-31 20:16:49 +08:00
|
|
|
return;
|
|
|
|
|
2015-11-04 16:56:26 +08:00
|
|
|
handle = ACPI_HANDLE(chip->parent);
|
2014-03-10 20:54:51 +08:00
|
|
|
if (!handle)
|
|
|
|
return;
|
|
|
|
|
|
|
|
status = acpi_get_data(handle, acpi_gpio_chip_dh, (void **)&acpi_gpio);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
2015-11-04 16:56:26 +08:00
|
|
|
dev_warn(chip->parent, "Failed to retrieve ACPI GPIO chip\n");
|
2014-03-10 20:54:51 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
gpio / ACPI: Add support for ACPI GPIO operation regions
GPIO operation regions is a new feature introduced in ACPI 5.0
specification. This feature adds a way for platform ASL code to call back
to OS GPIO driver and toggle GPIO pins.
An example ASL code from Lenovo Miix 2 tablet with only relevant part
listed:
Device (\_SB.GPO0)
{
Name (AVBL, Zero)
Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x08))
{
// Marks the region available
Store (Arg1, AVBL)
}
}
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0C)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0, 0, IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer,,)
{
0x003B
}
),
SHD3, 1,
}
}
Device (SHUB)
{
Method (_PS0, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (One, \_SB.GPO0.SHD3)
Sleep (0x32)
}
}
Method (_PS3, 0, Serialized)
{
If (LEqual (\_SB.GPO0.AVBL, One))
{
Store (Zero, \_SB.GPO0.SHD3)
}
}
}
How this works is that whenever _PS0 or _PS3 method is run (typically when
SHUB device is transitioned to D0 or D3 respectively), ASL code checks if
the GPIO operation region is available (\_SB.GPO0.AVBL). If it is we go and
store either 0 or 1 to \_SB.GPO0.SHD3.
Now, when ACPICA notices ACPI GPIO operation region access (the store
above) it will call acpi_gpio_adr_space_handler() that then toggles the
GPIO accordingly using standard gpiolib interfaces.
Implement the support by registering GPIO operation region handlers for all
GPIO devices that have an ACPI handle. First time the GPIO is used by the
ASL code we make sure that the GPIO stays requested until the GPIO chip
driver itself is unloaded. If we find out that the GPIO is already
requested we just toggle it according to the value got from ASL code.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2014-03-14 23:58:07 +08:00
|
|
|
acpi_gpiochip_free_regions(acpi_gpio);
|
2014-03-10 20:54:51 +08:00
|
|
|
|
|
|
|
acpi_detach_data(handle, acpi_gpio_chip_dh);
|
|
|
|
kfree(acpi_gpio);
|
2014-01-08 18:40:54 +08:00
|
|
|
}
|
2015-02-12 00:27:58 +08:00
|
|
|
|
2021-03-09 17:37:34 +08:00
|
|
|
void acpi_gpio_dev_init(struct gpio_chip *gc, struct gpio_device *gdev)
|
|
|
|
{
|
|
|
|
/* Set default fwnode to parent's one if present */
|
|
|
|
if (gc->parent)
|
|
|
|
ACPI_COMPANION_SET(&gdev->dev, ACPI_COMPANION(gc->parent));
|
2021-12-23 18:38:08 +08:00
|
|
|
|
|
|
|
if (gc->fwnode)
|
|
|
|
device_set_node(&gdev->dev, gc->fwnode);
|
2021-03-09 17:37:34 +08:00
|
|
|
}
|
|
|
|
|
2016-10-21 22:21:29 +08:00
|
|
|
static int acpi_gpio_package_count(const union acpi_object *obj)
|
2015-02-12 00:27:58 +08:00
|
|
|
{
|
|
|
|
const union acpi_object *element = obj->package.elements;
|
|
|
|
const union acpi_object *end = element + obj->package.count;
|
|
|
|
unsigned int count = 0;
|
|
|
|
|
|
|
|
while (element < end) {
|
2016-10-21 22:21:29 +08:00
|
|
|
switch (element->type) {
|
|
|
|
case ACPI_TYPE_LOCAL_REFERENCE:
|
|
|
|
element += 3;
|
2020-08-24 06:36:59 +08:00
|
|
|
fallthrough;
|
2016-10-21 22:21:29 +08:00
|
|
|
case ACPI_TYPE_INTEGER:
|
|
|
|
element++;
|
2015-02-12 00:27:58 +08:00
|
|
|
count++;
|
2016-10-21 22:21:29 +08:00
|
|
|
break;
|
2015-02-12 00:27:58 +08:00
|
|
|
|
2016-10-21 22:21:29 +08:00
|
|
|
default:
|
|
|
|
return -EPROTO;
|
|
|
|
}
|
2015-02-12 00:27:58 +08:00
|
|
|
}
|
2016-10-21 22:21:29 +08:00
|
|
|
|
2015-02-12 00:27:58 +08:00
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int acpi_find_gpio_count(struct acpi_resource *ares, void *data)
|
|
|
|
{
|
|
|
|
unsigned int *count = data;
|
|
|
|
|
|
|
|
if (ares->type == ACPI_RESOURCE_TYPE_GPIO)
|
|
|
|
*count += ares->data.gpio.pin_table_length;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2019-03-30 05:33:45 +08:00
|
|
|
* acpi_gpio_count - count the GPIOs associated with a device / function
|
|
|
|
* @dev: GPIO consumer, can be %NULL for system-global GPIOs
|
2015-02-12 00:27:58 +08:00
|
|
|
* @con_id: function within the GPIO consumer
|
2019-03-30 05:33:45 +08:00
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* The number of GPIOs associated with a device / function or %-ENOENT,
|
|
|
|
* if no GPIO has been assigned to the requested function.
|
2015-02-12 00:27:58 +08:00
|
|
|
*/
|
|
|
|
int acpi_gpio_count(struct device *dev, const char *con_id)
|
|
|
|
{
|
|
|
|
struct acpi_device *adev = ACPI_COMPANION(dev);
|
|
|
|
const union acpi_object *obj;
|
|
|
|
const struct acpi_gpio_mapping *gm;
|
|
|
|
int count = -ENOENT;
|
|
|
|
int ret;
|
|
|
|
char propname[32];
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
/* Try first from _DSD */
|
|
|
|
for (i = 0; i < ARRAY_SIZE(gpio_suffixes); i++) {
|
2017-05-24 01:03:17 +08:00
|
|
|
if (con_id)
|
2015-02-12 00:27:58 +08:00
|
|
|
snprintf(propname, sizeof(propname), "%s-%s",
|
|
|
|
con_id, gpio_suffixes[i]);
|
|
|
|
else
|
|
|
|
snprintf(propname, sizeof(propname), "%s",
|
|
|
|
gpio_suffixes[i]);
|
|
|
|
|
|
|
|
ret = acpi_dev_get_property(adev, propname, ACPI_TYPE_ANY,
|
|
|
|
&obj);
|
|
|
|
if (ret == 0) {
|
|
|
|
if (obj->type == ACPI_TYPE_LOCAL_REFERENCE)
|
|
|
|
count = 1;
|
|
|
|
else if (obj->type == ACPI_TYPE_PACKAGE)
|
|
|
|
count = acpi_gpio_package_count(obj);
|
|
|
|
} else if (adev->driver_gpios) {
|
|
|
|
for (gm = adev->driver_gpios; gm->name; gm++)
|
|
|
|
if (strcmp(propname, gm->name) == 0) {
|
|
|
|
count = gm->size;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2017-02-21 00:15:46 +08:00
|
|
|
if (count > 0)
|
2015-02-12 00:27:58 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Then from plain _CRS GPIOs */
|
|
|
|
if (count < 0) {
|
|
|
|
struct list_head resource_list;
|
|
|
|
unsigned int crs_count = 0;
|
|
|
|
|
2017-05-24 01:03:20 +08:00
|
|
|
if (!acpi_can_fallback_to_crs(adev, con_id))
|
|
|
|
return count;
|
|
|
|
|
2015-02-12 00:27:58 +08:00
|
|
|
INIT_LIST_HEAD(&resource_list);
|
|
|
|
acpi_dev_get_resources(adev, &resource_list,
|
|
|
|
acpi_find_gpio_count, &crs_count);
|
|
|
|
acpi_dev_free_resource_list(&resource_list);
|
|
|
|
if (crs_count > 0)
|
|
|
|
count = crs_count;
|
|
|
|
}
|
2017-02-21 00:15:46 +08:00
|
|
|
return count ? count : -ENOENT;
|
2015-02-12 00:27:58 +08:00
|
|
|
}
|
2015-11-12 03:45:30 +08:00
|
|
|
|
2018-11-29 00:57:55 +08:00
|
|
|
/* Run deferred acpi_gpiochip_request_irqs() */
|
2020-03-25 18:39:56 +08:00
|
|
|
static int __init acpi_gpio_handle_deferred_request_irqs(void)
|
gpiolib-acpi: make sure we trigger edge events at least once on boot
On some systems using edge triggered ACPI Event Interrupts, the initial
state at boot is not setup by the firmware, instead relying on the edge
irq event handler running at least once to setup the initial state.
2 known examples of this are:
1) The Surface 3 has its _LID state controlled by an ACPI operation region
triggered by a GPIO event:
OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
Field (GPOR, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Shared, PullNone, 0x0000, 0x0000, IoRestrictionNone,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x004C
}
),
HELD, 1
}
Method (_E4C, 0, Serialized) // _Exx: Edge-Triggered GPE
{
If ((HELD == One))
{
^^LID.LIDB = One
}
Else
{
^^LID.LIDB = Zero
Notify (LID, 0x80) // Status Change
}
Notify (^^PCI0.SPI1.NTRG, One) // Device Check
}
Currently, the state of LIDB is wrong until the user actually closes or
open the cover. We need to trigger the GPIO event once to update the
internal ACPI state.
Coincidentally, this also enables the Surface 2 integrated HID sensor hub
which also requires an ACPI gpio operation region to start initialization.
2) Various Bay Trail based tablets come with an external USB mux and
TI T1210B USB phy to enable USB gadget mode. The mux is controlled by a
GPIO which is controlled by an edge triggered ACPI Event Interrupt which
monitors the micro-USB ID pin.
When the tablet is connected to a PC (or no cable is plugged in), the ID
pin is high and the tablet should be in gadget mode. But the GPIO
controlling the mux is initialized by the firmware so that the USB data
lines are muxed to the host controller.
This means that if the user wants to use gadget mode, the user needs to
first plug in a host-cable to force the ID pin low and then unplug it
and connect the tablet to a PC, to get the ACPI event handler to run and
switch the mux to device mode,
This commit fixes both by running the event-handler once on boot.
Note that the running of the event-handler is done from a late_initcall,
this is done because the handler AML code may rely on OperationRegions
registered by other builtin drivers. This avoids errors like these:
[ 0.133026] ACPI Error: No handler for Region [XSCG] ((____ptrval____)) [GenericSerialBus] (20180531/evregion-132)
[ 0.133036] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20180531/exfldio-265)
[ 0.133046] ACPI Error: Method parse/execution failed \_SB.GPO2._E12, AE_NOT_EXIST (20180531/psparse-516)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
[hdegoede: Document BYT USB mux reliance on initial trigger]
[hdegoede: Run event handler from a late_initcall, rather then immediately]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-07-12 23:25:06 +08:00
|
|
|
{
|
2018-08-14 22:07:03 +08:00
|
|
|
struct acpi_gpio_chip *acpi_gpio, *tmp;
|
|
|
|
|
|
|
|
mutex_lock(&acpi_gpio_deferred_req_irqs_lock);
|
|
|
|
list_for_each_entry_safe(acpi_gpio, tmp,
|
|
|
|
&acpi_gpio_deferred_req_irqs_list,
|
2018-11-29 00:57:55 +08:00
|
|
|
deferred_req_irqs_list_entry)
|
|
|
|
acpi_gpiochip_request_irqs(acpi_gpio);
|
2018-08-14 22:07:03 +08:00
|
|
|
|
|
|
|
acpi_gpio_deferred_req_irqs_done = true;
|
|
|
|
mutex_unlock(&acpi_gpio_deferred_req_irqs_lock);
|
gpiolib-acpi: make sure we trigger edge events at least once on boot
On some systems using edge triggered ACPI Event Interrupts, the initial
state at boot is not setup by the firmware, instead relying on the edge
irq event handler running at least once to setup the initial state.
2 known examples of this are:
1) The Surface 3 has its _LID state controlled by an ACPI operation region
triggered by a GPIO event:
OperationRegion (GPOR, GeneralPurposeIo, Zero, One)
Field (GPOR, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Shared, PullNone, 0x0000, 0x0000, IoRestrictionNone,
"\\_SB.GPO0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x004C
}
),
HELD, 1
}
Method (_E4C, 0, Serialized) // _Exx: Edge-Triggered GPE
{
If ((HELD == One))
{
^^LID.LIDB = One
}
Else
{
^^LID.LIDB = Zero
Notify (LID, 0x80) // Status Change
}
Notify (^^PCI0.SPI1.NTRG, One) // Device Check
}
Currently, the state of LIDB is wrong until the user actually closes or
open the cover. We need to trigger the GPIO event once to update the
internal ACPI state.
Coincidentally, this also enables the Surface 2 integrated HID sensor hub
which also requires an ACPI gpio operation region to start initialization.
2) Various Bay Trail based tablets come with an external USB mux and
TI T1210B USB phy to enable USB gadget mode. The mux is controlled by a
GPIO which is controlled by an edge triggered ACPI Event Interrupt which
monitors the micro-USB ID pin.
When the tablet is connected to a PC (or no cable is plugged in), the ID
pin is high and the tablet should be in gadget mode. But the GPIO
controlling the mux is initialized by the firmware so that the USB data
lines are muxed to the host controller.
This means that if the user wants to use gadget mode, the user needs to
first plug in a host-cable to force the ID pin low and then unplug it
and connect the tablet to a PC, to get the ACPI event handler to run and
switch the mux to device mode,
This commit fixes both by running the event-handler once on boot.
Note that the running of the event-handler is done from a late_initcall,
this is done because the handler AML code may rely on OperationRegions
registered by other builtin drivers. This avoids errors like these:
[ 0.133026] ACPI Error: No handler for Region [XSCG] ((____ptrval____)) [GenericSerialBus] (20180531/evregion-132)
[ 0.133036] ACPI Error: Region GenericSerialBus (ID=9) has no handler (20180531/exfldio-265)
[ 0.133046] ACPI Error: Method parse/execution failed \_SB.GPO2._E12, AE_NOT_EXIST (20180531/psparse-516)
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
[hdegoede: Document BYT USB mux reliance on initial trigger]
[hdegoede: Run event handler from a late_initcall, rather then immediately]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-07-12 23:25:06 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
/* We must use _sync so that this runs after the first deferred_probe run */
|
2018-11-29 00:57:55 +08:00
|
|
|
late_initcall_sync(acpi_gpio_handle_deferred_request_irqs);
|
2019-08-28 04:28:35 +08:00
|
|
|
|
2020-03-25 18:39:56 +08:00
|
|
|
static const struct dmi_system_id gpiolib_acpi_quirks[] __initconst = {
|
2019-08-28 04:28:35 +08:00
|
|
|
{
|
2019-11-06 19:51:09 +08:00
|
|
|
/*
|
|
|
|
* The Minix Neo Z83-4 has a micro-USB-B id-pin handler for
|
|
|
|
* a non existing micro-USB-B connector which puts the HDMI
|
|
|
|
* DDC pins in GPIO mode, breaking HDMI support.
|
|
|
|
*/
|
2019-08-28 04:28:35 +08:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "MINIX"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Z83-4"),
|
2020-01-06 00:03:56 +08:00
|
|
|
},
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
|
|
|
|
.no_edge_events_on_boot = true,
|
|
|
|
},
|
2019-08-28 04:28:35 +08:00
|
|
|
},
|
2019-11-06 19:51:09 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The Terra Pad 1061 has a micro-USB-B id-pin handler, which
|
|
|
|
* instead of controlling the actual micro-USB-B turns the 5V
|
|
|
|
* boost for its USB-A connector off. The actual micro-USB-B
|
|
|
|
* connector is wired for charging only.
|
|
|
|
*/
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Wortmann_AG"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "TERRA_PAD_1061"),
|
2020-01-06 00:03:56 +08:00
|
|
|
},
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
|
|
|
|
.no_edge_events_on_boot = true,
|
|
|
|
},
|
2019-11-06 19:51:09 +08:00
|
|
|
},
|
2021-04-02 00:27:40 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* The Dell Venue 10 Pro 5055, with Bay Trail SoC + TI PMIC uses an
|
|
|
|
* external embedded-controller connected via I2C + an ACPI GPIO
|
|
|
|
* event handler on INT33FFC:02 pin 12, causing spurious wakeups.
|
|
|
|
*/
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Venue 10 Pro 5055"),
|
|
|
|
},
|
|
|
|
.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
|
|
|
|
.ignore_wake = "INT33FC:02@12",
|
|
|
|
},
|
|
|
|
},
|
2020-01-06 00:03:57 +08:00
|
|
|
{
|
|
|
|
/*
|
2020-03-02 19:12:22 +08:00
|
|
|
* HP X2 10 models with Cherry Trail SoC + TI PMIC use an
|
|
|
|
* external embedded-controller connected via I2C + an ACPI GPIO
|
|
|
|
* event handler on INT33FF:01 pin 0, causing spurious wakeups.
|
|
|
|
* When suspending by closing the LID, the power to the USB
|
|
|
|
* keyboard is turned off, causing INT0002 ACPI events to
|
|
|
|
* trigger once the XHCI controller notices the keyboard is
|
|
|
|
* gone. So INT0002 events cause spurious wakeups too. Ignoring
|
|
|
|
* EC wakes breaks wakeup when opening the lid, the user needs
|
2020-01-06 00:03:57 +08:00
|
|
|
* to press the power-button to wakeup the system. The
|
|
|
|
* alternative is suspend simply not working, which is worse.
|
|
|
|
*/
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "HP"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "HP x2 Detachable 10-p0XX"),
|
|
|
|
},
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
|
|
|
|
.ignore_wake = "INT33FF:01@0,INT0002:00@2",
|
|
|
|
},
|
2020-01-06 00:03:57 +08:00
|
|
|
},
|
2020-03-02 19:12:24 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* HP X2 10 models with Bay Trail SoC + AXP288 PMIC use an
|
|
|
|
* external embedded-controller connected via I2C + an ACPI GPIO
|
|
|
|
* event handler on INT33FC:02 pin 28, causing spurious wakeups.
|
|
|
|
*/
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion x2 Detachable"),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "815D"),
|
|
|
|
},
|
|
|
|
.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
|
|
|
|
.ignore_wake = "INT33FC:02@28",
|
|
|
|
},
|
|
|
|
},
|
2020-03-02 19:12:25 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* HP X2 10 models with Cherry Trail SoC + AXP288 PMIC use an
|
|
|
|
* external embedded-controller connected via I2C + an ACPI GPIO
|
|
|
|
* event handler on INT33FF:01 pin 0, causing spurious wakeups.
|
|
|
|
*/
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "HP"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion x2 Detachable"),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "813E"),
|
|
|
|
},
|
|
|
|
.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
|
|
|
|
.ignore_wake = "INT33FF:01@0",
|
|
|
|
},
|
|
|
|
},
|
2019-08-28 04:28:35 +08:00
|
|
|
{} /* Terminating entry */
|
|
|
|
};
|
|
|
|
|
2020-03-25 18:39:56 +08:00
|
|
|
static int __init acpi_gpio_setup_params(void)
|
2019-08-28 04:28:35 +08:00
|
|
|
{
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
const struct acpi_gpiolib_dmi_quirk *quirk = NULL;
|
2020-01-06 00:03:56 +08:00
|
|
|
const struct dmi_system_id *id;
|
|
|
|
|
|
|
|
id = dmi_first_match(gpiolib_acpi_quirks);
|
|
|
|
if (id)
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
quirk = id->driver_data;
|
2020-01-06 00:03:56 +08:00
|
|
|
|
2019-08-28 04:28:35 +08:00
|
|
|
if (run_edge_events_on_boot < 0) {
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
if (quirk && quirk->no_edge_events_on_boot)
|
2019-08-28 04:28:35 +08:00
|
|
|
run_edge_events_on_boot = 0;
|
|
|
|
else
|
|
|
|
run_edge_events_on_boot = 1;
|
|
|
|
}
|
|
|
|
|
gpiolib: acpi: Rework honor_wakeup option into an ignore_wake option
Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
quirk mechanism") was added to deal with spurious wakeups on one specific
model of the HP x2 10 series.
The approach taken there was to add a bool controlling wakeup support for
all ACPI GPIO events. This was sufficient for the specific HP x2 10 model
the commit was trying to fix, but in the mean time other models have
turned up which need a similar workaround to avoid spurious wakeups from
suspend, but only for one of the pins on which the ACPI tables request
ACPI GPIO events.
Since the honor_wakeup option was added to be able to ignore wake events,
the name was perhaps not the best, this commit renames it to ignore_wake
and changes it to a string with the following format:
gpiolib_acpi.ignore_wake=controller@pin[,controller@pin[,...]]
This allows working around spurious wakeup issues on a per pin basis.
This commit also reworks the existing quirk for the HP x2 10 so that
it functions as before.
Note:
-This removes the honor_wakeup parameter. This has only been upstream for
a short time and to the best of my knowledge there are no users using
this module parameter.
-The controller@pin[,controller@pin[,...]] syntax is based on an existing
kernel module parameter using the same controller@pin format. That version
uses ';' as separator, but in practice that is problematic because grub2
cannot handle this without taking special care to escape the ';', so here
we are using a ',' as separator instead which does not have this issue.
Fixes: aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option + quirk mechanism")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200302111225.6641-2-hdegoede@redhat.com
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-02 19:12:23 +08:00
|
|
|
if (ignore_wake == NULL && quirk && quirk->ignore_wake)
|
|
|
|
ignore_wake = quirk->ignore_wake;
|
2020-01-06 00:03:57 +08:00
|
|
|
|
2019-08-28 04:28:35 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Directly after dmi_setup() which runs as core_initcall() */
|
|
|
|
postcore_initcall(acpi_gpio_setup_params);
|