Re: ANNOUNCE: Diablo-Turbo first beta available
 

The messages from the new driver code are:
TSC2301: Pen down data with no irq
TSC2301: Data available after penup timer
(N810 messages are TSC2005:...)
They will be produced if the driver detects lost data, which may or not may happen in your (or even any) N800 (in my N810 it happens for sure). But even if there is no hardware failure for the driver to correct, the new code shouldn't cause any harm.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

The new kernel works perfectly, I tried drawing for quite a while but did not get any messages, though it feels better but it can be also placebo effect =), anyway thanks for all these, I still use my n800 almost daily and sadly I have been hit by the dsme bug so I have to buy a new battery as it reboots constantly when charging but otherwise it is still as good as new and works perfectly when not charging.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

maacruz
Some people (from n8xx.com) (and me as well) found Diablo-Turbo drains battery MUCH faster. Usually I charge my n810 once per two days, last night I charged it and in the end of the next day with 2 hours music listening and 1 hour BT + Opera my n810 was a bit less then dead.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

There are only two things that may have an impact in battery life:
1- The dsp_op state: If the cpu is configured at 400 MHZ instead of 333, battery life will be shortened when playing music. By default it is at 333, but you can check it; play some music and "sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq"
2- The touchscreen driver has a 75 ms poll, but I doubt it has much an impact in battery life, since it lasts microseconds, but I use the device very heavily so may be I don't notice it. I could make it tunable so it can be altered or switched off.
You should make a testing protocol to make sure the change in battery life is for real and how much it is. I find opera to be a big battery drainer, in particular if javascript is enabled.

EDIT: If the dsp is not in use, the cpu governor also has a say in battery life. The SD scheduler makes small changes to the nice load definition, so may be this could affect how much time the cpu is in each op state. Make sure that in your test protocol you check /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state before and after.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Does the SSU kernel poll the touchscreen? If not, does the DT kernel continue to poll at this rate while the screen is off or locked?

--

Do you know how to tell if the DSP is active? I'm thinking about displaying something in ASUI when it is and also add a toggle to easily change the op_dsp state.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

In the Opera thread it is stated that the browser do not let the system sleep while the browser is open, much the same issue that was had with the terminal at one time (and may still have, dunno).

Re: ANNOUNCE: Diablo-Turbo first beta available
 

The SSU kernel relies only on the irq, so no, it doesn't poll. The DT continues polling at this rate even if the screen is locked or turned off (the poll isn't actually for touchscreen data but just a check to see if there is data available). While I haven't specifically tested it, I think that the touchscreen is never disabled, and the data is simply discarded at a higher layer when the screen is off.

Anyway, I can make a test kernel with tunable polling, then we can meassure if it has any impact by leaving the device alone for some hours with and without polling after a full charge.

Sure!
/sys/devices/platform/dsp/state is 0 if the dsp is not active.
Having such a toggle would be great, I was about to ask you the same. Beware that the op_dsp can only be changed if the dsp is not active, otherwise it throws a device busy error. I'll see if I can modify the op_dsp patch to allow changes on the fly, since the current op state can be modified by writting to /sys/power/op_active even with the dsp active.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

[uncloaking...]
I wonder if this might be because of ramzez. I thought I noticed decreased battery before with the vanilla n810 kernel and ramzez installed when I tried it before.

- John
[cloak on..]

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Well there will be some extra cpu activity compressing and decompressing the swapped out data.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

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?

Re: ANNOUNCE: Diablo-Turbo first beta available
 

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.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

well there is the swap_prefetch to consider now, not sure how that affects things.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Hm, the plot thickens. It turns out my swap notify patch is identical to 08-patch_swap_notifier_generic_2.6.25.diff, but the DT kernel doesn't exhibit my problem. I must be screwing up somewhere else...

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Doesn't, at all. It is a veeeeeery loooooooong period timer.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Are you using my ramzswap 0.5.5 modules? The 0.5.4 release from compcache homepage is buggy and crashes on swapon/swapoff. Ah, and don't expect the 0.5.3 modules from ramzez-init to be compatible, either.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

With your kernel, yes. Previously I was playing with hand-rolled 0.5.4 ones on CSSU + swap notify kernel.

Aha, that seems to explain it then. But... where did you find 0.5.5?! It's not listed in http://code.google.com/p/compcache/downloads/list at least.

Edit: I see, you didn't "find" it, you fixed it yourself - thanks! :-)

Re: ANNOUNCE: Diablo-Turbo first beta available
 

