Improvement / Optimizations on the heating / power consumption

[EvilDragon]

Okay, I'm not sure if I should post this here on the boards or in the kernel mailing list... but if no one really has any ideas here, I'll try the mailing list

This post is probably one for experienced devs and Linux users.

What's it all about?

Well, we all know that the Pyra eats quite a bit of battery and runs pretty warm. Part of that is probably because there hasn't been any optimisations been done to improve the battery life.
On the Pandora, even disabling the USB stack helped save a bit of battery.

So I want to try and figure out ways to save battery power on the Pyra as well.


What's the plan?

As a first step, I'd like to find out what part of the Pyra uses how much battery.
There's the modem, audio, usb, backlight and so on.

The first thing is trying to find out what component has what power consumption.
I just like to get an overview so we know what might make most sense to optimize or disable as default in the OS.


So, what help is needed?

Well, how do we find out the culprits and try to fix things?

I know on my normal Linux PC, there's powertop which can show some statistics and offer optimizations, but I don't think powertop would work properly on the Pyra... would it?

So I need help finding out how to determine which part of the Pyra has what power consumption.
This is probably not as easy as it sounds, but maybe devs have some ideas?

Maybe we can watch the power consumption of the PALMAS chip and then disable / enable some components and see how much it changed?
Or don't connect it to a power supply and simply check the battery usage?

I also have no idea how to disable the various components fully on the Pyra.
On the Pandora, to fully disable the USB port, a simple rmmod was needed. Does that work on the Pyra as well?


Who can help?

Of course, best would be users / devs who already have a Pyra and can try it directly on their unit.
However, for ideas / commands / ways to find out what's going on, anyone experienced with stuff like that can help even if no Pyra is available.

 

[Risca]

I've worked with some of this stuff before:

• Check /sys/kernel/debug/clk/clk_summary (you need debugfs mounter) and cross-reference the TRM. Perhaps you can move some more peripherals to the same clock. Unused clocks are usually disabled by Linux automatically. Maybe use a slower clock+PLL if timing is less critical, e.g. if 3.2 MHz is needed you might be able to use a 32 kHz low power reference clock and multiply that with a PLL 10x instead of using an other reference clock with a higher power draw.
• What can be said about the different sleep modes of the OMAP5432? What devices are blocking a deeper sleep mode, and can something be done about it? We experienced our biggest power saving by entering deeper sleep modes. I know there was some issue with OMAP5432 and sleep mode, but was it relevant for every sleep mode?
• Most circuits have a low power mode when not needed, but it has to be explicitly enabled. Please consult the datasheet, if available. Maybe there's some way to query settings from the device? Some serious power savings can be had if you completely cut power to e.g. audio circuit when not playing any audio.
• Maybe some power domains can be disabled when not in used? You would have to consult the Pyra schematics to answer this one to see what is safe to disable. Maybe some devices can work with a lower voltage?
• In some cases, the voltage can be lowered dynamically based on load. I think older OMAP had something called smart reflex?
• The documentation for /sys/class/power_supply/<supply_name>/ seem to provide some good info: https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-power. However, I checked the driver for the palmas-regulator.c and it doesn't register itself as a power supply, but that might be easy to fix?

I also have no idea how to disable the various components fully on the Pyra.
On the Pandora, to fully disable the USB port, a simple rmmod was needed. Does that work on the Pyra as well?

I always considered rmmod a bit of a hack It relies on the driver to release all resources it needs and, if you're lucky, it will put the device in sleep mode/reset. I wish I could offer an answer on how it is supposed to be done, but I don't think there really is any good generic one. For example, to enable/disable power to bluetooth and wifi, you'd use the rfkill subsystem. Other (well-behaved) drivers will automatically suspend themselves when the last "user" of the driver lets go of the device. A user in this context might be another driver/device or it could be a userspace open() or close() call. Other drivers only does power management through the callback hooks in struct dev_pm_ops, which (IIRC) only gets called when the system goes into suspend or hibernation.

That was a small brainstorming dump of what I could think of from the top of my head. Hopefully, some of it is useful

 

[Risca]

Example clock: clk32kgaudio.
This is what Linux has to say about this clock:

# cat /sys/kernel/debug/clk/clk_summary
                                 enable  prepare  protect                                duty  hardware
   clock                          count    count    count        rate   accuracy phase  cycle    enable
-------------------------------------------------------------------------------------------------------
...
 clk32kgaudio                         1        1        0       32768          0     0  50000         Y
...

This clock has an enable and prepare count on my devkit of 1, and it can be enable/disabled by hardware.

To find out what device is using this clock, I searched the device trees and found that it was used by mmc3_pwrseq:

mmc3_pwrseq: sdhci0_pwrseq {
        compatible = "mmc-pwrseq-simple";
        clocks = <&clk32kgaudio>;
        clock-names = "ext_clock";
};

From what I could gather, it is used to provide the clock for a simple power sequencer (power off - sleep X s - power on) for the mmc3 interface. That is, when the mmc3 driver needs to reset the mmc3 interface it will ask the mmc-pwrseq-simple driver to do it. The mmc-pwrseq-simple driver needs the clk32kgaudio clock to function. If I don't need the mmc3 interface, I also don't need the mmc-pwrseq-simple driver, and I don't need the clk32kgaudio clock, which gets disabled by the Linux clock system. At least in theory...

EDIT:
This turned out to be a bad example since the mmc3 interface is never enabled in the device trees. I think the clk32kgaudio is always enabled because it has the CLK_IGNORE_UNUSED flag ¯\_(ツ)_/¯