[Galaxy S I9000 Android Development] newmail:
Correct, it's against the update2. My userland is XXJVR based but the patch will work on XXJVS too.

I've a friend using it on Galaxy S II, he suggested me a cleanup for SMP kernels, so I will post an update soon but there is no runtime change for Galaxy S users.

This ondemand-deep-sleep2 is just generic (not specific to SGS) and is needed to improve both battery and interactivity on any cellphone or tablet where the cpuidle wfi ARM sleeps will go deep and ignore the timer interrupts and only get waken by wifi or other events... the cpufreq.c part is not ok for laptops or similar, and the frequencies must be updated for the Galaxy S II before applying. However the cpufreq.c part isn't as important as the _ondemand part and on the decrease of the sampling rate to 10000.

My friend on galaxy S II told me had a default sampling rate of 100000 (SGS default is 40000), that's way overkill... that means the first two and ~half frames of a 25hz movement on the screen would be rendered at the lowest freq. The patch basically allows to decrease the sampling rate to the "interactive" one that we want ("10000"), but without leading ondemand to go totally confused and doing the opposite of what it should when the CPU is idle (or even when the cpu is running mixed loads that sometime trigger the long idle cycle that would then decrease the frequency to the policy.min at exactly the wrong time... i.e. when we had a long sleep with a short average sampling rate, we must ignore the past measurement because that would lead to decrease the freq by mistake as we just got a wakeup and exited the cpuidle). When I pinged my friend he was using the performance governor... now he's happy with this change and ondemand.

I've got a positive feedback from another user too, he was happy about increased battery life especially, but let's wait more people to test it too.

On my side it's working well and I was happy knowing the cpu was at 100mhz (instead of 800mhz) when I was listening to music during a short travel with the cell in my pocket and screen off :). skype doesn't jitter anymore when I iconize it and use the cellphone during a skype call.

There's no way the CPU can go to suspend to ram while the mp3 decoding is running. Just the whole suspend callbacks to shutdown the hardware wouldn't run fast enough for that, even without including the boot of the cpu during resume. Though is possible that the didle thing may make the cpu freq irrelevant, I don't know, but it's working perfectly at 100mhz too.. unlike the suspend to ram that must happen at 800mhz, so there's no reason apparently for the code I commented out in earlysuspend.c that jumps to 800mhz fixed.

Also note, when screen is off and the phone goes in suspend to ram (the awake bar isn't blue anymore in the battery chart) this patch shouldn't be able to make any difference because in suspend to ram the CPU loses power so it doesn't matter which frequency and voltage it had before the power was cut off. The cpufreq arm code makes sure the freq is 800mhz fixed before doing the suspend to ram (a friend of mine with galaxy S II had some issue if the freq wasn't 800mhz, the cpu voltage wasn't written correct during resume). That's likely an hardware issue, the freq to enter suspend to ram has to be 800mhz (more likely the voltage has to be the one set at 800mhz, it seems the voltage changes with the freq). So while removing the "forced" 800mhz during didle is safe, I can't remove it from the suspend to ram but there it doesn't matter because the cpu loses power completely then :-), so we're optimal!

I suspect the reason the didle forced the ULP_FREQ at 800mhz might have been because the ondemand could get confused by even longer sampling times and maybe the music player would skip? I've no idea what's the reason of the ULP_FREQ was, it just seems not necessary with my changes.

The power saving with this patch should be max when you have screen off and you make voip calls with proximity sensor or run a music player.

Have a nice weekend everyone.