Power consumption and suspend to ram

[robt]

The battery life of my PBP is really good, I get 8+ hours with my usage (browsing, bit of vnc, paying attention to brightness levels).

However, I have some problems with suspend to ram.
First, it wasn't always going into suspend to ram, though since some updates yesterday, this seems to have been fixed.

Second, when suspending to ram, after 2.5 hrs the battery still lost about 13% (82% to 69%), so that's barely better than keeping it running.

Is that normal?

The reason I ask: I have a Huawei tablet (M5 Lite) which runs seemingly forever, but also when just leaving it, it does fetch update information (so at some point wifi and other stuff is somewhat active), but otherwise it will lose about 20% in a week or more. I unplugged it this morning and it just sat idle all day, and just now it still has 100% charge...

Then another question: is it possible to do a suspend to disk? Or are there special reasons why that isn't recommended?
On my commute, there's a crap data connection, so I'd like to load a bunch of webpages at home or at work, then read on the go. With suspend to ram consuming a lot of battery, esp. when forgetting about it at work, I'll be stuck with a dead battery...

Any thoughts?




[Edit 2020-06-21 after getting proper suspend to ram working]

I got my Pinebook Pro in May 2020, these fixes are therefore for an ootb Manjaro 19 PBP.
With the guidance in this thread below I managed to get to where I'm at now.

My PBP is up to date in terms of software updates, so it already runs kernel 5.7.0-1-MANJARO-ARM. Kernel 5.6+ is one of the prerequisites for proper suspend to ram.

With dmesg and journalctl -f I could figure out that the sleep mode (closing the lid or Fn+ESC = Zz) was indeed not really suspend to ram.

I modified /etc/systemd/sleep.conf
#SuspendState=freeze
SuspendState=mem
and disallowed any Hibernate lines, not sure if that would be necessary, so just in case.

I installed bsp uboot, package name and version: uboot-pinebookpro-bsp (1.5-7), which tells me this at the end of the installation:
A new U-Boot version needs to be flashed our install drive. Please use lsblk to determine your drive, before proceeding.
You can do this by running:
# dd if=/boot/idbloader.img of=/dev/mmcblkX seek=64 conv=notrunc
# dd if=/boot/uboot.img of=/dev/mmcblkX seek=16384 conv=notrunc
# dd if=/boot/trust.img of=/dev/mmcblkX seek=24576 conv=notrunc
Transaction successfully finished.

lsblk outputs this:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk2 179:0 0 58.2G 0 disk
├─mmcblk2p1 179:1 0 213.6M 0 part /boot
└─mmcblk2p2 179:2 0 58G 0 part /
mmcblk2boot0 179:32 0 4M 1 disk
mmcblk2boot1 179:64 0 4M 1 disk
zram0 252:0 0 5.6G 0 disk [SWAP]

So then I had to do this:
# dd if=/boot/idbloader.img of=/dev/mmcblk2 seek=64 conv=notrunc
# dd if=/boot/uboot.img of=/dev/mmcblk2 seek=16384 conv=notrunc
# dd if=/boot/trust.img of=/dev/mmcblk2 seek=24576 conv=notrunc

after which a reboot got me to functional suspend to ram - I can see that the CPUs are put to sleep with journalctl, and overnight, the battery lost less than 3%.

[z4v4l]

Suspend to RAM and hibernation are ACPI things. Rockchip hasn't worried to provide a proper ACPI (any) for their SoCs yet, so I hardly believe what you see is really S3/S4. it's just poor mimicking. According to ACPI, in all sleep (S) states, the CPU IS NOT RUNNING at all. not idling, but exactly not running. so if you see battery is draining in this "fake" STR, you see a poor imitation of ACPI states in ARM linux. And of course, there should not be any discouraging on using hibernation, if you have an HDD, why not, it's cool? in case of specifically PBP, writing 4GB of hibernation file into a small eMMC may be not desirable because of wearing out. but, if you attached something beefier, then why not? again, if you don't see it present, that means linux doesn't have it. uboot doesn't have it. nothing of the software does have it.

[jiyong]

But the interesting thing is that the original Samsung Chromebook Plus is also using the RockChip RK3399 and Google has implemented the sleep states in ChromeOS.
Now if we only could see how they did that.

[robt]

I came across this after posting yesterday:

[link]https://forum.manjaro.org/t/working-on-suspend-to-disk-on-pinebook-1080p/104763[/link]

So it seems that suspend to disk isn't trivial on ARM.
And indeed it seems that suspend to ram / sleep is not putting the cpu to sleep...
Now I'm off looking for a plugin for firefox that saves all pages / cache so that it opens it up again when restarting...

(I could also use some tips on how to include clickable links...)

[Syonyk]

It's possible to suspend to RAM such that it doesn't use much power. You'll need the BSP uboot images (not the mainline ones), and either the BSP 4.4 kernel, or the latest 5.7 development kernel that's being worked on.

I've got mine to a point where it uses about 2% battery sitting asleep overnight, which I consider entirely sane, but it was far from a easy process to get there.

I'm working on a tutorial to do it with Ubuntu, but it's definitely not a "just works out of the box" thing for all the distros.

https://forum.pine64.org/showthread.php?tid=10228 has some discussion on it - that's where I've been doing some of my work.

[wdt]

Manjaro 19.12 has perfectly good s3,, suspend to ram
There were 2 edits to make it work, don't remember now, 2+ months ago
6-7% per day, quite adequate
uptime 21 days, a few hours

[robt]

I'm using Manjaro (preinstalled) and I don't get such good times. Like I wrote, my PBP loses over 10% in clearly under 3 hrs. 6 to 7% per day would be totally fine for me.
It's now at 85%, I'll check again in the morning (it's 1am in my time zone - time for bed).

[Syonyk]

What's your /sys/power/mem_sleep file say? If it's using that much power, it's probably selected s2idle instead of deep. Your power numbers are consistent with suspend to idle, which isn't a deep sleep state at all.

[robt]

That file says:
s2idle [deep]

Which I think means that deep sleep is selected... How does one change the mode?

Now after about 9 hours of sleep, my PBP has lost 40%, it's at 42% down from 82. I'd be really happy with less than 10% per day/24hrs...

[Syonyk]

Yes, that means deep sleep is selected. I think there are some other config files over in /etc/systemd that relate to sleep as well, but I'm not sure of the specifics - I'll have to look and see what mine are.