Over the years, I've messed with various kernel-power settings and reached the conclusions (valid only for my particular device), that

- any voltage profile less than "ideal" seems to introduce problems when accessing microSD
- using SmartReflex on VDD1 and VDD2 results in better battery life, but precludes overclocking beyond 805MHz
- the phone is stable at 250-805MHz with SmartReflex on VDD1 and VDD2 and has been running that way for a year

Now, without SmartReflex on either VDD and using the ideal voltage profile, the phone is perfectly happy at 1000MHz and this provides a noticeable speed boost to the interface. I wouldn't have chosen to do this two years ago, but warranty is no longer relevant and I have a spare N900 anyway. So, fine, we'll overclock the hell out of it. When we need to, that is. Battery life is still a concern, so I'd still like the phone to spend most of its time in 250-805MHz with SR, but to toggle SR and give me 1000MHz (preemptively) when I require it.

I don't want to do this by issuing a "kernel-config load xxx" on every lock/unlock as that takes upwards of half a second to complete, introducing a degree of lag and arguably defeating the purpose of the exercise. But, it has only just dawned on me that I can avoid this by setting the "ideal" voltage profile as default, then overriding clock speed and SmartReflex settings using sysctl. For instance:

/usr/local/bin/smartreflex:

#!/bin/sh

case $1 in
"on")
echo "805000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "250000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "1" > /sys/power/sr_vdd1_autocomp
echo "1" > /sys/power/sr_vdd2_autocomp
;;

"off")
echo "0" > /sys/power/sr_vdd1_autocomp
echo "0" > /sys/power/sr_vdd2_autocomp
echo "1000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "250000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
;;

esac

It seems to work, so, is there any good reason not to do this? The logic I am thinking of employing here is not completely decided yet, but my thinking is that every time I unlock the phone, it'll be to load some sort of application and therefore, that I will benefit from full speed, briefly at least, every time I unlock the phone.

Maybe it needs to be coupled with a timer when we're on battery, because one of two situations will be true. If I unlocked the phone for short-term use, i.e. to read a message or check when my bus is coming, then it'll be relocked again after a minute or two, in which case that relocking can be used as the trigger for reenabling SmartReflex. The problem comes if I unlocked the phone to listen to music or take a phone call, and it perhaps remains unlocked for an hour or two. In this case, we'd want battery life over responsiveness of the user interface and should probably reconfigure accordingly.

So, I guess the logic that I am proposing can be described as:

- on phone unlock, disable SmartReflex and boost to 1000MHz. If on battery, set a timer to revert after five minutes.
- on phone lock, restrict to 805MHz and enable SmartReflex

and the rationale this is that it should improve the responsiveness of the phone / browser / etc. when first unlocking it and selecting or using an application. It is anticipated that this will not improve battery life as compared with leaving SmartReflex enabled, but that it will do a limited amount of harm. Am I making sense, or have I missed something? Comments, suggestions and improvements to this logic are invited...