yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] igor.tonky:
okay, new drain tests :)

live_oc: 120

voltages: stock, except 900 for 120, 925 for 240 and 1275 for 1200.

1) 25-26 oct

0030 - 0927: 72-38%

airplane, conservative

15K, 80, 40

di disabled

2) 26-27 oct

2150 - 0911: 73-33%

airplane, ondemand

40K, 95

di disabled

3)27-28 oct

2330-0957: 100-68%

airplane, ondemand

40K, 95

di enabled

i've left phone playing music overnight, for three nights. first two i was using franco's 2511 kernel, last night with di enabled i was using 2711 kernel.

what am i missing here? does my phone drain too much by itself, so i can't see the difference between di and non-di?

p.s. it looks like my drain went from about 23% in 8 hours to about 26-30%. i guess it's due to 120 overclock.
[Nexus S Android Development] pan1980:
i admit that i cannot see any difference too, at least a remarkable one.

i use trinity kernels.
[Nexus S Android Development] Ezekeel:
The difference between DEEP IDLE enabled and disabled according to your data is 40% drain without DEEP IDLE vs 32% with DEEP IDLE. That is a reduction of battery consumption by 20%. Granted it is not as significant as the 55% I got in my test runs, but that might vary depending on the music player used and the file format. Also the starting battery charge was different between these runs and since the battery discharge is not linear this might also affect the results.
[Nexus S Android Development] igor.tonky:
the percentages are for different time periods, as stated by time before them. 40% in 11.5 hours, and 32% in 10.5 hours, so the projected drain difference is about 5%.

yes, the charge was different, but the data shows pretty much identical discharge pattern for all three test runs, so i don't think third try would differ much if started from 73%.

anyway, i'll wait on the franco kernel with your latest update and test some more, just thought maybe i'm missing something with the way i run tests.
[Nexus S Android Development] steve.garon:
Hi ezekeel,

Yesterday I had an abnormal battery drain while the phone was sleeping in airplane mode. I usually loose 1-2% in 9h while in airplane mode but this time something apparently triggered the nfc chip and it drained 60% of the battery.

I was wondering if the nfc needed some special attention like the bluethooth for deepidle. It might also be completely unrelated but I'd still like to hear your thoughts on this.
[Nexus S Android Development] morfic:
And look into the gps not being usable after sleep someone mentioned while you are at it. ;)
[Nexus S Android Development] SA-07:
Makes sense, matrix isn't a performance kernel
[Nexus S Android Development] Ezekeel:
The NFC chip? Hmm, that is unexpected. I will see if I can get an NFC tag somewhere for testing it systematically.

I am about to go visit a friend and will test recording the way there with My Tracks. This should show any problems with GPS.
[Nexus S Android Development] steve.garon:
I didnt know there where gps issues. I had mine turned off for the pass month.
[Nexus S Android Development] Ezekeel:
I can confirm that GPS is not working properly. I will look into it.
[Nexus S Android Development] yaronyud:
than what are you aiming your kernel 4? because so far i can see very good preformance with your kernel comparing to others...
[Nexus S Android Development] jeffkhlam:
thanks a lot. its important to many of us. appreciate your effort.
[Nexus S Android Development] skitapa:
The NFC chip is activated by a regular credit card if they are equipped with a chip (most of them are) it could happen that someone placed their phone on the wallet for the night and it kept looping. Just a though :-)
[Nexus S Android Development] Ezekeel:
Fixed GPS problems.

Bugfix: http://www.pastie.org/2775884
[Nexus S Android Development] PLEEZEFRAGME:
I am out of Ideas. Can anyone give me a step by step guide how to enable the DeapSleep mod? someone gave me an link about "You need to load the logcat module. Try using imsmod modulename. Look in a modules dir, don't know where in android. " but i dont understand one word of it.

I understand that i have to use imsmod but how? "imsmod -f /system/bin/logcat" for example?

im realy confused. Seems to work for all the other right from the start why not here?

Did a fresh cm7.1 install, wiped befor (all3 wipes) and installed the kernel after that. What did/do I do wrong?
[Nexus S Android Development] franciscofranco:
Terminal

Type "su" - enter

Type "echo 1 > /sys/class/misc/deepidle/enabled" - enter

Done
[Nexus S Android Development] PLEEZEFRAGME:
thank you. now i got it, but "dmesg" still gives me an "function not enabled"...

sorry for my bad english btw.
[Nexus S Android Development] franciscofranco:
We're going a little off topic here, but if you're using my kernel yes dmesg is disabled, I don't want it :)
[Nexus S Android Development] PLEEZEFRAGME:
it´s not really ot here...its about the DeepIdle.

