Patch webOS CPU Frequency or Voltage Scaling

THIS PAGE IS OBSOLETE - USE THE GOVNAH APPLICATION INSTEAD

= Overview= There are currently 2 methods to enable further power saving - neither is perfect. Note that these 2 methods CANNOT be used together so make sure you try only one solution at a time. Using both has been reported to brick your Pre, requiring a visit to the WebOS Doctor. Patches for these are now available in the gitorious repo. See Applying Patches

1 CPU Scaling 2 SmartReflex
 * This allows the Pre to scale the CPU clock speed up and down in response to changes in CPU utilization. Some people have reported glitching when using scaling when the CPU is under heavy load (lots of multitasking, playing video, etc).
 * This allows the Pre to vary the voltage inside the core in response to silicon characteristics, temperature, voltage, etc. This does not save that much power because it is supposed to be used along with CPU scaling to reduce voltage when the CPU is running slower, but the Pre's kernel is missing the modules to do this. This is why using both together will freeze the Palm Pre. (Remove the battery, restart with the USB plugged into your computer with NovaCom installed, During the phones boot procedure simply telnet to the phone through NovaCom's Proxy port 8023, remove the smartreflex files you installed in the events folder in /etc/ before WebOS panics)

= CPU Scaling=

Default Setting
Frequency scaling does not appear to be active by default on the Pre by default. The directory /sys/devices/system/cpu/cpu0/cpufreq contains information on the current state. The clock seems to be fixed at 500mHz for normal operation (according to cpuinfo_cur_freq), however several other frequencies exist: root@castle:/sys/devices/system/cpu/cpu0/cpufreq# cat ./scaling_available_frequencies 600000 550000 500000 250000 125000 The file /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state shows that at some point (probably during startup) the frequency is raised to 550mHz for a short period of time.

Enabling Scaling
It is possible to enable frequency scaling using the 'ondemand' governor: root@castle:/sys/devices/system/cpu/cpu0/cpufreq# echo ondemand > ./scaling_governor this will cause the frequency to be reduced automatically while idle, and increased as needed during operation, potentially increasing battery life. Because higher frequencies may cause overheating, and TI has noted a significant decrease in the life of the processor when running above 500mHz, you should also restrict the frequency scaling to 500mHz and below by doing the following: root@castle:/sys/devices/system/cpu/cpu0/cpufreq# echo 500000 > ./scaling_max_freq If your Pre seems sluggish after enabling scaling, you can try changing the values in /sys/devices/system/cpu/cpu0/cpufreq/ondemand as detailed below.

'ondemand' Configuration
Increasing the value of 'scaling_min_freq' will prevent the CPU from going into extremely low speed configurations, which will significantly improve the responsiveness of the device when it first detects increased CPU usage, at the cost of a little bit of battery life. root@castle:/sys/devices/system/cpu/cpu0/cpufreq# echo 250000 > ./scaling_min_freq Setting the value of 'up_threshold' lower will cause the frequency to be increased at lower levels of activity. root@castle:/sys/devices/system/cpu/cpu0/cpufreq/ondemand# echo 30 > ./up_threshold Note: The default setting for 'up_threshold' is 80.

Checking Performance and Stats
To check how long your Pre has been running and at what frequency, do this:

cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state

You will see something like this: 600000 906 550000 768 500000 380 250000 0 125000 180505

The first number is the CPU frequency, the second is a time interval. In this example, my Pre has spent the most time @ 125mHz, but you can see it shoots up when needed. Note that if you are overclocking, it really doesn't spend much time at 600mHz, so overheating shouldn't be a problem, but you will definitely notice an improvement. These stats are reset after a reboot.

Overclocking
Overclocking is not recommended, as TI has reported a significant decrease in the life of the CPU at frequencies about 500mHz. However some users have reported better responsiveness, in addition to running cooler and using less battery while overclocking.

To overclock to the CPU's maximum speed, do: echo "600000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

