On Thu, Jul 27, 2023 at 03:15:46PM +0000, Salil Mehta wrote:
Hmm. I would have thought the keyboard etc. should contribute to those interrupts by default (isn't it?) or do we need to explicitly configure the devices for their interrupts to be use in wakeup from s2idle?
Hmm, when you say keyboard here, do you mean the serial console or does QEMU emulate a keyboard device ? If latter, then yes but better to check if the device is configured as wakeup source, the keyboard/pad DT node must have the "wakeup-source" property. If former, try if no_console_suspend in the cmdline(or something similar) helps. Again need to check if it is enabled as wakeup source.(HINT: check /sys/class/wakeup/wakeup*/device/power/wakeup)
Typically I use RTC on systems as I need not physical access to the platform to test that. $echo +20 > /sys/class/rtc/rtc0/wakealarm $ echo mem > /sys/power/state
This might not work as after putting the VM into s2idle state VM kind of hangs and becomes unresponsive. I would assume that keyboard interrupts are not being considered for waking-up the VM here either.
What are the keyboards you are referring here ? Just serial port input or emulated keyboards ?
I can see RTC is configured by Qemu/VMM during init.
Good, Jean-Philippe confirms atleast RTC is working in QEMU as wakeup source.
Not sure if RTC is available on your system/VM. You just need to find a working wakeup source for your experiment.
Sorry if you have already tried that and seeing issues. You may have just missed to list it here. Thought I will check. The timer are also disabled during any system level sleeps and hence can't wake up without a valid working wakeup source unlike the normal CPU sleep/idle states.
So something like "system_wakeup" from qemu prompt seems to be the way but It looks this is not enabled in Qemu due to missing ACPI handling. Need to dig this further.
Yes ACPI is a different story. Not sure if you have RTC driver support for ACPI, need to check.
Also make sure all the drivers have working suspend resume routines, sometimes the driver resume fails and if the console is not yet resumed at that point, you get no logs.
Good point. This could be a possibility.
Let me know if you need any help.