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>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/errno.h>
|
2014-11-03 19:01:32 +08:00
|
|
|
#include <linux/gpio.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"
|
|
|
|
|
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;
|
2013-04-09 21:57:25 +08:00
|
|
|
unsigned int pin;
|
|
|
|
unsigned int irq;
|
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
|
|
|
/*
|
|
|
|
* For gpiochips which call acpi_gpiochip_request_interrupts() before late_init
|
|
|
|
* (so builtin drivers) we register the ACPI GpioInt event handlers from a
|
|
|
|
* late_initcall_sync handler, so that other builtin drivers can register their
|
|
|
|
* OpRegions before the event handlers can run. This list contains gpiochips
|
|
|
|
* for which the acpi_gpiochip_request_interrupts() has been deferred.
|
|
|
|
*/
|
|
|
|
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)
|
|
|
|
{
|
2015-11-04 16:56:26 +08:00
|
|
|
if (!gc->parent)
|
2012-11-30 19:37:36 +08:00
|
|
|
return false;
|
|
|
|
|
2015-11-04 16:56:26 +08:00
|
|
|
return 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
|
|
|
|
* controller does not have gpiochip registered at the moment. This is to
|
|
|
|
* 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
|
|
|
|
|
|
|
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);
|
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
static acpi_status acpi_gpiochip_request_interrupt(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;
|
|
|
|
unsigned long irqflags;
|
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
|
|
|
int ret, pin, irq, value;
|
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
|
|
|
|
2014-08-20 01:06:09 +08:00
|
|
|
desc = gpiochip_request_own_desc(chip, pin, "ACPI:Event");
|
2014-03-10 20:54:53 +08:00
|
|
|
if (IS_ERR(desc)) {
|
2015-11-04 16:56:26 +08:00
|
|
|
dev_err(chip->parent, "Failed to request GPIO\n");
|
2014-03-10 20:54:53 +08:00
|
|
|
return AE_ERROR;
|
|
|
|
}
|
2013-01-28 22:23:10 +08:00
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
gpiod_direction_input(desc);
|
2013-01-28 22:23:10 +08:00
|
|
|
|
2018-08-14 00:00:27 +08:00
|
|
|
value = gpiod_get_value_cansleep(desc);
|
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-10-23 16:27:07 +08:00
|
|
|
ret = gpiochip_lock_as_irq(chip, pin);
|
2014-03-10 20:54:53 +08:00
|
|
|
if (ret) {
|
2015-11-04 16:56:26 +08:00
|
|
|
dev_err(chip->parent, "Failed to lock GPIO as interrupt\n");
|
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) {
|
2015-11-04 16:56:26 +08:00
|
|
|
dev_err(chip->parent, "Failed to translate GPIO to IRQ\n");
|
2014-03-10 20:54:53 +08:00
|
|
|
goto fail_unlock_irq;
|
|
|
|
}
|
2013-04-09 21:57:25 +08:00
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
irqflags = IRQF_ONESHOT;
|
|
|
|
if (agpio->triggering == ACPI_LEVEL_SENSITIVE) {
|
|
|
|
if (agpio->polarity == ACPI_ACTIVE_HIGH)
|
|
|
|
irqflags |= IRQF_TRIGGER_HIGH;
|
|
|
|
else
|
|
|
|
irqflags |= IRQF_TRIGGER_LOW;
|
|
|
|
} else {
|
|
|
|
switch (agpio->polarity) {
|
|
|
|
case ACPI_ACTIVE_HIGH:
|
|
|
|
irqflags |= IRQF_TRIGGER_RISING;
|
|
|
|
break;
|
|
|
|
case ACPI_ACTIVE_LOW:
|
|
|
|
irqflags |= IRQF_TRIGGER_FALLING;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
irqflags |= IRQF_TRIGGER_RISING |
|
|
|
|
IRQF_TRIGGER_FALLING;
|
|
|
|
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 = kzalloc(sizeof(*event), GFP_KERNEL);
|
|
|
|
if (!event)
|
|
|
|
goto fail_unlock_irq;
|
2013-04-09 21:57:25 +08:00
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
event->handle = evt_handle;
|
|
|
|
event->irq = irq;
|
|
|
|
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
|
|
|
ret = request_threaded_irq(event->irq, NULL, handler, irqflags,
|
|
|
|
"ACPI:Event", event);
|
|
|
|
if (ret) {
|
2015-11-04 16:56:26 +08:00
|
|
|
dev_err(chip->parent,
|
|
|
|
"Failed to setup interrupt handler for %d\n",
|
2014-03-10 20:54:53 +08:00
|
|
|
event->irq);
|
|
|
|
goto fail_free_event;
|
2013-01-28 22:23:10 +08:00
|
|
|
}
|
2014-03-10 20:54:53 +08:00
|
|
|
|
2017-03-24 18:08:47 +08:00
|
|
|
if (agpio->wake_capable == ACPI_WAKE_CAPABLE)
|
|
|
|
enable_irq_wake(irq);
|
|
|
|
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure we trigger the initial state of the IRQ when using RISING
|
|
|
|
* or FALLING. Note we run the handlers on late_init, the AML code
|
|
|
|
* may refer to OperationRegions from other (builtin) drivers which
|
|
|
|
* may be probed after us.
|
|
|
|
*/
|
2018-08-14 22:07:03 +08:00
|
|
|
if (((irqflags & IRQF_TRIGGER_RISING) && value == 1) ||
|
|
|
|
((irqflags & IRQF_TRIGGER_FALLING) && value == 0))
|
|
|
|
handler(event->irq, event);
|
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_free_event:
|
|
|
|
kfree(event);
|
|
|
|
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);
|
|
|
|
|
|
|
|
return AE_ERROR;
|
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
|
|
|
|
* 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-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-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;
|
|
|
|
|
2015-03-11 06:10:01 +08:00
|
|
|
acpi_walk_resources(handle, "_AEI",
|
2014-03-10 20:54:53 +08:00
|
|
|
acpi_gpiochip_request_interrupt, acpi_gpio);
|
|
|
|
}
|
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) {
|
2014-03-10 20:54:53 +08:00
|
|
|
struct gpio_desc *desc;
|
|
|
|
|
2017-03-24 18:08:47 +08:00
|
|
|
if (irqd_is_wakeup_set(irq_get_irq_data(event->irq)))
|
|
|
|
disable_irq_wake(event->irq);
|
|
|
|
|
2014-03-10 20:54:53 +08:00
|
|
|
free_irq(event->irq, event);
|
2014-08-20 01:06:08 +08:00
|
|
|
desc = event->desc;
|
2014-03-10 20:54:53 +08:00
|
|
|
if (WARN_ON(IS_ERR(desc)))
|
|
|
|
continue;
|
2014-10-23 16:27:07 +08:00
|
|
|
gpiochip_unlock_as_irq(chip, event->pin);
|
2014-03-10 20:54:53 +08:00
|
|
|
gpiochip_free_own_desc(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);
|
|
|
|
|
2017-03-02 21:48:05 +08:00
|
|
|
static void devm_acpi_dev_release_driver_gpios(struct device *dev, void *res)
|
|
|
|
{
|
|
|
|
acpi_dev_remove_driver_gpios(ACPI_COMPANION(dev));
|
|
|
|
}
|
|
|
|
|
|
|
|
int devm_acpi_dev_add_driver_gpios(struct device *dev,
|
|
|
|
const struct acpi_gpio_mapping *gpios)
|
|
|
|
{
|
|
|
|
void *res;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
res = devres_alloc(devm_acpi_dev_release_driver_gpios, 0, GFP_KERNEL);
|
|
|
|
if (!res)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), gpios);
|
|
|
|
if (ret) {
|
|
|
|
devres_free(res);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
devres_add(dev, res);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(devm_acpi_dev_add_driver_gpios);
|
|
|
|
|
|
|
|
void devm_acpi_dev_remove_driver_gpios(struct device *dev)
|
|
|
|
{
|
|
|
|
WARN_ON(devres_release(dev, devm_acpi_dev_release_driver_gpios, NULL, NULL));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(devm_acpi_dev_remove_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-05-24 01:03:22 +08:00
|
|
|
static enum gpiod_flags
|
|
|
|
acpi_gpio_to_gpiod_flags(const struct acpi_resource_gpio *agpio)
|
|
|
|
{
|
|
|
|
bool pull_up = agpio->pin_config == ACPI_PIN_CONFIG_PULLUP;
|
|
|
|
|
|
|
|
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
|
|
|
|
* instead. If the pin is pulled up we assume default to be
|
|
|
|
* high, otherwise low.
|
|
|
|
*/
|
|
|
|
return pull_up ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
|
|
|
|
default:
|
|
|
|
/*
|
|
|
|
* Assume that the BIOS has configured the direction and pull
|
|
|
|
* accordingly.
|
|
|
|
*/
|
|
|
|
return GPIOD_ASIS;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
|
|
|
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;
|
|
|
|
*flags = update;
|
|
|
|
}
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2013-04-03 18:56:54 +08:00
|
|
|
struct acpi_gpio_lookup {
|
|
|
|
struct acpi_gpio_info info;
|
|
|
|
int 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
|
|
|
int 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;
|
|
|
|
|
2013-10-10 16:01:08 +08:00
|
|
|
if (lookup->n++ == lookup->index && !lookup->desc) {
|
2013-04-03 18:56:54 +08:00
|
|
|
const struct acpi_resource_gpio *agpio = &ares->data.gpio;
|
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
|
|
|
int pin_index = lookup->pin_index;
|
|
|
|
|
|
|
|
if (pin_index >= agpio->pin_table_length)
|
|
|
|
return 1;
|
2013-04-03 18:56:54 +08:00
|
|
|
|
2013-10-10 16:01:08 +08:00
|
|
|
lookup->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]);
|
2013-04-03 18:56:54 +08:00
|
|
|
lookup->info.gpioint =
|
|
|
|
agpio->connection_type == ACPI_RESOURCE_GPIO_TYPE_INT;
|
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) {
|
2017-05-24 01:03:23 +08:00
|
|
|
lookup->info.flags = GPIOD_IN;
|
2015-12-24 06:25:34 +08:00
|
|
|
lookup->info.polarity = agpio->polarity;
|
|
|
|
lookup->info.triggering = agpio->triggering;
|
2017-05-24 01:03:23 +08:00
|
|
|
} else {
|
|
|
|
lookup->info.flags = acpi_gpio_to_gpiod_flags(agpio);
|
2017-11-10 21:40:28 +08:00
|
|
|
lookup->info.polarity = lookup->active_low;
|
2015-12-24 06:25:34 +08:00
|
|
|
}
|
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).
|
|
|
|
*
|
2013-10-10 16:01:08 +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
|
|
|
|
2015-08-27 10:41:33 +08:00
|
|
|
dev_dbg(&adev->dev, "GPIO: _DSD returned %s %d %d %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
|
|
|
|
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,
|
2016-10-03 16:40:03 +08:00
|
|
|
enum gpio_lookup_flags *lookupflags)
|
|
|
|
{
|
|
|
|
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)) {
|
2017-05-24 01:03:18 +08:00
|
|
|
dev_dbg(dev, "refusing GpioInt() entry when doing GPIOD_OUT_* lookup\n");
|
|
|
|
return ERR_PTR(-ENOENT);
|
2016-10-03 16:40:03 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (info.polarity == GPIO_ACTIVE_LOW)
|
|
|
|
*lookupflags |= GPIO_ACTIVE_LOW;
|
|
|
|
|
2017-11-10 21:40:31 +08:00
|
|
|
acpi_gpio_update_gpiod_flags(dflags, &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)
|
|
|
|
*
|
|
|
|
* If @fwnode is an ACPI device object, call %acpi_get_gpiod_by_index() for it.
|
|
|
|
* Otherwise (ie. it is a data-only non-device object), use the property-based
|
|
|
|
* GPIO lookup to get to the GPIO resource with the relevant information and use
|
|
|
|
* that to obtain the GPIO descriptor to return.
|
|
|
|
*/
|
|
|
|
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
|
|
|
/**
|
|
|
|
* acpi_dev_gpio_irq_get() - Find GpioInt and translate it to Linux IRQ number
|
|
|
|
* @adev: pointer to a ACPI device to get IRQ from
|
|
|
|
* @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.
|
|
|
|
*
|
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
|
|
|
*/
|
|
|
|
int acpi_dev_gpio_irq_get(struct acpi_device *adev, int index)
|
|
|
|
{
|
|
|
|
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;
|
|
|
|
|
|
|
|
desc = acpi_get_gpiod_by_index(adev, NULL, 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) {
|
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;
|
|
|
|
|
2017-05-24 01:03:23 +08:00
|
|
|
snprintf(label, sizeof(label), "GpioInt() %d", index);
|
|
|
|
ret = gpiod_configure_flags(desc, label, 0, info.flags);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2015-12-24 06:25:34 +08:00
|
|
|
irq_flags = acpi_dev_get_irq_type(info.triggering,
|
|
|
|
info.polarity);
|
|
|
|
|
|
|
|
/* Set type if specified and different than the current one */
|
|
|
|
if (irq_flags != IRQ_TYPE_NONE &&
|
|
|
|
irq_flags != irq_get_trigger_type(irq))
|
|
|
|
irq_set_irq_type(irq, irq_flags);
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(acpi_dev_gpio_irq_get);
|
|
|
|
|
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;
|
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 pin_index = (int)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;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
length = min(agpio->pin_table_length, (u16)(pin_index + bits));
|
|
|
|
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.
|
|
|
|
*/
|
|
|
|
if (!found && agpio->sharable == ACPI_SHARED &&
|
|
|
|
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) {
|
2017-05-24 01:03:22 +08:00
|
|
|
enum gpiod_flags flags = acpi_gpio_to_gpiod_flags(agpio);
|
|
|
|
const char *label = "ACPI:OpRegion";
|
|
|
|
int err;
|
|
|
|
|
|
|
|
desc = gpiochip_request_own_desc(chip, pin, label);
|
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
|
|
|
status = AE_ERROR;
|
|
|
|
mutex_unlock(&achip->conn_lock);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2017-05-24 01:03:22 +08:00
|
|
|
err = gpiod_configure_flags(desc, label, 0, flags);
|
|
|
|
if (err < 0) {
|
|
|
|
status = AE_NOT_CONFIGURED;
|
|
|
|
gpiochip_free_own_desc(desc);
|
|
|
|
mutex_unlock(&achip->conn_lock);
|
|
|
|
goto out;
|
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 = kzalloc(sizeof(*conn), GFP_KERNEL);
|
|
|
|
if (!conn) {
|
|
|
|
status = AE_NO_MEMORY;
|
|
|
|
gpiochip_free_own_desc(desc);
|
|
|
|
mutex_unlock(&achip->conn_lock);
|
|
|
|
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)
|
2014-05-20 17:07:38 +08:00
|
|
|
gpiod_set_raw_value_cansleep(desc,
|
|
|
|
!!((1 << i) & *value));
|
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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-10-30 00:13:12 +08:00
|
|
|
static struct gpio_desc *acpi_gpiochip_parse_own_gpio(
|
|
|
|
struct acpi_gpio_chip *achip, struct fwnode_handle *fwnode,
|
|
|
|
const char **name, unsigned int *lflags, unsigned int *dflags)
|
2016-10-21 22:21:30 +08:00
|
|
|
{
|
|
|
|
struct gpio_chip *chip = achip->chip;
|
|
|
|
struct gpio_desc *desc;
|
|
|
|
u32 gpios[2];
|
|
|
|
int ret;
|
|
|
|
|
2016-11-08 21:40:06 +08:00
|
|
|
*lflags = 0;
|
|
|
|
*dflags = 0;
|
|
|
|
*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) {
|
|
|
|
unsigned int lflags, dflags;
|
|
|
|
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;
|
|
|
|
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;
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
status = acpi_attach_data(handle, acpi_gpio_chip_dh, acpi_gpio);
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2016-10-21 22:21:32 +08:00
|
|
|
if (!chip->names)
|
2017-12-15 22:02:33 +08:00
|
|
|
devprop_gpiochip_set_names(chip, dev_fwnode(chip->parent));
|
2016-10-21 22:21:32 +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
|
|
|
acpi_gpiochip_request_regions(acpi_gpio);
|
2016-10-21 22:21:30 +08:00
|
|
|
acpi_gpiochip_scan_gpios(acpi_gpio);
|
2016-06-15 14:47:51 +08:00
|
|
|
acpi_walk_dep_device_list(handle);
|
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
|
|
|
|
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;
|
|
|
|
/* Fallthrough */
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* acpi_gpio_count - return the number of GPIOs associated with a
|
|
|
|
* device / function or -ENOENT if no GPIO has been
|
|
|
|
* assigned to the requested function.
|
|
|
|
* @dev: GPIO consumer, can be NULL for system-global GPIOs
|
|
|
|
* @con_id: function within the GPIO consumer
|
|
|
|
*/
|
|
|
|
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
|
|
|
|
|
|
|
bool acpi_can_fallback_to_crs(struct acpi_device *adev, const char *con_id)
|
|
|
|
{
|
|
|
|
/* Never allow fallback if the device has properties */
|
|
|
|
if (adev->data.properties || adev->driver_gpios)
|
|
|
|
return false;
|
|
|
|
|
gpio: acpi: Even more tighten up ACPI GPIO lookups
The commit 10cf4899f8af ("gpiolib: tighten up ACPI legacy gpio lookups")
prevents to getting same resource twice if the driver asks twice using
different connection ID.
But the whole idea of fallback might bring some problems. Imagine the case when
we have two versions of BIOS/hardware where in one _DSD is introduced along
with GPIO resources, but the other one uses just plain GPIO resource for
another purpose
Case 1:
Device (DEVX)
{
...
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"some-gpios", Package() {^DEVX, 0, 0, 0 }},
}
})
}
Case 2:
Device (DEVX)
{
...
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27}
})
}
To prevent the possible misconfiguration tighten up even more GPIO ACPI lookups
for case without connection ID provided.
In the past the issue had been triggered by "use mctrl_gpio helpers" series
[1,2].
[1] commit 4ef03d328769 ("tty/serial/8250: use mctrl_gpio helpers")
[2] https://patchwork.kernel.org/patch/9283745/
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-05-24 01:03:19 +08:00
|
|
|
return con_id == NULL;
|
2015-11-12 03:45:30 +08:00
|
|
|
}
|
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
|
|
|
/* Run deferred acpi_gpiochip_request_interrupts() */
|
|
|
|
static int acpi_gpio_handle_deferred_request_interrupts(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,
|
|
|
|
deferred_req_irqs_list_entry) {
|
|
|
|
acpi_handle handle;
|
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
|
|
|
handle = ACPI_HANDLE(acpi_gpio->chip->parent);
|
|
|
|
acpi_walk_resources(handle, "_AEI",
|
|
|
|
acpi_gpiochip_request_interrupt, acpi_gpio);
|
|
|
|
|
|
|
|
list_del_init(&acpi_gpio->deferred_req_irqs_list_entry);
|
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
|
|
|
|
|
|
|
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-08-14 22:07:03 +08:00
|
|
|
late_initcall_sync(acpi_gpio_handle_deferred_request_interrupts);
|