To put it back, do: echo "500000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Making your changes stick after a reboot
Create a file called cpu-scaling in /etc/event.d and put this code in it, then reboot.
 * 1) Enables cpu scaling

start on stopped finish stop on runlevel [!2]

console none

script echo "500000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "250000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "30" > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold end script

Return to Stock Fixed Frequency
The simple way is just to remove the cpu-scaling script from /etc/event.d (if you created it) and reboot. None of these changes are persistent without the "sticky" script shown above.

If you switch back to the 'userspace' governor without rebooting, your frequency could get stuck at a lower setting and the whole system get really bogged down. Here is a quick shell script to help you revert to userspace with the original frequency:

Copy/paste this whole line as one command: echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor ; echo 500000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Then confirm the frequency/governor are back the way you want.

Comments and Caveats

 * "I tried this out but video playback was flickery and horrible. The up_threshold tweak setting to 30 seems to improve it a lot, but it's still flickery a bit.  Some people may not be happy."


 * "I found that setting the max freq to 600000 with the threshold helps this problem. See relevant warnings above first!  I don't really watch video on my Pre, so it's not so big of a deal." -pEEf


 * "A lot of people on the Precentral forums (myself included) are experiencing the phone locking up after a while of using this, and need to pull the battery to reset. (On webOS 1.0.3 at least.)"


 * "I've been running my phone with scaling for nearly a week now without problems, but I'm not 'overlcocking' so to speak. Any specifics on what might cause the locks? (ok had my first locks tonight while attached to the touchstone, weird it never happened before now (and annoying))" -retry


 * "I tried the folling over WebOSQuick Installer Linux Console: 1. root@castle: echo ondemand > ./scaling_governor 2. root@castle: echo 500000 > ./scaling_max_freq 3. root@castle: echo 125000 > ./scaling_min_freq 4. root@castle: echo 30 > ./up_threshold . But even after 7hours... nothing changed.. just used 500Mhz in Airplane mode over Night." -Ryo

= SmartReflex=

Enable SmartReflex
SmartReflex can be enabled in the VDD1 and VDD2 areas of the OMAP processor by setting two flags under /sys/power root@castle:/sys/power# echo -n 1 > /sys/power/sr_vdd1_autocomp root@castle:/sys/power# echo -n 1 > /sys/power/sr_vdd2_autocomp This slide deck has much of the pertinent information about SmartReflex and other power-saving technologies on the OMAP processor. Unfortunately the kernel modules that provide many of the features mentioned in the slide deck are not present on the Pre. This is the main reason that SmartReflex may not save a terribly large amount of power.

Making your changes stick after a reboot
To enable SmartReflex, create a file called smartreflex in /etc/event.d and put this code in it, then reboot. description "SmartReflex" author "Alex Markson" version 1.0
 * 1) -*- mode: shell-script; -*-

start on stopped finish stop on runlevel [!2]

console none

script

echo -n 1 > /sys/power/sr_vdd1_autocomp echo -n 1 > /sys/power/sr_vdd2_autocomp
 * 1) SmartReflex
 * 2) "SmartReflex™ driver allows for auto-compensation of VDD1 and
 * 3) VDD2 voltages (around the voltages specified by current OPP)
 * 4) by analyzing the silicon characteristics, temperature, voltage etc"
 * 5) Enable SmartReflex
 * 1) Enable SmartReflex

end script

If you want to enable overclocking in addition to SmartReflex, add the following JUST BEFORE the end script line: echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
 * 1) according to the OEM shell script in /etc/miniboot.sh
 * 2) this seems like it needs to be set twice to make sure ?

Comments and Caveats

 * "AFter using this for about a week, I find that using SmartReflex causes the Pre to stutter every so often"
 * "webos 1.1 w/ no problems to start. Installed ondemand script, full 125-600mhz range, threshold 30: worked fine mostly but on the touchstone it gets hot and locks up kills battery, backlight on behind black screen, every time, within an hour. Switched to smartreflex with 600mhz, no problems, though only a few days so far and no video testing. Media player remix playing to car stereo via bluetooth is smooth." Bkw 00:02, 15 September 2009 (UTC)

