megi's PinePhone Development Log RSS

2023–05–22: Pinephone (Pro) power measurements and optimizations

Thanks to support of people who donate money to me, I've been able to add proper lab PSU to my home's lab equipment, and I am now able to perform Pinephone power measurements and optimizations in a much more precise and faster way than before. Thank you for your support! :)

I've used an old Pinephone battery adapter I made for my previous INA226 based power meter and hooked Pinephone Pro through it to the new bench PSU.

With this setup, I've measured Pinephone and Pinephone Pro power consumption under different situations with my latest orange-pi-6.3 Linux branch.

Last time I did similar measurements was when Pinephone Pro was initially announced a year and a half ago. I only did the measurements on the developer sample of the phone that was using RK3399 SoC, and not the power optimized RK3399S that the production variant of the phone is using. So an update is in order.

The following measurments were done on the latest version of Pinephone Pro which I have access to. It has a batch number MQ2109L2600058 printed on the sticker on the modem's metal shielding. I'm not aware whether there were any further HW revisions since then. Probably not.

How long will Pinephone last on a battery can be calculated from power consumption by dividing battery energy in mWh by the power consumption. Eg. power consumption is 1000 mW, battery capacity is 11,500 mWh, the phone will last 11.5 hours.

Please don't use mAh ratings and similar for calculations, because the phone will draw different current based on how much energy remains in the battery, so there's no straightforward way to guess how long will the battery last from that. Ceteris paribus, the power consumption stays roughly constant in the face of changing battery voltage. Use watts and watt hours, and ignore the manufacturer's use of mAh. Pinephone battery has ~11.5Wh of energy at full charge.

Power use in suspend to RAM

Pinephone Pro draws 177 mW in suspend. That's 65 hours of suspend time, if all you do is have the phone on standby. The phone's modem doesn't add any significant power consumption on top, assuming you're using the stock firmware, my modem-power driver, and have adb access to the modem disabled. I haven't tested any other combination, yet. So I can't tell you about that, but I know that keeping modem suspended and consuming as little power as possible (~10 mW as specified in the datasheet) requires careful setup.

(Without adb access disabled, modem adds 50 mW of power consumption, because having adb enabled prevents it from going to deep sleep.)

Pre-production Pinephone Pro using plain old RK3399 has power consumption in sleep of 260 mW. Quite a bit higher than RK3399S. It will be interesting to do these measurements for Pinebook Pro, which also uses RK3399 SoC.

Precision of PMIC's own measurements

Power management chip (PMIC) in the phone measures current to/from the battery by measuring a voltage drop on a shunt resistor of 10 mOhm. Looks like these measurements don't always match with the lab equipment. For example when /sys/class/power_supply/rk818-battery/current_now says 530 mA my PSU (and multimeter) measures 450 mA. That's a ~18% difference. This doesn't scale linearly with current. The percentual difference is different at diferent power consumption levels. It's more precise with higher current. That suggests not a scaling problem, but some offset problem.

Looks like ADC has to measure both positive and negative currents, and has some fixed error offset around 0 mA, that needs calibrating away. When the current is 0, the ADC will report some small positive or negative current, unless calibrated. I think this offset simply is 530 - 450 = 80 mA on my phone. Not insignificant!

The driver does some offset calibration at various points in the charging cycle, and so the precision of current measurements will likely depend on eliminating the DC offset of the ADC. It's good to know this for someone who will take on rewriting the BSP driver for upstreaming. Replacing the battery erases the store offset measurements from the PMIC memory.

Power use in idle

Pinephone Pro draws about 1500 mW in idle. By idle I mean the phone has display turned off, no processes are loading the CPU, and wifi is in power saving mode, and the user is not interacting with the phone. The phone can stay for 6.7 hours in this mode on a fully charged battery.

This mode is important to measure, because in this mode, we measure runtime power management performance of Linux drivers.

Each driver implements two kinds of power management:

• runtime PM
• system sleep

In each driver, runtime PM functions, if implemented, should power down devices that are not used at runtime, when the system is not sleeping as a whole.

System sleep functions in the driver power down devices when the whole system is going to sleep.

These two mechanisms are semi-independent, and the driver can implement one while not the other. Typically system sleep hooks will be implemented, but not the runtime PM.

Power use in suspend to idle (s2idle)

