Re: Intel SunrisePoint GPIO used as GpioInt in ACPI stuck in "mode 1" rather then configured as GPIO?

[Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>]

On Mon, Mar 26, 2018 at 04:54:24PM +0200, Hans de Goede wrote:
> Hi All,
> 
> So this story starts with a touchpad problem:
> https://bugzilla.redhat.com/show_bug.cgi?id=1543769
> 
> (various logs, etc. are there).
> 
> Which we believe we've pinned down to the interrupt not
> working (it seems to fire all the time).
> 
> Which is where things get strange, the interrupt is described in the DSTD as:
> 
>             Name (SBFG, ResourceTemplate ()
>             {
>                 GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000
>                     "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
>                     )
>                     {   // Pin list
>                         0x0000
>                     }
>             })
> 
> Where some later code patches the pin number, using
> a variable from nvram, so we don't get the pin here.
> 
> /proc/interrupts has:
> 
> 
>             CPU0       CPU1       CPU2       CPU3
> 135:     249595          0          0          0  intel-gpio  129  ELAN1200:00
> 
> I don't see any funny pinmapping going on in the sunrisepoint code,
> so I believe that we are using pin 129, then looking at the pinctrl
> info we get:
> 
> cat /sys/kernel/debug/pinctrl/INT345D:00/pins gives:
> 
> pin 129 (L_BKLTEN) mode 1 0x40800500 0x00000039
> 
> Which is weird because intel_gpio_irq_type() calls
> intel_gpio_set_gpio_mode().
> 
> I've asked the reported to add an explicit
> 
> 	irq_set_irq_type(client->irq, IRQ_TYPE_EDGE_FALLING);
> 
> Call to the i2c-hid driver which is in use for this device, and
> then things change to:
> 
> pin 129 (L_BKLTEN) mode 1 0x42800500 0x00000039
> 
> So we do have the right pin, but it seems stuck in mode 1 and
> seems to ignore the writes trying to change it to a GPIO?
>
> Any idea how to further debug this?

Can you ask the reporter to apply following patch and attach dmesg to
the bug? It should show the correct pin number just in case it is
different from 129.

> Could it be that pin 129 is special and cannot be configured
> as a regular GPIO, maybe the DSDT is somehow broken and giving
> us the wrong pin?

IIRC there are some pins that are only GPIOs and thus their native mode
is the same as GPIO mode but not sure if that's the case here.

diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index e2232cbcec8b..8b38720cca28 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -750,6 +750,9 @@ int acpi_dev_gpio_irq_get(struct acpi_device *adev, int index)
 			if (irq < 0)
 				return irq;
 
+			dev_info(&adev->dev, "GPIO at _CRS index %d=%d (IRQ %d)\n",
+				 index, desc_to_gpio(desc), irq);
+
 			snprintf(label, sizeof(label), "GpioInt() %d", index);
 			ret = gpiod_configure_flags(desc, label, 0, info.flags);
 			if (ret < 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html