Changing vsel of lower frequencies with overclock

---

have been pratting about with this over the last day, have found the following.

I am using overclock module to set a custom setting of 900mhz/46vsel

However, when performing a cat /proc/overclock/mpu_opps I get the following

mpu_opps[3] rate=900000000 opp_id=3 vsel=46
mpu_opps[2] rate=600000000 opp_id=2 vsel=48
mpu_opps[1] rate=300000000 opp_id=1 vsel=33

So whilst we are changing the max_freq and max_vsel we are not doing anything to reduce the vsel on the lower frequencies and thus not getting max battery life. The stock vsel at 600mhz is actually more than 900!

So I made a script so as to change the vsel values to lower for the lower frequencies as below:

setscaling.sh

echo 46 > /proc/overclock/max_vsel
echo 900000 > /proc/overclock/max_rate
echo 1 300000000 28 > /proc/overclock/mpu_opps
echo 2 600000000 38 > /proc/overclock/mpu_opps
echo 3 900000000 46 > /proc/overclock/mpu_opps
echo 0 900000 > /proc/overclock/freq_table
echo 1 600000 > /proc/overclock/freq_table
echo 2 300000 > /proc/overclock/freq_table

mpu_opps then read as I want it:

mpu_opps[3] rate=900000000 opp_id=3 vsel=46
mpu_opps[2] rate=600000000 opp_id=2 vsel=38
mpu_opps[1] rate=300000000 opp_id=1 vsel=28

I can run the script manually, and it works a treat, however, on reboot it has to be manually applied. Tried a number of ways to get this to run at boot (scripts and also autostart app in the market) however it doesn't apply and the reason behind this is due to it trying to apply the script before the overclock module has been applied.

I then tried to exclude the Milestone overclock app and use the overclock.ko module directly into /system/lib/modules/overclock.ko. The module itself seems to run ok, however when I then apply my setscaling.sh it cause the phone to reboot.

So a few questions if anyone can help.

1)is there anyway to delay a script from running for a period of time after boot (eg once the overclock module has loaded)

2) Any ideas why the phone is rebooting when using the overclock module directly outside the app, but the script works fine in conunction with the app.

I think I am just missing something obvious thats staring me in the face!

I guess it would be quite simple for whoever coded milestone overclock to just add a setting where we can choose the vsel for multiple frequencies...
Good job though, was wondering also if that was possible!
Will try and find how to contact him

Originally Posted by Damool

I guess it would be quite simple for whoever coded milestone overclock to just add a setting where we can choose the vsel for multiple frequencies...
Good job though, was wondering also if that was possible!
Will try and find how to contact him

I have added my setscaling.sh place it in /system/binx and execute it.

You can ammend it to put your own frequencies in there, be careful though!

Thanks will try when back from skiing

Higgsy, do you know how Android natively sets the frequency and voltage levels? Is there a config file or is it hard coded into the kernel or a module? My googling skills didn't turn up much.

Originally Posted by Zaben

Higgsy, do you know how Android natively sets the frequency and voltage levels? Is there a config file or is it hard coded into the kernel or a module? My googling skills didn't turn up much.

The default levels should be the reset values in the hardware itself. The Milestone Overlock App contains a kernel driver to communicate with the OMAP processors PLL and voltage chip (the TWL5030 chip) using the I2C buss to be able to modify these registers and their reset values. Higsy is communicating with this kernel driver using the /proc to set some of the registers that the kernel driver has mapped out. So it's more a case of being able to set these registers when the kernel module is being loaded to avoid doing it once the driver has been loaded.

Originally Posted by Xhit

The default levels should be the reset values in the hardware itself. The Milestone Overlock App contains a kernel driver to communicate with the OMAP processors PLL and voltage chip (the TWL5030 chip) using the I2C buss to be able to modify these registers and their reset values. Higsy is communicating with this kernel driver using the /proc to set some of the registers that the kernel driver has mapped out. So it's more a case of being able to set these registers when the kernel module is being loaded to avoid doing it once the driver has been loaded.

Yeah thats it, any suggestions then? At the mo I'm still running my script manually on boot after everything is loaded, to be fair I do it without thinking about it now, but would be good to automate it

Originally Posted by Higgsy

Yeah thats it, any suggestions then? At the mo I'm still running my script manually on boot after everything is loaded, to be fair I do it without thinking about it now, but would be good to automate it

Hmmm, seems I was mistaken in my last post. The kernel driver does not write to the TWL5030 directly, some registers in this chip has already been mapped out by and OMAP kernel driver and the overclock kernel driver is just used to be able to get to the OMAP driver parameters and other kernel parameters. All this according to the documentation found in code.google.com/p/milestone-overclock/wiki/KernelModule . And according to the same you can set some parameters when you insmod the kernel driver, "insmod overclock.ko mpu_opps_addr=0xc050a848 max_rate=800000 max_vsel=62". So you could try to set the arguments you want in freq_table and mpu_opps at insmod instead to see if that works?

EDIT: According to the FAQ, changing the freq_table and mpu_opps can only be done using a script writing to /proc.
http://code.google.com/p/milestone-overclock/wiki/FAQ

Edit 2: Checked the source code of overclock kernel driver. And the freq_table and mpu_opps is not a module_param meaning you can not set them during kernel load. However it would be very easy to add a couple of module_params to the source code be able to set them during kernel driver load. However you would need the complete cross-compiler environment to build it once modified, which I guess is the major time consumer to make this change. So kindly asking Tiago Sousa whos written it would maybe be the quickest..

Originally Posted by Xhit

Hmmm, seems I was mistaken in my last post. The kernel driver does not write to the TWL5030 directly, some registers in this chip has already been mapped out by and OMAP kernel driver and the overclock kernel driver is just used to be able to get to the OMAP driver parameters and other kernel parameters. All this according to the documentation found in code.google.com/p/milestone-overclock/wiki/KernelModule . And according to the same you can set some parameters when you insmod the kernel driver, "insmod overclock.ko mpu_opps_addr=0xc050a848 max_rate=800000 max_vsel=62". So you could try to set the arguments you want in freq_table and mpu_opps at insmod instead to see if that works?

EDIT: According to the FAQ, changing the freq_table and mpu_opps can only be done using a script writing to /proc.
http://code.google.com/p/milestone-overclock/wiki/FAQ

Edit 2: Checked the source code of overclock kernel driver. And the freq_table and mpu_opps is not a module_param meaning you can not set them during kernel load. However it would be very easy to add a couple of module_params to the source code be able to set them during kernel driver load. However you would need the complete cross-compiler environment to build it once modified, which I guess is the major time consumer to make this change. So kindly asking Tiago Sousa whos written it would maybe be the quickest..

Right I cracked it!

all I had to do was the following

My setscaling.sh resides in system/xbin

I created an Install-recovery.sh and placed in system/etc

The content of Install-recovery.sh is:

#!/system/bin/sh
sleep 90
setscaling.sh

Hence making the script wait 90 secs before it initialises my setscaling.sh - plenty of time for the overclock module to load.

It may not be the best solution but it works a treat.

Wow that was fast. I've been playing with the voltages and it seems that stability depends on both the starting freq/vsel and also the current battery level. For example I can lower the voltage for 300MHz slowly while staying at 300MHz, but jumping from 600MHz I have to be much more careful so the resulting vsel has be to much more conservative. Milestone-overclock isn't always successful when you hit "apply" (including false read back) and I had to use Quadrant's system info to verify each time. This was much more touchy compared to undervolting a laptop.