Shutdown all but one CPU cores on screen off

[XaviDCR92]

Overview

This PR attempts to reduce power consumption by powering down all but one CPU cores while the device remains awake, yet inactive. Then, once the user interacts with the device again, all CPU cores are powered back on.

Notes

While this should reduce power consumption to some degree, I am unsure of how much actual power is saved on the PinePhone. Some quick experiments did not show a noticeable improvement, but YMMV.

[milky-sway]

Sorry, have been quite busy in the past weeks.
Do you still use this script? If so, how is your experience regarding the power savings? Does everything else behave normally (e.g. receiving a call)?
Will test it in every day use in the next couple of days.
Thank you.

[XaviDCR92]

Do you still use this script?

I am using a slightly modified version of this script, with fine-tuned values for SLEEP_SECS_INIT, SLEEP_STEP, SLEEP_MAX_SECS and WAKE_SECS, according to own experience. Also, I have disabled some features that were not so interesting for me, such as notification LED or single CPU core use (see notes below).

If so, how is your experience regarding the power savings?

I am using the modified version above everyday, and is a good compromise between convenience and battery life. Typically, battery would last around 12-20 hours with light-medium usage, which is a lot more than compared to no suspend (and runs noticeably cooler, too), although less compared to keeping the phone suspended until the power button is pressed.

Surprisingly, the power saving feature suggested on this PR was not very useful to me, due to the following reasons:

• Consumed power and heat dissipation was similar (if not worse) with 1 CPU core. I have used the following script to print real-time power usage over stdout.
• The phone would take several seconds to wake up from suspend when running on a single CPU core, which was a bit inconvenient, compared to its increased responsiveness with all CPU cores active.

Does everything else behave normally (e.g. receiving a call)?

Calls and SMS are working fine so far. However, the Quectel EG25 modem on the PinePhone is known to be buggy, so the modem might crash more often, compared to no suspend. According to own experience, surprisingly modem crashes seem to occur more often when on the go.

As a workaround, I have written the following script, which restarts eg25-manager if the modem crashes. I did not work so well for Manjaro + Phosh, but works like a charm on Arch Linux + Phosh, so I do not have to worry about modem crashes any more.

OTOH, I am using some applications, such as Dino, which take a significant amount of time to receive incoming messages for some reason unrelated to sleepwalk, so I had to assign WAKE_SECS to a value higher than I would like to. Hopefully, these issues are solved anytime soon so as to keep WAKE_SECS as low as possible and thus increase battery life.

Sometimes though, the phone crashes when entering suspend and thus is unable to wake up, even if the power button is pressed. Typically, the phone would sleep for a specific amount of time and then wake up, as shown below:

Apr 08 15:42:26 danctnix sleepwalk[2955]: Sleeping for 90s
Apr 08 15:42:26 danctnix kernel: PM: suspend entry (deep)
Apr 08 15:43:57 danctnix kernel: Filesystems sync: 0.054 seconds
Apr 08 15:43:57 danctnix kernel: Freezing user space processes ... (elapsed 0.018 seconds) done.

However, sometimes it cannot wake up and thus must be force-restarted. For example, as shown below, the phone crashed at Apr 08 14:48:37 and did not report anything else on journalctl until rebooted.

Apr 08 14:48:37 danctnix sleepwalk[2977]: Sleeping for 90s
Apr 08 14:48:37 danctnix kernel: PM: suspend entry (deep)
-- Boot 8657034898c54b2d83e3c0b14e715531 --
Apr 08 15:37:09 danctnix kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034]

In any case, I assume this issue is not related to sleepwalk, but possibly crust.

[milky-sway]

Thanks for your answer.

I have mostly the same issues as you. Unfortunately we have to deal with this modem on the pinephone pro, too (currently collecting dust in my closet). But I'm hoping that the open source driver will mature in the future. I will try your modem-restart script and see how it works for me. I'm using arch linux arm, too.

The 30 seconds wake time is ok for me (using mainly telegram-desktop for messaging). Usually I get my messages within 10-15 seconds I think. Since the script does now detect receiving notifications we could implement some sort of smart waiting depending on the wait time of previous cycles someday.

A small note to your modified version of the script: You seem to check /sys/class/power_supply/axp20x-battery/status to detect, if the pinephone is charging or not. This will however report Discharging when the pinephone is charged 100%, but still connected to a charger. The solution is to check /sys/class/power_supply/axp20x-usb/online instead (1, when charger is plugged in, 0, when not).

[milky-sway]

Closing this pull request, because it isn't useful.

[XaviDCR92]

A small note to your modified version of the script: You seem to check /sys/class/power_supply/axp20x-battery/status to detect, if the pinephone is charging or not. This will however report Discharging when the pinephone is charged 100%, but still connected to a charger. The solution is to check /sys/class/power_supply/axp20x-usb/online instead (1, when charger is plugged in, 0, when not).

Good point! I had just realized about this behaviour.