Pinephone Pro draws 1250 mW in s2idle. That's 9.2 hours of suspend time.

All s2idle does is that it tells all drivers to power down the devices in preparation for system sleep, and then it turns off all CPUs other than the first one, and makes the first CPU wait for resume interrupt from some wakeup capable device. It basically goes through all the kernel parts of system sleep cycle, but doesn't pass the control to platform firmware to bring the system to deep sleep.

The absolute numbers are not that interesting, but note the difference between idle and s2idle power consumption! This difference is 250 mW and tells us how much we can save if we identify drivers that don't implement runtime PM, and implement support for it in them.

Maximums – max LCD backlight, max CPU

With max backlight brightness, Pinephone Pro consumes 3.2W in idle and 6.7W with all CPU cores fully utilized. Yeah, don't run PPP with max backlight and all cores enabled, unless you want to discharge your battery in less than 2 hours. :)

This is something you have to optimize for yourself, because it's just a user specific setup. Kernel hacking will not help you with max load situations. Hardware simply consumes this much, when fully utilized. It can also consume more than 6.7W, when also eMMC and WiFi are utilized fully. It's not that hard to get close to 10W, when running everything at max utilization.

You'll get overheating and about 1 – 2 hour runtime on full battery.

Distributions can help here by allowing users to select different power profiles, just like on Windows laptops, and ensuring that these profiles are implemented correctly.

USB power – running Pinephone Pro without a battery (or with an empty battery)

It's possible to run Pinephone Pro from just a USB power supply.

In fact, Pinephone Pro is quite well suited for running without a battery, because unlike on the original Pinephone, WiFi and modem will still both work, when the phone is powered exclusively from the USB port.

The power supply and a USB cable has to be selected with some care, though.

Technically speaking, voltage on the USB port of the phone must not at any time drop below 4.3V (and it's better for stability if it doesn't drop below 4.5V). This is easier said than done.

You have to have USB PSU that can handle at least 2A at 5V without voltage drop and preferably more. You may also need a good quality USB Type-C cable. Any Type-C to Type-C cable that follows the Type-C specification should do, but IMMV.

Not all cables are made equal. I've tested some of my USB cables using a ~3 Ohm load which emulates a phone consuming ~6W and Pine64's default red cable that comes with the phone falls somewhere in the middle. Neither great, nor the worst. It has about 150 mOhm resistance on VBUS+GND wires. So 2A should not cause more than 0.3V drop.

If you want something more reliable, short 5A rated Type-C cable will do its job perfectly. Type-C connector has 4 contacts for VBUS and 4 contacts for groud, so it's much better than USB-A connectors which can be unreliable with just one ground and one VBUS contact where contact resistance may vary quite a bit each time you plug it in. IIRC 5A cables are designed for max 0.25V voltage drop at 5A.

In summary, if you see unreliability booting the phone without a battery, check your PSU and cables. Remove and insert them a few times to try to reduce contact resistance, etc. Or just use a full Type-C cable (C connector on both ends).

Testing battery-less boot

For this test I made a custom Type-C cable for my lab PSU…

…so I could do measurements and tests that could emulate low/no battery situations (that currently result in boot loops for users using Tow/U-Boot):

The basic limitation in this scenario is that the phone starts with a maximum limit of how much current it can draw from VBUS configured to 450 mA. Even if you have 3 A power supply, the phone will simply shut down once the 450 mA limit is crossed.

This limit is not respected by U-Boot/Tow-Boot and both of these bootloaders proceed with boot even when it's impossible it would succeed. The bootloader should instead wait for the battery to charge a bit before proceeding, like most Android and iOS based phones do. Even U-Boot can do things that will cause the phone to cross the limit, if not careful.

Linux boot is a very power hungry process, where all Linux devices are being enabled in a short period of time, data is loaded from eMMC at high speed, CPU cores are busy coordinating everything, and so on. I measured the power needed for boot of ~9W.

It needs to be explored when exactly is this limit crossed, to understand what can be done about it, and when exactly it must be raised. I'll explore that in the next post.

Anyway, with patched levinboot, Pinephone Pro runs fine without the battery down to about VBUS voltage of 4.3V, according to my measurements. It becomes unstable at 4.2V or less. Living on the edge is not advised, so let's say 4.5 V minimum on VBUS under all circumstances is a good idea if you want to run the phone in this manner long term.