Yes i am using your Kernel^^ Propably should ask in your topic.

Is there a way to test DE is enabled right now? (well, exept turn of the display and wait 2 hours)

thank you for your help.
[Nexus S Android Development] franciscofranco:
cat /sys/class/misc/deepidle/enabled

If it returns 1 then it's enabled, but it's enabled by default in my kernel.
[Nexus S Android Development] Serious_Beans:
How do I get a logcat from my phone? Using the latest deep idle kernel from morfic my phone reboots every time I put it to sleep, only happens with his deep idle kernel so I'm assuming it's that, but idk trying to rule out problems.
[Nexus S Android Development] franciscofranco:
adb logcat > logcat.txt
[Nexus S Android Development] Ezekeel:
I put the DEEP IDLE state with TOP=ON back in; it is used when GPS or BT are running. With these changes when the screen is off we always have an efficient low power state available for race-to-idle. Thus when the screen is off we can (and should) always use the highest frequency available. This can be achieved with the help of screen-off profiles or using the latest version of lazy with screenoff_maxfreq enabled. Since lazy also seems to be the most efficient governor around for the time the screen is on (http://xdaforums.com/showpost.php?p=18871979&postcount=45), I recommend using it.

Bugfix: http://www.pastie.org/2778855

I also tried to reproduce the WiFi problems some people were having, simply by continuously pinging the device from my PC and after like 20min minutes the connection apparently shut down. However it reactivated automatically once I woke up the device, so I guess this is just the normal power saving feature.

Update: Turns out I had the WiFi sleep policy not properly set to keep the WiFi awake. Thanks MK for the heads up; I would have never found that setting on my own. I will give it another try and report back.
[Nexus S Android Development] franciscofranco:
Thanks for the update, I'll test this with lazy + maxfrequency while scree off and will report back.

I had to laugh on that last part, it was funny eheh
[Nexus S Android Development] Ezekeel:
I have been running the ping test for 90min and the WiFi did not drop once, so I guess there is no general problem with going to DEEP IDLE while WiFi is activated.

I also tested GPS and it is working fine with DEEP IDLE with TOP=ON. I do not have any BT headphones to test BT so any feedback is appreciated.
[Nexus S Android Development] Ezekeel:
Made some improvements, so people are able to get some statistics about the use of the different idle states.

For each of the different idle states, the number of idle calls and the total amount of time spend in each state are saved. These stats can be shown using 'idle_stats' in the sysfs interface and resetted with 'reset_stats'.

Bugfix: http://www.pastie.org/2779930
[Nexus S Android Development] igor.tonky:
can you please compile and post your kernel with all the modifications so we could test it?

i'd love to compile it myself, but it stucks on the boot with attached logcat. i tried your .config or make defconfig - the result is the same.

the toolchain is from the latest ndk: CROSS_COMPILE=/opt/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi

i tried it with ubuntu and codesourcery - same result :(
[Nexus S Android Development] Ezekeel:
I am still using CM 7.03 (2.3.3) and I guess you tried it on 2.3.4 or later.

If anyone wants to try it: http://www.multiupload.com/TX9GJNM0GF
[Nexus S Android Development] franciscofranco:
Thank you!

I've been running with your last two bugfixes for about 4/5 hours and I notice a big improvement, obviously with Lazy + screen off max frequency and everything works fine. I'm impressed, nice job.
[Nexus S Android Development] from1989:
i find that the battery lost 15% last night with your kernel 20111027 at lazy governor at 100/1000 and if i go on 400/1000 it will save power when i listen to the music with screen off??
[Nexus S Android Development] morfic:
Thanks, now i just need to find out why my phone does not enter deep idle.

No change in battery consumption let me to think it isn't, now i see it isn't:

idle state total (average)

===================================================

IDLE 1398502ms (18ms)

DEEP IDLE (TOP=ON) 0ms (0ms)

DEEP IDLE (TOP=OFF) 0ms (0ms)
[Nexus S Android Development] sixstringsg:
I am glad to see that our code helped y'all out. I actually have a nexus coming in the mail, so ill be around.
[Nexus S Android Development] franciscofranco:
Just tried to see my stats and it just shows 0ms in every field... am I missing something here or does it need something about debug enabled in the kernel config?
[Nexus S Android Development] igor.tonky:
yup, same result with same logcat. must be 2.3.3 then. oh well, i guess i'll try fixing the wifi module error compiling franco kernel, he's pretty good staying updated with your patches, thanks anyway ezekeel!
[Nexus S Android Development] Ezekeel:
DEEP IDLE is not used when the device is connected to USB; I think I never mentioned that. If that is not reason, I have no idea what the problem is. The only thing you can do is put some debug statements in the code to see which check is keeping it from entering DEEP IDLE.

I guess it is possible that some debug option you disabled is necessary for this to work. If you find out, please let me know which option it was.
[Nexus S Android Development] morfic:
morfic@othris:~$ adb shell cat /sys/devices/system/cpu/cpu0/cpuidle/state0/time

* daemon not running. starting it now on port 5037 *

* daemon started successfully *

687649294

morfic@othris:~$ adb shell cat /sys/devices/system/cpu/cpu0/cpuidle/state0/usage

21611

morfic@othris:~$
[Nexus S Android Development] Ezekeel:
That is the total idle time for all three different idle states added up. And idle_stats still does not show any usage of the DEEP IDLE state?
[Nexus S Android Development] morfic:
Correct.

I pasted this to show both have values, despite the zeros in the stats
[Nexus S Android Development] morfic:
I can pretty much reproduce this:

Use a lot of apps, all backgrounded, not backed out of, so they are running.

Screen off through power button.

Count to 10.

Reboot.

Edit: Catalyst right now is camera use. After next reboot I will just use camera after phone is booted up.
[Nexus S Android Development] morfic:
Can not reproduce the Reboots with didle disabled.
[Nexus S Android Development] Ezekeel:
I tried it and cannot reproduce the reboot problems.
[Nexus S Android Development] Jonathon Grigg:
I tried reproducing morfics steps, no issues there with all the latest fixes. However I have had issues in the past with deep idle and camera, but I haven't used camera much since I flashed my test kernel. It may be something to do with camera module power usage not going too well with deep idle?

Sent from my Nexus S
[Nexus S Android Development] isikh:
Any idea why I'm getting random reboots on deep idle enabled kernels? I'm using my good man, Morfic's kernels. Nexus S T-MoUS
[Nexus S Android Development] mike216:
Because of the higher buss speed try raising voltages

Sent from my G1
[Nexus S Android Development] isikh:
Are you referring to my question: Any idea why I'm getting random reboots on deep idle enabled kernels? I'm using my good man, Morfic's kernels. Nexus S T-MoUS

?

If so, how would I go about doing that? I have setcpu.
[Nexus S Android Development] mike216:
Yes I was and I'm not sure on morfics kernel because his isn't available on set cpu but I'm sure many users on his thread might be able to help you and if it isn't possible then you might have to go with one of his higher voltage versions of trinity

Sent from my G1
[Nexus S Android Development] isikh:
Ah, I see thanks for your help; Can anyone else provide some input? :)
[Nexus S Android Development] FloHimself:
The reason that you don't even get the IDLE count is because of this.

My device doesn't enter deep idle because of this:

<6>[ 509.389274] cpuidle: ===================================
<6>[ 509.390465] cpuidle: check_power_clock_gating()
<6>[ 509.391124] cpuidle: check_usbotg_op()
<6>[ 509.392304] cpuidle: ===================================

and that is with USB not connected.
[Nexus S Android Development] Ezekeel:
Good catch. I did not look at the details, but that actually could have caused the problem.

That is strange. I assume you tested that with screen-off, right? In that case check_power_gating() should not be 1 all the time. Also check_usbotg_op() should be only 1 when the device is connected to USB. I guess you are using the i9023 and there might be some differences to the i9020 which I am using. What kernel are you running? Maybe someone with a i9020 and the same kernel can test if their device behaves the same, so we can exclude differences in the hardware models.
[Nexus S Android Development] FloHimself:
Yes, I tested this with screen-off. I'm running a i9023 with a 2.3.6 stock ROM with a cyanogenmod based kernel.

If someone with a i9020 would be so kind to test this:

The kernel source is here: https://github.com/fschaefer/samsung-kernel-crespo/tree/test

A precompiled kernel here: http://dl.dropbox.com/u/31174/android/cm_crespo_kernel_flohimself_v1.zip

S5PV210_PD_LCD and S5PV210_PD_CAM are always powergating!?

<6>[ 297.262815] cpuidle: ===================================
<6>[ 297.262948] cpuidle: S5PV210_PD_LCD | S5PV210_PD_CAM | S5PV210_PD_TV | S5PV210_PD_MFC | S5PV210_PD_G3D
<6>[ 297.263023] cpuidle: S5PV210_PD_LCD: 8
<6>[ 297.263154] cpuidle: S5PV210_PD_CAM: 32
<6>[ 297.263225] cpuidle: S5PV210_PD_TV: 0
<6>[ 297.263296] cpuidle: S5PV210_PD_MFC: 0
<6>[ 297.263426] cpuidle: S5PV210_PD_G3D: 0
<6>[ 297.263497] cpuidle: check_power_clock_gating()
<6>[ 297.263569] cpuidle: loop_sdmmc_check()
<6>[ 297.263699] cpuidle: check_usbotg_op()
<6>[ 297.263771] cpuidle: ===================================
[Nexus S Android Development] Ezekeel:
Hehe. Did you directly print the values of S5PV210_PD_LCD and S5PV210_PD_CAM? Because these are just bit masks. The way you use them is getting the value of S5P_NORMAL_CFG and then apply a bitwise and '&' using the bitmask. If the value is 0 the corresponding module is deactivated else it is

activated.

For example:

val = __raw_readl(S5P_NORMAL_CFG);
status = val & S5PV210_PD_CAM

If status is 0 the CAM module is deactivated, else activated.
[Nexus S Android Development] FloHimself:
I print them like this:

val = __raw_readl(S5P_NORMAL_CFG);
printk(KERN_INFO "cpuidle: S5PV210_PD_CAM: %lu\n", val & S5PV210_PD_CAM);
[Nexus S Android Development] Ezekeel:
Ok. That is correct.

Then you are right and the CAM and LCD modules on the chip are not powered off (or at least not marked as powered off) when the screen is off.

I did some quick tests with the stock camera app and when the screen is off (either on sleep or kept awake with Touch Wake) the DEEP IDLE state is properly used. I guess you did not even have the camera app running during your tests, so this is definitely strange.

Update: The only places where S5P_NORMAL_CFG is changed are arch/arm/mach-s5pv210/power-domain.c and arch/arm/mach-s5pv210/pm.c. I guess that is a good place to start. I am still on 2.3.3 and maybe there were some changes after that which broke something.
[Nexus S Android Development] morfic:
Time for you to cease working on 2.3.3 if you are serious about deep idle i think.
[Nexus S Android Development] FloHimself:
I'm already diggin in the power domains...

btw: someone here reported about reboots... if I open the camera app and close it again, val & S5PV210_PD_CAM reports 0. after that animations slow down and i get a reboot...

update: arch/arm/mach-s5pv210/power-domain.c and arch/arm/mach-s5pv210/pm.c don't have changes

---------- Post added at 04:37 PM ---------- Previous post was at 04:04 PM ----------

update 2:I've now the following behavior:

on boot something sets "val & S5PV210_PD_CAM = 32".

when I open the cam app and close it again "val & S5PV210_PD_CAM = 0".

when the LCD gets off (I guess it enters deep idle now), the device reboots.

update 3:I removed my debugging stuff. the reboots are gone. maybe the kernel just don't like printing when just entering deepidle...

When I open and close the cam app once after reboot I get:

# cat idle_stats
idle state total (average)
===================================================
IDLE 21234ms (0ms)
DEEP IDLE (TOP=ON) 0ms (0ms)
DEEP IDLE (TOP=OFF) 1602ms (17ms)

update 4: nope... device is still rebooting... :(
[Nexus S Android Development] polobunny:
cease

/grammar nazi flies off
[Nexus S Android Development] Ezekeel:
The slowdown is because you use the DEEP IDLE state with TOP=ON while the screen is on. Don't do that.

Yeah that probably would have been too easy.

Ok. So there is way the ROM and apps can influence the power state of the CAM module and something seems to be activating the CAM on boot. This can either be the kernel itself or some function in the ROM or even an app that activates it. Or the kernel activates CAM by default and the ROM is supposed to disable it on boot, but does fail to do so. That is hard to tell who the culprit is for this problem.

What puzzles me is that the device seems to enter DEEP IDLE (assuming that causes the reboot) after CAM was switched off, meaning that also LCD must have been deactivated. Maybe when CAM is active also LCD will be kept active even when the screen is off. So, solving the CAM issue might also solve the LCD issue. Still won't explain the reboot, but one step after another...
[Nexus S Android Development] FloHimself:
oh, sorry. I haven't seen false values for S5PV210_PD_LCD in my last tests. I assume I had some module enabled (backlightdimmer or something??) that prevented the LCD going to sleep.

So two problems remain:

1) "val & S5PV210_PD_CAM = 32" on boot

2) reboots when the device enters deep idle.

