Looks like unless we hit a deeper idle state first via PM runtime, any following suspend will fail to wake to a UART keypress. Allowing the system to hit a deeper idle state first via PM runtime will fix the problem. It seems there is a state somewhere saved and restored by suspend resume cycle that gets cleared by PM runtime autoidle entering deeper idle states. This can be reproduced on at least 37xx-evm with the following script: #!/bin/bash # # Disable autoidle to prevent system entering deeper idle states # before the first suspend as this exposes the bug. # uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d) for uart in $uarts; do echo -1 > $uart/autosuspend_delay_ms 2>&1 done uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null) for uart in $uarts; do echo enabled > $uart/wakeup 2>&1 echo auto > $uart/control 2>&1 done # # Unless we hit a deeper idle state via PM runtime autoidle first, # any following suspend fails to wake up from a console UART key # press and only wakes to the rtcwake below. # echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode rtcwake -m mem -s 5 echo Woke up echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode
Actually the above scripts wakes up just fine as it sets the off mode for suspend. It's the retention suspend mode that fails, updated test script below: #!/bin/bash # # Disable autoidle to prevent system entering deeper idle states # before the first suspend as this exposes the bug. # uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d) for uart in $uarts; do echo -1 > $uart/autosuspend_delay_ms 2>&1 done uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null) for uart in $uarts; do echo enabled > $uart/wakeup 2>&1 echo auto > $uart/control 2>&1 done # # Unless we hit a deeper idle state via PM runtime autoidle first, # any following suspend fails to wake up from a console UART key # press and only wakes to the rtcwake below. # echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode rtcwake -m mem -s 5 echo Woke up