maacruz
I was too busy to investigate battery problem but today I lost 20% of charge as I listened music for an hour. (quasar using mplayer).
May be it is because of Advanced sistemui made by auouymous, but I think it is Diablo turbo.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Kroll, that battery usage is consistent with the use of mplayer to play music, no matter the kernel. If you use mplayer to play music the cpu will be running at 400 MHZ constantly, since the cpu is doing the decoding, and that means 5 hours of battery life. 1h/5h=20%
I'll address any issue you find, but you have to make a proper test, reproductible, and with both kernels to spot the difference. Please, understand that I can't test everything myself, just don't have enough time.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Are you using 400/133 or 333/220 ratio? Try running `/etc/init.d/advanced-systemui stop` as root before you listen to music next time and see if the battery still drops by 20% in an hour.

Listening for disable_ts and turning off polling while locked would be a good start. How hard would it be to use a dynamic polling rate that decays between two tunable values the longer no data is available?

What does op_active do?

Re: ANNOUNCE: Diablo-Turbo first beta available
 

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...

Re: ANNOUNCE: Diablo-Turbo first beta available
 

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
 

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
 

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
 

Done. See post above.

I'd rather have some actual data of the real battery impact before trying to implement something like that.

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
 

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
 

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
 

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.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

I've been suffering this problem since I installed the launch bar applet, a loooooooong looooooooong ago, although it hasn't happened lately, may be since I started the DT beta.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

:) Lucky you. I have never had that bug until now. But I can live with it.

What about the other "problem"? I mean the "broken" Community SSU update.

Thanks.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

I implemented this idea and today did some limited testing to measure the battery consumption while playing music under the different possible states using the dsp.
Testing protocol:
Start with battery at 99%, should not drop under 75%
Set op state. Start playing music (128 kbps mp3, easy music) using osso-mediaplayer. No other programs running.
Start the measuring script:
Lock and switch off the screen (I have it configured to switch off in 0 seconds).
Wait 15 min, then unlock the device, stop the music and take note of the values.
Do it again with other op state. First I alternated op 0 and 1, 3 measurements each. Then, charged the battery and repeated the procedure with op 1 and 2, 2 measurements each.

Results:
After the first 6 measurements, I realized the battery meter accuracy was no better than 0.4 %, so the error was in the 20% range. 15 minutes is not long enough, for good measurements it would need 1 hour to keep the error under 5%, but since I already had 6 measurements I continued anyway with the op=1 and op=2 states.
Later, for completion, I did a run of mplayer (bare mplayer in other xterm).

This is how much the battery dropped in each state in 15 min:
0 (400/133) -> 2.8 % (11.2%/hour)
1 (330/220) -> 2.4 % (9.6%/hour)
2 (266/177) -> 2.0 % (8.0%/hour)
3 (165/110) -> 1.6 % (5.6%/hour)
Later:
mplayer (400/0) -> 3.2 % (12.8%/hour)

Nothing like hard data :D

Conclusion:
For just music playing, op=3 is great, doubling battery life. Of course, the device struggles trying to play videos. Also tryed doing some other activity and it is usable, but slow.
Playing music with mplayer is really bad for the battery.
Someone who still runs the diablo/ssu kernel should do the same measurement (to the only available op), to finally dispel any doubt about battery consumption.

EDIT: Played same music during 172 min through speakers at maximum volume (they suck more power than earbuds), at op=3, battery went from 92.4% to 73.2%. That means 6.7%/hour

EDIT2: One hour measurement at op=1 (default value), using earbuds, battery went from 98.2 to 88.1, that is 10.1%/hour

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Mmm, looks like you may have installed the osso-software-version-rx44 package from Diablo instead Community SSU.
Check what release you have with "dpkg -l osso-software-version-rx44"
It should be 1:5.2010.33-1 (stable) or 1:5.2010.32-3 (testing)

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Here I go, again :D
New test kernel: https://garage.maemo.org/frs/download.php/9344/zImage

Changes: allow all 4 op states in op_dsp. op_dsp=3 -> 50% more battery life playing music (wrt default op_dsp=1).

Re: ANNOUNCE: Diablo-Turbo first beta available
 

And you have a N800! Cool!

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Same to me.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Could the gconf/dbus fixes have broken personal launcher? Maybe try reverting them back to old versions and see if problem goes away. Maybe compile a DT kernel without touchscreen patch and let them them test it with personal launcher.

Is it 400/133 or 400/165? The governor doesn't work when dsp is enabled, right? And changing op_dsp locks the frequency of both cpu and dsp?

Re: ANNOUNCE: Diablo-Turbo first beta available
 

The bug is in personal launcher, so it should be solved there. We shouldn't be chasing wild gooses.

It is 400/133
The governor does not work when dsp is enabled, op state remains constant.
Changing op_dsp sets the frequency that both cpu and dsp will have when dsp is active. op_dsp can't be changed when the dsp is active.

Re: ANNOUNCE: Diablo-Turbo first beta available
 

Does Diablo turbo apply the microb tweaks? If not, will it?

Also, I don't understand what the zimage is or how to use it...