We can play with cpufreq. QC does it in: device/qcom/common/rootdir/etc/init.qcom.post_boot.sh
Christian, this may be interesting for you.
So without any tunning, we can go down upto 782MHz. > $ adb shell 'echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' > $ adb shell 'echo 787200 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed' This may be improved by either directly passing those values are kernel command line arguments (and used directly by the cpufreq kernel module), or implementing a shell script setting it at boot from the values passed at boot. Thus, since we can change fastboot, we could also have a |fastboot oem speed| command to change the frequency.
Created attachment 8488647 [details] Defaulting to userspace and allowing a minimum of 300MHz With this patch, we set the default governor to be userspace and we allow to go below 787MHz, up to 300MHz. After testing this on a Flame, we really feel the lag.
Did you also stop one of the cores ? Can we use "echo 0 > /sys/devices/system/cpu1/online" ?
(In reply to gabriele.vidali from comment #4) > Did you also stop one of the cores ? > Can we use "echo 0 > /sys/devices/system/cpu1/online" ? See bug 1050267.
I tried downclocking the CPU to 700mhz and reducing the ram to 256mb: the phone is almost unusable. Either the screen resolution plays its part or the intex build is much more optimized compared to the flame one
Created attachment 8527786 [details] I have modified init.qcom.post_boot.sh Modified init.qcom.post_boot.sh doesn't set all the variables or something else resets them after boot, but after starting it again it works
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.