Update: I'm still not sure if this is a kernel version issue or a device version issue!?
[Nexus S Android Development] Ezekeel:
1) Well as I said above, the problem could be with the kernel, ROM or even an app activating CAM on boot. One could try to find some on/off switch in the sysfs and switch CAM at the end of boot with an init.d script.

2) Try using lazy with screenoff_maxfreq enabled. There seems to be a problem with the lower frequencies. Also try not using any OC or UV - maybe something is not 100% stable.
[Nexus S Android Development] Ezekeel:
Some changes for the new idle_stats feature.

1. Changed stats variables to 'unsigned long long' to defer overflow and keep the idle times in us for increased accuracy.

2. In case of an overflow of one of the stats variables, all stats are resetted.

3. Put in a mutex to prevent simultanous access to the stats variables.

Bugfix: http://www.pastie.org/2788087
[Nexus S Android Development] FloHimself:
Well, thanks for all your help Ezekeel! I disabled all overclocking and undervolting features while testing... still no luck. Maybe I try with your kernel with CM 7.0.3. Is there a special reason you're still using this version?

Update: running CM 7.0.3 with your kernel and deep idle is running stable on my device.
[Nexus S Android Development] Ezekeel:
Never change a running system. Having a stable development environment is worth a lot. Also ICS is around the corner, so one would have to update again shortly after.
[Nexus S Android Development] invd:
Well, I'm really no dev, but just a thought - GTalk usually turns cam on in the boot process...
[Nexus S Android Development] Ezekeel:
It turns on the cam by default even if it is not used? That would be a quite silly behavior. What is your source on that info? I also have the Google Talk app installed with automatic sign-in and I do not any problems.
[Nexus S Android Development] waterface:
Hello, and excuse me in advance for a newbie question. Where do I have to look to see that? Or how do I perform the same test?

