[MyL5] First Impressions of Evergreen (Tim's story)

Thanks for the clarification :slight_smile: I am eager to see this in the real world :slight_smile:

I sort of disagree. I am going to be annoyed that I have to power off my device and lose my session because suspend isn’t there.

I just need suspend to ram. I don’t care if the only way to wake from that is the power button initially. This ability is about cutting the cycle of charging simply to use the device. In a day I’m rarely actually using my phone for more than 2 hours a day collectively. The power on time is good enough already.

Furthermore, given the state of the Linux phone right now, standby is just a reality of phone life. Ignoring it to chase down a rabbit hole that is infinitely deep (optimization work is NEVER done) is something that can be fully embraced when there is a reliable power saving scheme in place. This scheme is standby (suspend to RAM) for the time being. This gives you all the time in the world to develop a low power mode, or work on runtime optimization.

From the discussion above it seems that there could be different types of suspend that work best for different usage patterns. Maybe this could be something that could be configured in settings. I guess that the “low power mode” on phones is one of them. Maybe there could be several others.

I’m talking about suspend to RAM as used by Linux. Other kinds of PM like turning the cores and peripherals off while not in use are either already there or being worked on.


Wait… because I was wondering about that. I have read in several places in this forum that the CPU is working although the screen is off, and thus it consumes energy from the battery. If I manually turn of all but 1 core (leave 1 core on for handling incoming calls) using something similar to

echo 0 > /sys/devices/system/cpu/cpu2/online

will this save me power? Or the phone already does that by default?

I do agree that the energy savings are of higher priority than suspend as you say. I just wrote that it seems that nothing has been done on the suspend front so far.

1 Like

Actually this is better:

for x in /sys/devices/system/cpu/cpu*/online; do echo 0 >"$x" ; done

since cpu0 (typically) can not be turned off

@Products4People Thank you for the time taken to write that post and sharing your impressions. Wish you and all us others good luck and pleasure with our (future) Librem 5 handheld-computer.

1 Like

I think people tend to forget how rough around ALL edges were Android and iOS when they first came out. I think we, as customers first, and mostly Linux geeks second, are sometimes to harsh on people that are trying to do something new within our fav ecosystem. It might not be perfect now, but it will be soon thanks to the likes of Purism, Pine64 and the great community we all are part of.


My Android is still rough around the edges! :face_with_raised_eyebrow:


That’s a somewhat simplistic description. We do have working cpuidle in the kernel, so the cores that aren’t used shouldn’t consume much energy. However, CPU cores are far from the only things present in the whole SoC - there are many components driven by many clocks and regulators with complicated structure and dependencies. Some things can be clocked down, others can be fully disabled, for some you can even cut the power straight from the PMIC. Parts of that are already working, other parts aren’t done yet.

In my experience turning the cores off with /sys/devices/system/cpu/cpu*/online didn’t really influence power usage compared to having them still on but idle, but otoh I haven’t really made a scientific experiment and the difference may have been there but drowned in measurement noise. Anyway, you’re the root, feel free to use it if you find out it makes a difference for your use case :wink:


Reminds me of the time I first saw a “screen saver”, in the mid 1980’s, the engineer who was not using the computer at the moment said: “A busy computer is a HAPPY computer!”


You’re very welcome and your post made me realize I have been calling my Librem 5 a “Linux phone” to my social circle for the past three years. I see Purism going the “handheld computer” or “computer in your pocket” route, which is certainly true as well. I guess I’ve been hoping people would have heard of Linux but for those who never have, those other definitions may inspire their interest.

Thanks for your comment and I think that’s very true. It’s pretty sad because who would be upset at someone else who buys a new kind of phone. It’s not anything against anyone else what phone you choose to buy, for crying out loud.

Where it’s likely to make a difference is when the phone is not idle. The VRMs for the CPU have an efficiency curve, and likely the CPU cores themselves do. Hard to say if running 1 core at full speed 4x as long will use more or less energy than 4 cores 1x as long. As you say, best thing to do, if it matters, is try it and see with a particular workload.

Well, they also still mainly call it a phone. A Security & Privacy Focused Phone.
Actually, recently I thought it’s “wrong” to call Purism a Linux company or the Librem 5 a Linux phone.
Why? Well, who calls Tesla a Lithium company?

Linux is the means, but not a value in itself. One can realize that when somebody points out “But Android is also Linux!”. Then you go “But I mean… GNU/Linux… You know, pure!”
But that’s not the point.
Purism could have chosen (or could switch to) any libre OS. Of course, Linux is the natural choice.
The word Linux appears one time on the product page, and only after you scroll quite a few pages… And it makes sense. Purism doesn’t want to cater to Linux fans, but to those who desire freedom, security and privacy.
Our friends and relatives probably really don’t care much about penguins and gnus, but more and more are looking for those things, and we need to focus on them.

1 Like

It just came to my mind that it’s not entirely true - there has been some work on suspend done in the past. It needs a different ATF branch than the one we’re using right now - I know that it worked for me in the past with an older kernel (haven’t tried with recent ones). However, as it is right now it breaks the DRAM frequency scaling, which makes the device use quite a lot of power when not suspended, so that’s a rather poor tradeoff and is the reason why it’s not used at the moment. It also needs some adjustments of the device tree to make sure the modem stays on during suspend (this one shouldn’t be hard though).

You should be able to use s2idle already if you want to make sure your cores stay idle, although it seems like there’s something buggy in the USB path as suspending the USB core currently makes it consume slightly more power than when it’s on :smiley: Therefore we currently don’t suspend it at runtime at all, but it gets suspended at s2idle which makes it consume a bit more power than when not suspended. Fixing that is part of runtime power management work.

So, the first step to make s2ram a reality is to produce one common (and preferably upstreamed) ATF branch that works with both DRAM scaling and suspend. We want that to eventually happen for other reasons as well, so we’ll likely get there at some point (this is also something that NXP itself expressed interest in working on at some point, so it may even happen without our involvement giving us more time to work on phone specific stuff :)).

