[Epic 4G Android Development] tanimn:
Sorry folks. If you've ever seen the movie paycheck, that's me (minus the great paydays). I chase off down the rabbit hole in pursuit of a goal and tend to not come up for air til I'm done. For the moment, I'm done.

Hope you're all enjoying 1.1.0, I found it sitting down to tea with the mad hatter and Rod Serling. ;)

The answer to this question is more complicated than it seems. There are really only 2 legitimate undervolts in this kernel, 1 at 1ghz, and 1 at 200mhz, both within the stock frequency range. Each frequency relies on 2 voltages: DVSARM and DVSINT, of which there are only 4 and 2 values allowed respectively across the entire range of frequencies, of which there are 3 extra in this kernel. Got it so far?

The complete voltage table and stock values are as follows:

Speed: DVSARM / DVSINT - Stock / Values

1.3ghz: 1.325v / 1.125v - NA / NA

1.2ghz: 1.325v / 1.125v - NA / NA

1.0ghz: 1.200v / 1.125v - 1.275v / 1.100v

800mhz: 1.200v / 1.125v - 1.200v / 1.100v

600mhz: 1.100v / 1.125v - NA / NA

400mhz: 1.100v / 1.125v - 1.050v / 1.100v

200mhz: .950v / 1.000v - .950v / 1.100v

100mhz: .950v / 1.000v - .950v / 1.000v

3 frequencies don't even exist in stock, so we technically can't classify them as over or under volts, even though they have to be included within the previously mentioned limits. One of the 2 DVSINT values had to be increased to stabilize the higher frequencies without raising a DVSARM voltage to unsafe levels, thus requiring it to be raised across all frequencies it affects. Suprisingly, this seems to have IMPROVED battery performance. I'm still trying to figure that one out...

At any rate, while I love a good agressive undervolt (remember 1.0.1?), I have to make sure that a majority of phones will boot and run well. So I am reduced to the best compromise I can manage. There should still be room to improve in the mid ranges, but that will take a lot more testing against handsets that behave poorly with undervolts before it get's implemented here.

There is no menu for this. If you want to adjust the patch value, you need to run commands from a rooted shell, or create an init.d script to apply custom values at every startup. If you do the following:

cat /sys/devices/platform/s3c-keypad/timer_delay

from a terminal, you will see what the default is set to. you can modify this setting by echoing a new value to that file like so:

echo "3" > /sys/devices/platform/s3c-keypad/timer_delay

The setting should already be optimized, but the option is now there to change it if desired.

Within SetCPU, that's about the only thing you can do. I used various benchmark softwares to put the cpu under load at different frequencies to test the stability. Things you can try are smartbench, neocore, quadrant, linpack... There are more, that's just what I used. Just don't set setcpu to enable on boot until you are comfortable with your settings.

I'll be posting a sunset version of the 1.0 kernel in the near future for people who prefer that line, but expect the 1.1 versions to surpass it's features very shortly.

Finally let me just say thank you to everybody here. Your input, feedback, and support have been invaluable to this process. I couldn't have done it without you.