I am having trouble with my phone apparently not entering deep idle (Nexus S i9023).

Thanks a lot for helping out

---------- Post added at 10:55 PM ---------- Previous post was at 10:47 PM ----------

Is there already a downloadable kernel I can try that has these two last bugfixes? I'm running NSCollab based on 2.3.7.
[Nexus S Android Development] morfic:
Does your gtalk support the video cam? considering how ancient your setup is.....
[Nexus S Android Development] Ezekeel:
Good question since I actually never used it. I just checked and I cannot find any mention of camera in the menu or the settings. So if there is an older version out there without camera support I actually might have that one installed. Maybe Google messed up when implementing the camera support. A quick check would be to uninstall the app and see if the camera still gets enabled on boot.

Update: I checked and I have Google Talk version 1.3.
[Nexus S Android Development] franciscofranco:
Me too, and I ain't got problems with any camera and reboots.
[Nexus S Android Development] morfic:
Gtalk version 1.3 here too.
[Nexus S Android Development] morfic:
I sure wish there was a reference source tree, i might have a chance to find the source of reboots on my kernel, going through all netarchy changes, the large amount of changes since 2.3.3 by samsung, makes it difficult to pinpoint essential differences.

Maybe there will be one for the ICS source.

thanks for your work,

Daniel
[Nexus S Android Development] FloHimself:
FYI:

