Reply
Thread Tools
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#61
Originally Posted by jstokes View Post
If the tablet is locked, it should be - "1" is written to /sys/devices/platform/omap2_mcspi.1/spi1.0/disable_tp by MCE/SystemUI AFAIK. My understanding of the kernel is rudimentary but if the sysfs interface is anything like the procfs one, isn't a function (via a pointer) invoked when a file is written/to be written to, so even if it's not "disabled" (i.e. events are still picked up but not acted upon), you can still get notification and stop the polling accordingly?
It actually was quite easy.
New DT test kernel: deleted
Changes:Stop touchscreen polling when locked, so cpu usage due to touchscreen driver shouldn't be of any concern.

Now, before you flash, try to collect some hard data to see what impact polling really had:
Testing protocol:
Plug your device and let the battery charge completely
Unplug it and leave it alone locked for 1 hour
Plug it and let it charge again fully (this is to avoid battery hysteresis)
Unplug it
"sudo cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state" and take note of the values
"battery-status" should say 100%
Lock and leave the device alone for about 8 hours (just the night, 24 h would be better but you don't want to be without your device for a day, do you?)
Then repeat "sudo cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state" and "battery-status" and take note.

Flash the new kernel and repeat the test protocol.

Last edited by maacruz; 2011-02-16 at 20:35. Reason: Deprecated testing binary deleted
 

The Following User Says Thank You to maacruz For This Useful Post:
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#62
Originally Posted by Kroll View Post
Usually i listen music for 2-3 hours everyday and charge n810 once per two or free days! And I take notes, checking the mail etc and my tablet keeps the charge for two days minimum.
Ok, tomorrow I will make a test...
default one so 400/133 i guess...
But it is not the same to listen music using the dsp and to listen music using the cpu.
mplayer == cpu only -> 400/unused -> about 5 h playback
osso mediaplayer == dsp -> 333/266 default -> about 7 h playback
 
Posts: 1,101 | Thanked: 1,184 times | Joined on Aug 2008 @ Spain
#63
Originally Posted by lma View Post
But no physical I/O which should offset that. I've been running mine with ramzswap for many months and haven't noticed any reduction in battery life. I don't have any useful data or observations for the "turbo" kernel yet.
I think that ramzswap actually could even be a gain, but it makes an interesting test case. I'll try to make a test.
 
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.
 
Posts: 398 | Thanked: 301 times | Joined on Sep 2007 @ Texas
#65
Originally Posted by maacruz View Post
But it is not the same to listen music using the dsp and to listen music using the cpu.
mplayer == cpu only -> 400/unused -> about 5 h playback
osso mediaplayer == dsp -> 333/266 default -> about 7 h playback
FWIW, I recall but can't find the relevant post that the 400/133 mode may be lower power consumption than 333/266 because the DSP does not idle where the ARM does. At one point, I had a 400/133 kernel loaded and don't recall a change in battery life, but that's just a general impression.

BTW, thanks for the effort, the touchscreen bug is highly annoying so I'm really looking forward to fixing that.

Frank

Last edited by Frank Banul; 2011-02-15 at 23:32.
 
Posts: 674 | Thanked: 191 times | Joined on Mar 2008 @ Buenos Aires, Argentina
#66
I have two problems:

1) From time to time, when my N810 is idle and I touch the screen to wake it up, the last app used in the previous session starts automatically. I am sure that I am not pressing over any link to that application.

2) The Application Manager shows me an update to the OS2008 Community SSU but it cannot be installed because of missing packages (yours are newer).

Thanks.
 
Posts: 24 | Thanked: 8 times | Joined on Oct 2007 @ Finland
#67
I havent tried the new kernel yet but I did get the "TSC2301: Pen down data with no irq" on the dmesg now after drawing for quite a while so it seems the polling does catch some data.
 

The Following User Says Thank You to andy1 For This Useful Post:
n9ots's Avatar
Posts: 139 | Thanked: 38 times | Joined on Nov 2007 @ mid gulf coast florida
#68
Originally Posted by alephito View Post
I have two problems:

1) From time to time, when my N810 is idle and I touch the screen to wake it up, the last app used in the previous session starts automatically. I am sure that I am not pressing over any link to that application.
This happens to me occasionally (although not since upgrading to DT kernel and junk).
I suspect it has something to do with the launch bar applet, as the only programs that launch as you describe are those available on my launcher.
 
Posts: 674 | Thanked: 191 times | Joined on Mar 2008 @ Buenos Aires, Argentina
#69
Originally Posted by n9ots View Post
I suspect it has something to do with the launch bar applet, as the only programs that launch as you describe are those available on my launcher.
Yes, that is true: the applications that start automatically are in my Personal Launcher. But in my case this behavior started with the installation of this beta.
 
Posts: 206 | Thanked: 46 times | Joined on Mar 2010
#70
Just installed the beta ( I know, I'm late for the party!). I love the snappyness. Though boot time seems longer, other than that I haven't noticed any negative.
 

The Following User Says Thank You to cstryon For This Useful Post:
Reply

Tags
chinook, diablo, new life, os2008


 
Forum Jump


All times are GMT. The time now is 17:38.