On Mon, May 04, 2020 at 02:08:42PM +0800, Chen-Yu Tsai wrote: > 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> Applied, thank you. -- Dmitry
