maemo.org - Talk - ANNOUNCE: Diablo-Turbo first beta available

maemo.org - Talk (https://talk.maemo.org/index.php)

- OS2008 / Maemo 4 / Chinook - Diablo (https://talk.maemo.org/forumdisplay.php?f=29)

- - ANNOUNCE: Diablo-Turbo first beta available (https://talk.maemo.org/showthread.php?t=69740)

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by jstokes (Post 947046)

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by Kroll (Post 947438)

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

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by lma (Post 947050)

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by auouymous (Post 947419)

Listening for disable_ts and turning off polling while locked would be a good start.

Done. See post above.

Quote:

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.

Quote:

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by maacruz (Post 947462)

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

Re: ANNOUNCE: Diablo-Turbo first beta available

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by alephito (Post 947671)

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

Quote:

Originally Posted by n9ots (Post 947936)

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.

Re: ANNOUNCE: Diablo-Turbo first beta available

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.