View Single Post
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#64
Originally Posted by auouymous View Post
Listening for disable_ts and turning off polling while locked would be a good start.
Done. See post above.

How hard would it be to use a dynamic polling rate that decays between two tunable values the longer no data is available?
I'd rather have some actual data of the real battery impact before trying to implement something like that.

What does op_active do?
It sets the cpu/dsp frecuency:
Looking at the kernel source code
0->400/165
1->333/220
2->266/177
3->165/110
It is dinamically changed by the governor.

I have done some more testing and while op_active can be written to with the dsp active, and /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq reflects the change, /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state shows that actually there is no real frequency change, and after a second or two, op_active reverts to the value configured in op_dsp.

Actually, looking at this, I have an idea. The original op_dsp patch limits the op states to 0 and 1, while the Diablo kernel sets the op state to 1. If we allow more op states with the dsp active, we can get significant battery gains by choosing state 2, or even 3 if it works.