[HACK] Overclocking/Undervolting kernels with Voltage Control support

[xan]

Hello,
I'm the author of Voltage Control, an application for Galaxy S series to control OC/UV kernels. I don't personally own a Nexus S (and I cant say I will, unless someone want to Nexus S donate one for me ;p).

Voltage Control Lite 4.00 on Android Market!

I know there are many apps to control OC, but I dont know any doing UV work.
If anybody is interested in making UV kernel for Nexus S there are some working kernels for SGS (given the hardware similarities some knowledge may be taken from current solutions).
Authors of most OC/UV code are raspdeep and Unhelpful, heres the topic: http://forum.xda-developers.com/showthread.php?t=822027 and second: http://forum.xda-developers.com/showthread.php?t=762171


If you are interested in creating UV kernel working with Voltage Control, I'll give brief explanation how VC works, and how are things done on SGS.

My application communicates with kernel via sysfs interfaces via cat and echo:
mandatory:

/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state // to read all states
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq // may be obsolete, didnt make a decision yet

/sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table

key in UV procedure, it represents undervolt for each frequency from highest to lowest; "25 25 50 50 100" means UV highest freq by 25, and lowest by 100


providing additional functionality:

/sys/devices/system/cpu/cpu0/cpufreq/frequency_voltage_table

Containing all frequencies and corresponding voltages, format:
FREQ STOCK CURRENT

1120000   1300   1300
1000000   1300   1300

This is useful for determining stock voltages used by the device, because they are needed in voltage calculation. Stock values are hardcoded, but If you want to change them I suggest to implement this table, to let user know at exactly what voltage his device is running.

Third column is obsolete, since VC calculates current (stock-uv) voltage itself might be removed in the future.

/sys/devices/system/cpu/cpu0/cpufreq/states_enabled_table

This is table where we store enabled ("1") and disabled ("0") state for each frequency;
"0 1 1 0 1" means we disabled highest frequency and second to lowest.
This is useful when kernel developer wants to produce ONE kernel for all OC lovers.
This means there could be one kernel supporting OC frequencies up to 1600Mhz (lets say 1600,1500,1400,1300,1200,1120), and user could choose which ones he wants to use (eg 1400 and 1120, disabling the rest).

I'm aware that Nexus S will receive tremendous attention from developers so I believe that someone might actually come with better implementation (single table consisting of all information needed by VC?)of this mess.
Best idea would be to make one table for all information, so it can be easily parsed.


Current version of app is 4.0 beta, which is a complete rewrite.

I'm open for ideas, suggestions regarding additional features.

Happy OCing.

 

[supercurio]

Thanks xan for this invitation

Unhelpful also played a big part with the initial code to load dynamically frequencies and voltages using a sysfs interface.
BTW, your app source is welcome on project-voodoo github !

I know several people motivated to contribute, it would be a place to start.

 

[xan]

Right, Unhelpful, adding topic to OP.

Yes, this needs to be open-sourced.
No date yet, because there are monsters inside.

The thing that struck me now, is why is all of that so complicated?

I think I like single-table idea more and more.

 

[k0mpresd]

ill volunteer to help.

 

[distortedloop]

Very exciting to see some of the best dev names from the SGS community showing interest in the Nexus S. Many goog things to come for us if they remain interested...

 

[Anderdroid]

So when are we gonna see a 1.2GHz Voodoo OC/UV kernel

 

[jroid]

My phone recieves a noticeable speed increase with the voodoo kernel for Nexus S with max and min set to 1000 with performance governor Can't wait for a super optimized kernel OC/UV!

 

[defysword]

looking forward to a UV kernel to extend battery life.

 

[hah2110]

My phone recieves a noticeable speed increase with the voodoo kernel for Nexus S with max and min set to 1000 with performance governor Can't wait for a super optimized kernel OC/UV!

Anything on battery?

looking forward to a UV kernel to extend battery life.

+1

 

[shrooms90]

why is no one compiling a kernel supporting xans app? i really loved it on my galaxy s and when i saw this threat i was hoping for a supported kernel for my nexus s. it really can make oc more stable if u r patient enough to test the best setzings for ur phone

Sent from my Nexus S using Tapatalk

 

[Kel Ghu]

Can't wait for this too. Xan's app is really good on SGS.

 

[morfic]

why is no one compiling a kernel supporting xans app? i really loved it on my galaxy s and when i saw this threat i was hoping for a supported kernel for my nexus s. it really can make oc more stable if u r patient enough to test the best setzings for ur phone

Sent from my Nexus S using Tapatalk

This died the 22nd of December, I got my Nexus S around that time, kept it stock while on vacation over the holidays, missed out there.

I *may* check this out, don't want to turn into Patches....
But I could continue to build Honity stable for Will, but others run lower than he does.
Instead of stock + UV build it would be only 1.
And Honity14 could be the UVOC some want.

Problem in that is that I take a risk of people not understanding the "use at your own risk" part involved.

Thanks for bumping this thread, didn't know xan had this.


Sent from my Nexus S

 

[shrooms90]

This died the 22nd of December, I got my Nexus S around that time, kept it stock while on vacation over the holidays, missed out there.

I *may* check this out, don't want to turn into Patches....
But I could continue to build Honity stable for Will, but others run lower than he does.
Instead of stock + UV build it would be only 1.
And Honity14 could be the UVOC some want.

Problem in that is that I take a risk of people not understanding the "use at your own risk" part involved.

Thanks for bumping this thread, didn't know xan had this.


Sent from my Nexus S

sounds good. i like honity kernel but for my phone it needs a little fine tuning.
i think people would understand "use at ur own risk" imo most people understood it on the sgs forum.
so i really would love to see honity14 with uv options

Sent from my Nexus S using Tapatalk

 

[dario3040]

Is there any progress?

 

[pongster]

I'm open for ideas, suggestions regarding additional features.

Happy OCing.

Hi. great stuff here. would this app work (or made to work) using snq-'s undervolting via sysfs here.

I use a kernel with the above patch enabled and my ROM users would love to be able to do this using an app like this.

Thanks!

 

[shrooms90]

Hi. great stuff here. would this app work (or made to work) using snq-'s undervolting via sysfs here.

I use a kernel with the above patch enabled and my ROM users would love to be able to do this using an app like this.

Thanks!

Im a noob when it comes to kernel developping, but i hope this will help u:
From what i understood this app undervolts using following command:
echo "0,0,50,100,0...." /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
Where the numbers stand for the amount of undervolting in mV for each freq. (I think it is from lowest to highest but im not sure. If u set the values at boot it just writes a startup script in /system/etc/init.d/

Sent from my Nexus S using Tapatalk

 

[JupiterDroid]

Fantastic,

The nexus s dev community is definitely growing now

JD

Sent from my Google Nexus Magic Wand S

 

[Stea1thmode]

Fantastic,

The nexus s dev community is definitely growing now

JD

Sent from my Google Nexus Magic Wand S

wtf? fancy seeing you here

 

[jlevy73]

wtf? fancy seeing you here

WTH young man, did you get lost

 

[TheEscapist]

Just thought that I'd mention this.

I develop a kernel for the Captivate for CM7. Our cm kernel is based off Nexus S code, so anything that works under it will work under your kernels as well (probably). I've implemented this successfully under my kernel with no real problems.

Just add a sysfs interface to the cpufreq driver to store the uv amount, then subtract that amount * 1000 from arm_volt before feeding it into the regulator.

Sources are here --> https://github.com/TheEscapistxda/CM7-OCUV

PS I apologize for my terrible commenting.