On Sun, Apr 26, 2020 at 11:58 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > On some X86 devices we do not register an input-device, because the > power-button is also handled by the soc_button_array (GPIO) input driver, > and we want to avoid reporting power-button presses to userspace twice. > > Sofar when we did this we also did not register our interrupt handlers, > since those were only necessary to report input events. > > But on at least 2 device models the Medion Akoya E1239T and the GPD win, > the GPIO pin used by the soc_button_array driver for the power-button > cannot wakeup the system from suspend. Why this does not work is not clear, > I've tried comparing the value of all relevant registers on the Cherry > Trail SoC, with those from models where this does work. I've checked: > PMC registers: FUNC_DIS, FUNC_DIS2, SOIX_WAKE_EN, D3_STS_0, D3_STS_1, > D3_STDBY_STS_0, D3_STDBY_STS_1; PMC ACPI I/O regs: PM1_STS_EN, GPE0a_EN > and they all have identical contents in the working and non working cases. > I suspect that the firmware either sets some unknown register to a value > causing this, or that it turns off a power-plane which is necessary for > GPIO wakeups to work during suspend. > > What does work on the Medion Akoya E1239T is letting the AXP288 wakeup > the system on a power-button press (the GPD win has a different PMIC). > > Move the registering of the power-button press/release interrupt-handler > from axp20x_pek_probe_input_device() to axp20x_pek_probe() so that the > PMIC will wakeup the system on a power-button press, even if we do not > register an input device. > > Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> Looks good to me. Acked-by: Chen-Yu Tsai <wens@xxxxxxxx>