= Credits=
 * Alex Markson for the SmartReflex find and the script.
 * pEEf for numerous discoveries related to cpu scaling.
 * sidamos for the info about 'up_threshold'
 * garrettwp for the cpu scaling event.d script.
 * Jauder Ho for gitorious patches

= Hacking= There is still a lot of work to be done in making this work optimally. The following are some resources and thoughts.
 * A paper about the ondemand governor http://www.linuxinsight.com/ols2006_the_ondemand_governor.html
 * webOS 1.0.4 has CONFIG_PREEMPT set along with CONFIG_HZ=100. CONFIG_NO_HZ aka tickless is not set. In webOS 1.4.0 (Feb 2010), CONFIG_PREEMPT is not set, CONFIG_HZ=100 and CONFIG_NO_HZ=y (did not check in between).
 * Possible patch for NOHZ / ondemand governor http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-05/msg10436.html
 * Use PowerTop to observe what is going on inside the Pre:
 * Install ipkg-opt then run these commands from a root command prompt to install and start powertop:
 * http://www.lesswatts.org/
 * http://wiki.davincidsp.com/index.php/Running_PowerTOP_on_OMAP35x_platform
 * TI 3430 PM presentation http://www.celinux.org/elc08_presentations/TI_OMAP3430_Linux_PM_reference.ppt
 * CPU frequency scaling in Linux with cpufreq. Details on cpufreq parameters http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html
 * smartreflex patches http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26629.html

=More Information= Right now this is a [slow] collection of data --A2NY

Kernel Config File: cat /boot/config-2.6.24-palm-joplin-3430

Kernel Config Freq: CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y
 * 1) CPU Frequency scaling
 * 1) CPU Frequency scaling
 * 1) CONFIG_CPU_FREQ_DEBUG is not set
 * 1) CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
 * 2) CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
 * 1) CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
 * 2) CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
 * 3) CONFIG_CPU_FREQ_GOV_PERFORMANCE is not set
 * 4) CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
 * 1) CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

Enabled Governors: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors ondemand userspace

ONDEMAND is also called DVFS (Dynamic Voltage & Frequency Scaling)


 * 1) Newer kernels apparently have an improved ondemand governor http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-05/msg10436.html

Kernel Config PM:
 * 1) OMAP Power Management
 * 1) OMAP Power Management

CONFIG_OMAP3_PM=y CONFIG_OMAP_VOLT_SR_BYPASS=y
 * 1) Power Management Options
 * 1) Power Management Options
 * 1) CONFIG_OMAP_VOLT_SR is not set
 * 2) CONFIG_OMAP_VOLT_VSEL is not set
 * 3) CONFIG_OMAP_VOLT_VMODE is not set

CONFIG_OMAP3ES2_VDD1_OPP4=y
 * 1) Default VDD1 OPP Level Selection
 * 2) CONFIG_OMAP3ES2_VDD1_OPP1 is not set
 * 3) CONFIG_OMAP3ES2_VDD1_OPP2 is not set
 * 4) CONFIG_OMAP3ES2_VDD1_OPP3 is not set
 * 1) CONFIG_OMAP3ES2_VDD1_OPP2 is not set
 * 2) CONFIG_OMAP3ES2_VDD1_OPP3 is not set
 * 1) CONFIG_OMAP3ES2_VDD1_OPP5 is not set