I just tested a clean install of CM 7.1.0 and the cam wasn't enabled after boot. But the device still reboots when entering deep idle. This is with my CM based kernel. When I get some time I would test a stock rom with a stock based kernel.
[Nexus S Android Development] invd:
Well, it seems, I was wrong - I did a little search and found nothing. It seems that this was a special behaviour of GTalk on the Motoroloa Milestone (on every boot the activation sound of the camera was played and I remember there was a discussion about this init-behaviour somewhere). So forget what I said (btw: GTalk 1.3 here too) ;)
[Nexus S Android Development] Ezekeel:
Yeah a reference tree would be nice.

Good to know the CAM problem is not with the kernel, but with the ROM or some app.

I will wait for the other kernel devs to catch up to the latest version and see how DEEP IDLE is working for them and their testers. If it working for them, it probably is not a problem with the official updates that came after 2.3.3. Also with more testers maybe we can see some sort of pattern emerge.
[Nexus S Android Development] franciscofranco:
Yes I'll release my updated kernel today and I'll probably grab some useful feedback for you.
[Nexus S Android Development] FloHimself:
I took this and pushed it to this, but can't get it to boot on my device.
[Nexus S Android Development] Ezekeel:
Great. Did you manage to get the idle_stats times working with your kernel? If not, maybe you could add a little bandaid and additionally print the num_idlecalls values, which at least would show that DEEP IDLE is properly used.
[Nexus S Android Development] franciscofranco:
I haven't tried yet with your latest commit, had to sleep few hours to maintain my mental health :p

I will try now.

EDIT: nah doesn't work. I'm gonna try few things.