I disagree. It’s not just a unspecified “optimization work”, there are clear and tangible things still to be done in runtime PM - like the USB core not being suspended that I mentioned above, or DP core never suspending after the first use etc. This directly influences suspend as well, since the kernel is using the same code to shut the devices off. Since in suspend everything gets turned down at the same time, there are more opportunities to make some hacks and broad assumptions that won’t hold when suspending peripherals selectively (Librem 5’s power paths are pretty complex for a mobile phone). Therefore I believe that making sure the runtime PM is in good state before putting the focus on suspend is a better approach, since good runtime PM state makes the work on suspend much easier; while going the other way around (focusing on suspend first) may make further runtime PM work harder.

I do understand that from the user perspective it may be better to have at least some form of suspend available earlier - but that’s short-term thinking. We want to maintain software for this device for years as close to mainline as possible, so we’ll naturally gravitate towards long-term thinking and give things like ease of maintenance much greater weight than some other phone manufacturers on the market.


That makes sense. I just hope that suspend can come as it really will help workflow. Still don’t take any of my comments as an actual criticism but rather as my wishes.

1 Like

Wha? How did you get in on that you lucky dog? I was watching closely, and still missed the very small window of opportunity to buy one. Is it working? They keep talking about not having an optimized OS, and since you say you’re not a Linux guy, I’m interested in your opinion about it’s usability.

There are a lot of reviews here: http://forum.pine64.org/showthread.php?tid=11333.

Please don’t go off-topic.


My impression so far is that time-between-charges is the single biggest issue preventing this phone from being a daily driver (hence my experimentation with a spare battery and an external charger).

Hence also from a sales pipeline perspective. That too is short-term thinking, and can be ignored if you’ve got the cash or cashflow.