Hehe I was interested after seeing your post before but when testing drain at different CPU freq it didn’t seem to make a huge difference, I used “cpupower-gui” to experiment.
These are the “on battery” changes I made.
CPU_SCALING_GOVERNOR_ON_BAT=powersave
CPU_ENERGY_PERF_POLICY_ON_BAT=power
CPU_HWP_DYN_BOOST_ON_BAT=0
CPU_HWP_DYN_BOOST_ON_BAT=0
SCHED_POWERSAVE_ON_BAT=1
PLATFORM_PROFILE_ON_BAT=low-power
INTEL_GPU_MIN_FREQ_ON_BAT=100
INTEL_GPU_MAX_FREQ_ON_BAT=650
INTEL_GPU_BOOST_FREQ_ON_BAT=650 (not worth it likely, GPU scales on it’s own very well see “intel_gpu_top”)
PCIE_ASPM_ON_BAT=powersupersave
RUNTIME_PM_ON_BAT=auto
Looking at powertop, I just can’t seem to make the display backlight use a lower wattage. It’s always around 3W, this is probably why I am idling at 3.5W.
Limits the iGPU clock to 650 mhz on battery power, the lower bound setting (INTEL_GPU_MIN_FREQ_ON_BAT=100) doesn’t seem to do anything really. IMO this is only helpful if you will be loading the gpu fully but don’t want it to go to max clocks, in regular use I find that it does a fine job of clocking up and down to just what is needed. You can use intel_gpu_top to see and decide.
Be aware that the power estimate listed for each element in powertop is pretty much a random guess. It has no way of directly measuring the consumption of individual components. The only direct measurement powertop has is the reported battery power number listed at the top when the laptop is running on battery.
If you want to know how much power your backlight is using, you’ll need to let the system run with the backlight off while on battery, see what the battery power value reads, then turn on the backlight and see what the new power reading is. The difference is the consumption of the backlight.
Differential power measurements can also be done with a USB-C power meter, though you need to be careful to make sure that the battery is fully charged and has been stable for a few minutes so that you don’t get the charging power mixed in with your readings.
You can even use TLP along with auto-cpufreq AS LONG as you disable TLP’s governor and turbo boost setting (along with any additional CPU-related setting you’ve set yourself in TLP but by default I think these are the only two). Then you can benefit from auto-cpufreq and TLP’s other features (USB auto-suspend, radio devices, etc.).
Anyone here should read through the existing Linux battery life tuning thread first. It should have everything you need for tuning (there’s basically no difference in tuning from 11th vs 12th gen).
Does anyone understand how power-profiles-daemon works? I’ve heard that it can govern the cpu and fans based on information that Framework specifies, presumably in firmware. Is this true? If so is this optimal? Also I’m wondering if someone could give me pointers on how to disable all CPU governing that TLP assumes.
From what I’ve gathered I need to change CPU_ENERGY_PERF_POLICY_ON_(AC/BAT) to default and SCHED_POWERSAVE_ON_BAT to 0. Everything else seems to have a default of <none> which I assume means TLP doesn’t do anything.
PPD, which IIRC is a kde/plasma only invention, and TLP (a much more “universal” and extensible solution) do not work together at all. Devs of each have not been playing nicely with each other.
Choose one or the other. I went with TLP, and have been plenty happy with my choice.
TLP lists what it’s in conflict with in their FAQ (and the section above has detailed info on power-profiles-daemon interactions): Installation — TLP 1.6 documentation
You can also add auto-cpufreq, which in their README says " Please note: auto-cpufreq aims to replace TLP in terms of functionality and after you install auto-cpufreq it’s recommended to remove TLP . If both are used for same functionality, i.e: to set CPU frequencies it’ll lead to unwanted results like overheating. Hence, only use both tools in tandem if you know what you’re doing."
Note all of them play relatively nice with thermald, and that’s what should be loading the Framework “firmware” info - specifically, the DPTF adaptive policy tables.
Awesome, I think that is what I must have thought PPD does because I watched a talk with Framework and Fedora staff saying that there were custom fan curves.
I have a fairly in-depth understanding of it – in case you missed this, there’s some relevant/foundational info on how/what power profiles are (which set EPP values through the Intel P-State driver. EPP = Energy Performance Preference).
Long story short I forked PPD and adjusted the code – PPD IIRC simply just changes the EPP values which can be set yourself via /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference.
You can see my changes here which should result in some further understanding of what PPD does per the .patch file diffs:
I’d recommend just removing PPD altogether if you’re using TLP since it seems that PPD just changes EPP values, which TLP does via:
having only two power profiles with TLP (AC and BAT/battery, though those exact EPP values are user customization) instead of PPD’s 3 (which are fixed and imo aren’t ideal values for power savings anyways)
and the lack of Gnome/KDE shell integration.
So that should broadly answer your question, though I’m not sure if there’s any synergy with some Framework firmware setting. I don’t believe there are – if there were, I think it’d either be the Intel P-State driver itself and/or thermald. I could be totally wrong here, haha.
edit: just read @lhl’s comments and saw it covered some stuff I typed