CONFIG_OMAP3ES2_VDD2_OPP3=y CONFIG_MPU_OFF=y CONFIG_OMAP34XX_OFFMODE=y CONFIG_CORE_OFF=y CONFIG_SYSOFFMODE=y CONFIG_AUTO_POWER_DOMAIN_CTRL=y
 * 1) Default VDD2 OPP Level Selection
 * 2) CONFIG_OMAP3ES2_VDD2_OPP2 is not set
 * 1) CONFIG_OMAP3ES2_VDD2_OPP2 is not set
 * 1) CONFIG_OMAP3ES2_VDD2_OPP2 is not set
 * 1) CONFIG_ENABLE_VOLTSCALE_IN_SUSPEND is not set
 * 2) CONFIG_RESET_IVA_IN_SUSPEND is not set
 * 1) CONFIG_CORE_OFF_CPUIDLE is not set
 * 1) CONFIG_HW_SUP_TRANS is not set
 * 2) CONFIG_TRACK_RESOURCES is not set
 * 1) CONFIG_PREVENT_MPU_RET is not set
 * 2) CONFIG_PREVENT_CORE_RET is not set
 * 3) CONFIG_DISABLE_EMUDOMAIN_CONTROL is not set

TWL4030: /sys/devices/platform/twl4030_registers.0/module_pm_receiver

Kernel info: +	 Please note, that by default SmartReflex is only +	 initialized. To enable the automatic voltage +	 compensation for VDD1 and VDD2, user must write 1 to +	  /sys/power/sr_vddX_autocomp, where X is 1 or 2.

Device Startup: 2009-11-02T02:40:01.263122Z [15] webos kern.warning kernel: OMAP: Initializing SmartReflex subsystem... 2009-11-02T02:40:01.263549Z [15] webos kern.info kernel: OMAP: SmartReflex subsystem initialized. 2009-11-02T02:40:01.282196Z [15] webos kern.err kernel: OMAP 3430 Power Management subsystem initializing. 2009-11-02T02:40:01.292083Z [15] webos kern.info kernel: OMAP: Setting up clocks. 2009-11-02T02:40:01.319152Z [15] webos kern.warning kernel: OMAP: OPP mismatch: current/target=2:4 2009-11-02T02:40:01.319702Z [15] webos kern.info kernel: OMAP: Change MPU speed: 250 => 550 MHz 2009-11-02T02:40:01.321044Z [15] webos kern.info kernel: OMAP: ARM/DSP clock at 550/396 MHz. 2009-11-02T02:40:01.321624Z [15] webos kern.info kernel: BogoMIPS: 547.88 @550000 KHz 2009-11-02T02:40:01.327911Z [15] webos kern.info kernel: OMAP CPU idle driver initializing. 2009-11-02T02:40:01.328277Z [15] webos kern.err kernel: create_proc_entry succeeded 2009-11-02T02:40:01.342102Z [15] webos kern.info kernel: Initialize power support module 2009-11-02T02:40:01.342742Z [15] webos kern.info kernel: OMAP3: PM: Sirloin target registered successfully.

SR autocomp is enabled in userspace: 2009-11-30T17:39:39.106658Z [329] webos kern.info kernel: Timeout in prcm_check_power_domain_status, domain 9, desired state 1, current state 3 2009-11-30T17:39:55.827423Z [345] webos kern.info kernel: Timeout in prcm_check_power_domain_status, domain 9, desired state 1, current state 3

SR autocomp is enabled in ondemand: (device wants off, will not wake if it goes off) 2009-11-30T17:27:37.676910Z [7523] webos kern.info kernel: Timeout in prcm_check_clock_domain_status, domainid 9, desired state 0, current state 1 2009-11-30T17:27:45.676269Z [7531] webos kern.info kernel: Timeout in prcm_check_clock_domain_status, domainid 9, desired state 0, current state 1

powersave_bias http://osdir.com/ml/kernel.cpufreq/2006-07/msg00137.html This patch adds a "powersave_bias" tunable to ondemand to allow it to reduce its target frequency by a specified percent.

By default, the powersave_bias is 0 and has no effect. powersave_bias is in units of 0.1%, so it has an effective range of 1 through 1000, resulting in 0.1% to 100% impact.

In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz:-)

For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8.