[Nexus 6  Original Android Development] bbedward:
Hi,

Typically in the old days (which is the last time I was around) this type of thing would be in a cpufreq kernel driver using methods from the battery driver, and possibly allowing configurability through a basic sysfs interface. However, this is not the old days.

I inquired to my good friend imoseyon (I say good friend, he'd probably say "friend? you mean that crazy guy who i talked to once and now he keeps asking if I want to hang out?")

It appears that this battery change goes through the msm_thermal driver through a userspace process. The sad news is that there isn't a way to differentiate between thermal-related calls and these battery-related calls at the kernel level.

BUT,

this specific behavior can be disabled in the userspace (just not in the kernel space) - You will need root access (or you could make this change through twrp)

I will point you to this file (Which you should make a backup of before making any changes to it):

/system/etc/thermal-engine-shamu.conf

You can either edit it in something like root explorer, or pull it down through adb like this:

# adb pull /system/etc/thermal-engine-shamu.conf

Open it in your editor of choice (on windows I suggest you use something that supports unix line endings, like notepad++)

Point yourself to BAT-SOC-CPUFREQ near the top of the file

[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 60 80
thresholds_clr 59 79
actions cpu cpu
action_info 2265600 1728000

Interpreting this is pretty straight forward:

- sampling 5000 : I guess how often (probably in ms) that it compares battery % to thresholds and thresholds_clr

- thresholds 60 80: defines two thresholds in which to take actions

- thresholds_clr 59 79: defines two thresholds in which to clear actions

- actions cpu cpu: the action to take (like a method) when thresholds are met

- action_info 2265600 1728000: action parameters that are apparently used to change scaling_max_freq

Read from thresholds down like a column

The bit that tells it to reduce frequency to 2.26Ghz at 40% and back to 2.6 at 41% is this:

thresholds 60
thresholds_clr 59
actions cpu
action_info 2265600

Where thresholds 60 refers to 40% battery by apparently % discharged (100-60 = 40%). Similarly thresholds_clr 59 (100 - 59 = 41%)

Anyway lets you say you want to throttle to 2.26GHz at 20% and at 21%+ you want to be back to normal scaling_max_freq (2.6Ghz stock) You should change it to look like this:

[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 80
thresholds_clr 79
actions cpu
action_info 2265600

Save the file thermal-engine-shamu.conf and push back to device (or in root explorer you are already there)

# adb remount rw /system
# adb push thermal-engine-shamu.conf /system/etc/
# adb remount ro /system

Changes will probably take effect after you restart the thermal-engine service (if not, then do a reboot).

# adb shell stop thermal-engine
# adb shell start thermal-engine

------

Also notice the exact same applies for GPU frequency throttling and HOTPLUGGING due to battery

On stock 5.1 - Here is everything that happens and can be understood from the default thermal-engine-shamu.conf (related to battery):

CPU is throttled to scaling_max_freq 2.26GHz @ 40% battery

CPU is throttled to scaling_max_freq 1.7GHz @ 20% battery

GPU is throttled to 500MHz @ 45% battery

GPU is throttled to 389MHz @ 10% battery

GPU is throttled to 300MHz @ 5% battery

CPU3 (core #4) is removed (hot-unplugged) @ 15% Battery

CPU2 (Core #3) is removed (hot-unplugged) @ 8% Battery

Hotplug and GPU throttle behavior can be changed in the same thermal-engine-shamu.conf on the subsequent lines. (Exact same logic as described above, but actions/methods are different OFC)

[BAT-SOC-HOTPLUG]
algo_type monitor
sensor soc
sampling 5000
thresholds 85 92
thresholds_clr 84 91
actions hotplug_3 hotplug_2
action_info 1 1

[BAT-SOC-GPU]
algo_type monitor
sensor soc
sampling 5000
thresholds 55 90 95
thresholds_clr 54 89 94
actions gpu gpu gpu
action_info 500000000 389000000 300000000

----

So this is actually quite an easy thing to adjust. I know that franco/imoseyon have taken further actions to (and are currently working on):

Prevent this sort of userspace changes from going through msm_thermal driver, by rewriting the driver to only deal with thermal stuff (basically - and probably as it should do to begin with). Apparently this is a little problematic because QC/Moto/Goog have used this driver and its ioctl to funnel other important stuff through (that isn't thermal-related but is still important)

To lock specific msm_thermal userspace processes from making changes to cpufreq

But there are other factors in play there that complicate things.

Disabling the specific behavior of throttling CPU+GPU and disabling hotplugging at certain battery percentages is extremely easy through that configuration file.

Cheers,

B