[Moto G5 ROMs, Kernels, Recoveries, & Other Develop] b.zill:
CPU governor / Power Management

I see three slightly different approaches, maybe we could combine these into one perfect one? :)

1. [MENTION=4968571]andyro2008[/MENTION] uses

#big GOV
chmod 644 /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 'interactive' > /sys/devices/system/cpu/cpu0/cpufreq/
chmod 444 /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
#LITTLE GOV
chmod 644 /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
echo 'interactive' > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
chmod 444 /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor

This takes cpu0 and cpu4 as “pars pro toto” for the governors of both clusters, but it seems to work. Further, the profile “interactive” seems already present and does not need to be filled with param values.

2. This is what Kernel Adiutor applies on startup to set both clusters to interactive:

chmod 644 /sys/module/workqueue/parameters/power_efficient
echo 'N ' > /sys/module/workqueue/parameters/power_efficient
chmod 644 /sys/devices/system/cpu/cpu1/online
echo '1' /sys/devices/system/cpu/cpu1/online
chmod 444 /sys/devices/system/cpu/cpu1/online
{"path":\/sys\/devices\/system\/cpu\/cpu%d\/cpufreq\/scaling_governor","value":"interactive","min":0,"max":3,"bigCpus":[0,1,2,3],"LITTLECpus":[4,5,6,7],"correctImin":2}
{"path":\/sys\/devices\/system\/cpu\/cpu%d\/cpufreq\/scaling_governor","value":"interactive","min":4,"max":7,"bigCpus":[0,1,2,3],"LITTLECpus":[4,5,6,7],"correctImin":2}

(not sure if it says correctImin or correctlmin)

The first two commands probably set the Kernel Adiutor option at the bottom of the CPU dialog. Then, obviously all cores are set to “interactive” individually. The separation into two commands for each cluster is probably due to the fact that Kernel Adiutor uses a template for settings across different devices.

3. This seems the current init.qcom.rc by [MENTION=6810779]wzedlare[/MENTION] (https://github.com/Wzedlare/android_device_motorola_cedric/blob/cm-14.1/rootdir/etc/init.qcom.rc):

# disable thermal & BCL core_control to update interactive gov settings
write /sys/module/msm_thermal/core_control/enabled 0

# governor settings
write /sys/devices/system/cpu/cpu0/online 1
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor "interactive"
write /sys/devices/system/cpu/cpufreq/interactive/above_hispeed_delay "19000 1401600:39000"
write /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load 85
write /sys/devices/system/cpu/cpufreq/interactive/timer_rate 20000
write /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq 1401600
write /sys/devices/system/cpu/cpufreq/interactive/io_is_busy 0
write /sys/devices/system/cpu/cpufreq/interactive/target_loads "85 1401600:80"
write /sys/devices/system/cpu/cpufreq/interactive/min_sample_time 39000
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 652800

# re-enable thermal & BCL core_control now
write /sys/module/msm_thermal/core_control/enabled 1

# Bring up all cores online
write /sys/devices/system/cpu/cpu1/online 1
write /sys/devices/system/cpu/cpu2/online 1
write /sys/devices/system/cpu/cpu3/online 1
write /sys/devices/system/cpu/cpu4/online 1
write /sys/devices/system/cpu/cpu5/online 1
write /sys/devices/system/cpu/cpu6/online 1
write /sys/devices/system/cpu/cpu7/online 1

On the load balancer settings and if it is necessary to disable thermal core control before changing the governor profile, I cannot judge. Question: Why is it important to bring up cpu0 online (like Kernel Adiutor does) somewhere in the middle of all those settings? There should be at least one core active to handle the boot process by that point, and I would assume that the governor would handle all other cores so far? Or should be avoided that for some reason some cores are disabled on boot? Individually setting the params within profile “interactive” seems not necessery, unless the preset should be changed for some reason. Plus, the individual settings do not match what Kernel Adiutor shows for the big cluster in “interactive” mode after booting, so I assume the script params are not accepted.

My question is if it would not be enough to reduce that part in init.qcom.rc to:

# bring up core 0 online
write /sys/devices/system/cpu/cpu0/online 1

# governor settings for big (cores 0-3) and LITTLE (cores 4-7) cluster
write /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor "interactive"
write /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor "interactive"

BTW, I accidentally disabled cpu2 and realized that then cpu8 jumps to 100% load and remains there even when the device is idle (screen on). So, disabling of cores manually might not be a good idea, and there is some kind of HMP or hotplug management present. On my device, sleep mode is by far the most used status of both clusters, so disabling of cores should not give much advantage.

Finally, I can second that the “extreme power save mode” (settings > battery) does not change the cpu governor (e. g. to profile “powersave” for both clusters), and seems to have little effect.

Having both clusters run on “interactive” profile, which is Moto G5 and Lineage default, would be nice.

EDIT: I see that the gov code in init.qcom.rc is obviously inherited from init.qcom.power.rc (Moto G4/G4+ athene, msm8952), where it is applied to both clusters and thus might not reflect changes since?