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

[Hans de Goede <hdegoede@xxxxxxxxxx>]

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?

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?

Regards,

Hans


--
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