This is basically a repost of the work i did in the forums of PreCentral.net

Okay i have been doing extensive testing. I believe i have solved most of the problems related to cpu scaling.

noted problems:
1. Video playback flickers and can be choppy
3. Phone freezes usually in standby or some other low state like listening to pandora in standby.
2. Can force the phone to have a 250mhz minimum instead of 125Mhz minimum

Fixes:
Two new scaling schemes. The first uses 1 second sampling rates and an 11% cpu utilization speed up threshold. The second method uses powersave_bias to turn on the 250mhz minimum (this will cause the phone to quit going down to 125Mhz, it goes down to 250Mhz instead during standby or other lowly states)

The fist scheme fixes video playback and phone freezes during lowly states, but does not fix the 250Mhz minimum problem so you phone will use 125Mhz for its lowly state.

The second scheme fixes phone freezes during lowly states like standby and Pandora, and makes 250Mhz the minimum cpu frequency. This method does not fix video playback flickering issues.

Here is the code:

First scheme (my favorite and the one im currently using)
assumes you are at root@castle:/#

echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 500000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 11 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

Second scheme (not my favorite because of video flicker and other reasons i will explain latter but it does utilize the 250mhz low state which is a little snappier than 125Mhz)
assumes you are at root@castle:/#

echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 500000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 11 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
echo 10000000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias

The main problem with the methods people were doing before is that the chip was switching between low and high state several times over the course of a few second no matter if they were playing a video or pandora. The first scheme above fixes that issue. The second scheme still suffers from this but i tried to lessen its severity by changing the sampling rate to 10 seconds (in reality it seems like 2 seconds durring testing). 10 seconds was the lowest i could go without it wanting to change states from low to high several times in a few seconds. There is something wrong with the powersave_bias function that makes it switch states faster than the sampling rate. I am looking into possible workarounds.

I would have liked to make the speed up threshold 5% but the lowest the up_threshold function would let me choose is 11%. 5% is usually low enough to have the phone running full power during pandora. Your phone is almost always lower than 5% during standby or when not doing anything on your phone.

If you want these codes to stick after a reboot then you will need to prepare a script in vi editor inside you pre’s linux system in the format similar to how they did it at pre dev wiki here

scroll down the page till you see how they made it stick. Just change the code to the codes in the post, but you need to change the format slightly. If you dont know how to do this then you do not need to be trying anything mentioned in this post.

And as always i am not responsible for any damage this may cause you. But the consensus is that the ondemand scaling function is pretty harmless to your phone. Freezes are fixed by unplugging you battery. If you want to be extra careful then just run these codes without making a script. That way when you reboot everything goes back to defaults from palm for the cpu.

If anyone can get powersave_bias stable let me know what you did. I was using trans_table in the /cpufreq/stats folder and also time_in_state within the same folder. Another usefull tool is cpuinfo_cur_freq within the /cpufreq folder. Also use top command to monitor your cpu utilization, this command can be executed anywhere within linux.

I have decided to include some code that will help anyone if they decide to do their own testing of cpu scaling and power save bias. Here is the code I use for testing:

current speed
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
time in different frequencies
cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
number of switches between power states
cat /sys/devices/system/cpu/cpu0/cpufreq/stats/trans_table
current sampling rate
cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
current up threshold
cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
current power save bias
cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
current max freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
current min freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

turn off power save bias
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias

overclocking
echo 550000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 1500000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

good luck

-L337Tech