yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] apatal:
The patch is something you include in your code if you're compiling a kernel, it cannot be flashed over a kernel, like in a ROM.

There is however a kernel available which contains the patch, among others, which is also developed by _thalamus. :)

Sent from my Nexus S
[Nexus S Android Development] teoserio:
on my i9023 and Remics rom it seems that there's more battery drain than INK (the version with DI by fear).

Btw I didn't try while listening music so I don't know if it is kernel related or something else
[Nexus S Android Development] _thalamus:
'seems that there's more battery drain' isn't massively helpful to be honest. More detail would be appreciated, such as some figures compared to a previous one of *my* kernels.

I'm not sure if there is an issue or not at the moment, looking at the time the device is spending in suspend makes me think that there isn't a problem, but if someone can show me that there is, I will look into it.
[Nexus S Android Development] :
Did you adjust both C2 and C3 residency at the same time? And I'm assuming it was with v0.380?
[Nexus S Android Development] :
I put c2 way up so it was almost unused. Yes v0.380
[Nexus S Android Development] :
IDLE2 v0.383

So, I've got a confession to make firstly.

I didn't do any incremental patches to go from 0.380 to 0.382, as I had squashed everything up to 0.380 and started doing: git commit -a --amend and before I knew it I had diverged a bit and was too lazy to copy and paste all my changes to make an incremental.

So...you are going to need to rebase out *all* the previous IDLE2 patches. Apologies, but I guess it's a good excuse to make a new branch and clean up your git. :)

The upside of this is that it is only 2 patches to apply after this which are located here.

Changes v0.380 > v0.383:

Add external kill function, see v0.383 commit message. Currently used to workaround modem bug and for suspend, can easily be used elsewhere if you find other problems in other devices. It can be called in oneshot mode or in an explicit mode. It is used in oneshot mode in modem_ctl.c and in explicit mode in wakelock.c.

Use system workqueue instead of dedicated workqueue. We don't have enough work to warrant the memory and cost of using a separate workqueue.

Work around modem bug which causes it to fail to recover if it crashes whilst idle2 is enabled. It appears that the modem doesn't / isn't able to fire an interrupt once it crashes, so the driver doesn't fire an interrupt to wake the A8 up from DEEP-IDLE, so it all goes horribly wrong. The modem_ctl driver is full of nasty hacks anyway, the fact it works is more luck than anything else.

Remove PM notifiers due to calling idle2_kill() from wakelock.c.

Minor tidying in other functions.

Removal of unrequired #includes (let me know if you get issues on other devices and I will add what you need back).

Prebuilt kernel from aformentioned IDLE2-v0.3xx branch is available here.
[Nexus S Android Development] :
So I found the source of the vast majority of the spurious scheduler_tick() wakeups which was stopping idle2 from achieving it's best possible residencies.

Previously, I was getting at least 25-30 wakeups per second, now I'm getting about 15 or less. It appears that the interactive governor was causing the additional ticks and subsequent wakeups. With interactive disabled even with the wifi bug because I forgot to toggle, the average residency while screen off and wakelock held doubled. Music playback residencies are slightly better too, but most of the wakeups come from I2S when music is playing back.

Anyway...I've worked around that in my kernel by implementing a boostpulse interface for ondemand and a PowerHAL for crespo, based on an idea from some work Steve Kondik has been doing on it. It actually appears to be smoother than interactive now, and I'm damn certain it's substantially cheaper.

I've already done IDLE2 v0.390, but I was sulking so I didn't release it on here. But as I've pushed the code, I might as well announce it. Changelog is in the commit text.

I'll do a prebuilt in the near future, but it needs a custom PowerHAL in /system/lib/hw to work with the default ondemand settings and perform correctly, so I'll have to update my build scripts so I can include it. I think I'll be sticking with ondemand plus my PowerHAL going forwards, as it performs just as well if not better than interactive and it's still my preferred governor.
[Nexus S Android Development] apatal:
I've actually been using ondemand for quite some time as it does "feel" cheaper in terms of power consumption, at least based on my experience. I keep noticing too that with ondemand, it tends to make use of the lower CPU freq more than interactive does, so I think this may contribute to better battery life. Still getting around the powerHAL you mentioned there. Sounds promising though, as always.
[Nexus S Android Development] knzo:
Nice nice, I'll test that Ondemand soon.
[Nexus S Android Development] knzo:
Seems to be as fast as Interactive indeed; I'll try to gauge the battery next.

However, the question is: does the overhead difference significantly affect the battery duration? I'm somewhat skeptical on this.
[Nexus S Android Development] :
Dunno, this thread is for IDLE2, not my ondemand changes. :p I only mentioned that as a side topic.

I should actually use my ****ing blog more.
[Nexus S Android Development] :
As regards IDLE2, I found earlier that simply having interactive compiled into the kernel causes the additional scheduler_ticks (which manifest as RTC_TICK wakeups). You don't actually have to be using it, ondemand can be in use, but simply having interactive as an option causes the issue. I found this because I *was* going to leave interactive as an option, but changed my mind rapidly after the problem manifested itself again.

I didn't actually realise that even when you aren't using a cpufreq governor, it is initialised anyway, so the threads are started, memory is allocated, workqueues are allocated et al. So less is definitely more there...lol. Makes me chuckle when I think about the kernels with 10 different governors all chugging away with their timers and work. Hahahahahahahahahaha (slow fadeout of laughter)...

It looks to be that it is because interactives main thread, kinteractiveup, is realtime and spins constantly. I blame that for the wakeups because it is calling schedule(), which I expect will cause a call to scheduler_tick() if I go and look through the code. Why on earth they have to use a realtime thread and a loop is beyond me. It isn't *that* critical that the CPU is ramped up in realtime. A millisecond latency will not hurt. Using workqueues and queue_work() would be more than quick enough, especially now they have boostpulse...and it would be a hell of a lot cheaper.

So yeah, thats my take on the interactive wakeups. As for battery usage, any wakeup from idle is going to use additional battery, *especially* on SMP devices which use coupled idle states because a tick will bring all the CPUs out of idle. Whether it will be measurable is anyones guess, but the fact is, less time in idle = more battery usage whether measurable or not.
[Nexus S Android Development] :
IDLE2 v0.391 here.

Minor changes, details in commit message.

Prebuilt kernel here. Includes correct power.herring.so this time too.
[Nexus S Android Development] caliban2:
Just wanted to add that these excessive time-ticks also happened with smartassV2 - which is interactive-gov rewritten. So I guess it's safe to say that any gov based on interactive is affected.
[Nexus S Android Development] polobunny:
Ha! Great finds there about having interactive active all the time. It's crazy to have anything in a realtime thread though in the computer world. Anything not critical should never come close to realtime, that's just asking for problems. :|

Props for all the work you've put in IDLE2 so far, this is shaping up to be real good. Can't wait!
[Nexus S Android Development] fear_factory84:
Hi thalamus, I flashed your latest idle2 kernel (0.391).

I can confirm that now bluetooth works fairly better (previously when my bt headset became out of range connection resulted always on until I manual disconnect it).

Auto connection from bt headset seems not to work. I have to initiate connection by phone. Anyone other that has this issue?

Battery drain compared to other kernels seems high (same cm10 nightly rom used).
[Nexus S Android Development] :
Yeah, unfortunately, bluetooth is probably going to continue to be a pain for some people / devices. There is no accurate way of detecting when it is in use, because it's continually enabled from ICS and above even when it is actually switched off. I'm not really planning on spending any more time attempting to solve the issues with bluetooth for a few reasons:

I don't use it so I have no way of testing it.

It works well enough for most people who use it.

There is a disable switch for IDLE2 if needed.

I don't really think *that* many people use bluetooth so it's a minority issue as far as I am concerned.

I've spent enough time on it already, and have other (better) things to do.

However, if anyone wants to solve the issue and send a patch, go ahead, and providing it actually fixes the issue and doesn't tear my codebase apart, I'll accept it.

As for the sleep battery drain, I am well aware of that and I do intend to fix it, although currently I have no idea why it is occurring. It seems to me almost as if IDLE2 is making suspend less efficient, which suggests to me that I'm not doing something I should be doing after it wakes from IDLE, so I intend to audit the code, compare it to the PM code and see what I'm doing wrong.

Of course, the issue may not lie there at all, I'm just taking an educated guess.
[Nexus S Android Development] madd0g:
Hm, the one posted earlier in the thread doesn't seem to exist any more (echo 1 > /sys/module/cpuidle etc). Care to share the correct current one ?
[Nexus S Android Development] :
To disable:

echo 1 > /sys/module/idle2/parameters/disable
[Nexus S Android Development] :
I've asked the mods to clean up most of todays posts which are unrelated to idle2, so they will all vanish soon...

I must also point out this is a developers thread, it isn't meant for end users. If you are a user with a question, come on IRC, the link is in my signature. Don't ask in here, because I'll request that the moderators delete it.
[Nexus S Android Development] veyka:
Thread cleaned, lets keep this on topic :)
[Nexus S Android Development] ilnanny:
Thank you so much for your great work

Inviato dal mio Nexus S i9023 Italia
[Nexus S Android Development] brenix:
thalamus... I've noticed several "idle2: |= IDLE2_EXT_KILL" messages in dmesg. It seems the more of these I receive/see, the faster the battery drains. I went looking into the code where you kill idle2 each time the modemctl_ioctl() is called and commented out the idle2 code. After doing this and running a test, I'm seeing a decent bump in battery life... I'm currently at 84% with 14 hours battery life, whereas I would probably be at 30% or 40% by now. It seems that my phone still enters the C1/C2/C3 states about the same as it did before. Even after commenting out the code, I have not noticed any side effects regarding mobile data or phone usage. Everything is working as expected..

I'm curious if there might be a better location in the code to call idle2_kill() or to reduce the amount of times modemctl_ioctl is called?? I have not tried increasing the amount of time to kill idle2 since I don't think it would bring much improvement... Any thoughts on this?
[Nexus S Android Development] :
Well, you are luckier than I was then. It may appear to be superfluous, but without that, if my modem crashes it will not restart itself, and I'm not alone with that issue.

The ioctl isn't called very often and will only be called when the modem status is changed, which only tends to happen when the modem is starting / stopping / crashing, etc.

If it is called regularly you have another issue related to your modem / network.

So no, nothing can be changed in regard to that I'm afraid.

I honestly don't believe that can have anything to do with the battery usage either. I think it's just a fluke that your battery hasn't drained because there is still an existing bug which causes suspend to become less 'efficient' once IDLE2 has been used.
[Nexus S Android Development] brenix:
Interesting... Good to know..I'll maybe look into it a bit more.. Thanks!
[Nexus S Android Development] boog:
Man, awesome work! Hopefully I can learn something from it.

So, for the kernel newbie, after applying the patches (I love how they use github!), is there any changes needed to the defconfig? Looking through the source, I want to say there isn't, but in order to try to learn more, I figured I would just ask.

Thank you for your work! I will give credit for your work, and hope I can eventually contribute some code back.
[Nexus S Android Development] Harbb:
I gave it the typical 10 hour music test as I'd done with Ezekeel's Deep Idle, however from the results so far seem to be in between Ezekeel's under -similar- circumstances and without DI. Your kernel doesn't have the same governors to play with so i'll force it to 1000Mhz and do another test too, replicating screen off max frequency.

I tested on a bog stock install of 4.0.4 from fastboot with no additional apps, only the kernel with BT streaming fixed was modified. Stats will be updated in a few minutes here, alongside other DI tests i've done.
[Nexus S Android Development] :
Thats interesting, it does show it is working though.

I have made substantial changes to the idle2 code today, which I suspect will improve the results somewhat, I haven't announced the changes on here yet, I will do that tomorrow, but they are available on my github and there is a new kernel available here. It would be good if you could test that.

I'm not entirely unconvinced that there wasn't / isn't a bug in 3.0.37 which causes additional power drain, but I haven't had time to look into that yet. I seem to remember .36 with idle2 using a lot less battery than .37 with idle2 is using.
[Nexus S Android Development] Harbb:
I'd be hard pressed to say it isn't working to some degree, but not convinced that it is currently working on par with Ezekeels current implementation if based only on these results (though with different parameters). Further testing will level the playing field either way.

I've always been a little hesitant about stating that it's working simply because there is no idle stats there (such as with Eugenes, which showed no idle stats nor battery life improvement). This is entirely due to things like the bluetooth quickswitch and camera module which prevented top=off results in Ezekeels DI. However with no precautions from boot yours seemed to get noticeably better results. It's great when things just work.

As for the next kernel version i'll test, PM me one which you'd prefer me to test within the next 12 hours. That's if you want me to try out one that isn't .37 or if you've added any other modifications to the idle2 code, else i'll just test the one above.
[Nexus S Android Development] veagles:
I tested version 18. I am not seeing any battery savings compared to stock.

I lost 5% battery for one hour of music playback with screen off, which is the same as what I get with stock.
[Nexus S Android Development] :
Oh, it definitely works. I added some debug code to make sure that the processor was obeying the WFI instruction, so there is no doubt that it does actually work.

I do, however, tend to agree that it isn't working 100%, I believe there was a bug which was causing battery drain because I was getting several % an hour yesterday whilst idling. I also believe that bug to be fixed in -19 kernel as I only lost about 1% an hour overnight, which is normal. I also got confirmation from another user that their device only used 3% in 7 hours. So, that bug appears to be fixed.

Now, as regards my latest v0.140 update:

I had to make some tough compromises in 0.140. I made the decision to modify the implementation so it doesn't use TOP OFF. I made that change due to hitting an impossible to resolve bug which involved bluetooth. There is no way of waking the device via bluetooth when it is in the TOP OFF DEEP-IDLE state. This means that after a while, idle bluetooth connections are dropped, whereas in TOP ON mode, they are not. The only way around this would be to check if bluetooth is active and set TOP accordingly. However, on ICS, without the framework patch, bluetooth is always active, and in the pursuit of keeping the code clean and cheap, I decided that I could vastly simplify idle2 by using TOP ON instead, and it would also, by default, resolve the bluetooth bug.

So, the 0.140 patch was born, which switches to TOP ON and removes the GPIO power down code, because that also isn't needed.

I then went through the entire idle2 codebase and removed anything which wasn't required when TOP ON was used. I removed the earlysuspend hooks and removed the ineffective and expensive wakelock code. I then added some calls to s5p_set_idle2_lock() in the suspend and earlysuspend code to disable idle2 when the device is suspending and to disable idle2 when the display is enabled.

All in all, these changes don't impact stability, they make idle2 much cheaper, and hopefully it should save more battery now the drain bug is fixed.

Go forth and test. :cyclops:
[Nexus S Android Development] teoserio:
you're right, I'm not so precise in testing stuff it seems :cyclops:
[Nexus S Android Development] :
When I measured battery drain with TOP=ON with ezekeel's version, I found there was no improvement over DI being disabled. Are you still interested in providing with- and without-IDLE2 versions for me to make a direct measurement?
[Nexus S Android Development] Harbb:
As bedalus said, all measurements with TOP=ON states seem to provide no measurable power saving. I see what you're getting at with the reasoning why you'd want to only use TOP=ON. It may be that your implementation is different enough from Ezekeels to provide similar power saving (hopefully so). After bedalus and myself do our testing on this latest version the decision should be clear cut anyway.
[Nexus S Android Development] :
It doesn't make sense that it wouldn't provide power saving if implemented correctly. The A8 is power gated when which must save power.

It's illogical to say turning the biggest power consumer off doesn't save power. I imagine that it is an implementation issue if it isn't working properly.

I encourage you to test it and let me know how it fares though. Obviously if it doesn't save power, I will further develop the implementation of it. It's a learning curve, I'm currently doing what I think is the right thing to do, I may be wrong however, and any input is welcome.
[Nexus S Android Development] :
Little bit of an update on development...

I decided that I hate the way idle2 is invoked at the moment. The code is clunky and it isn't ideal for hooking into various subsystems. I want to hook into the audio subsystem to only enable whilst audio is playing, TOP OFF if possible and TOP ON if not. I also need to hook into the bluetooth subsystem to disable TOP OFF whilst bluetooth is in use.

So, my plan at the moment is to implement all 3 idle states separately IDLE, DEEP-IDLE TOP ON & DEEP-IDLE TOP OFF and switch between them as necessary. I also plan to use a workqueue and delayed work to switch between the states.

That way, I can introduce a delay such as a 10 second delay after audio starts before idle2 is activated, and if it isn't, the workqueue will be flushed and the state won't be switched. This would stop it being activated when notifications play, for example.

Implementing the IDLE states separately will also have the advantage of keeping each idle code path optimised at the expense of duplicating some code, but I feel it is the best way forwards.

I've already started work on this, the idle state switching is already partially implemented and I haven't come across any unforeseen issues yet. Lol.
[Nexus S Android Development] Nexxusel:
I have a question. For the TOP OFF is enabled, MMC does not have to be in use, but the purpose of the TOP OFF is listening music and save battery, but if the songs are in the MMC does not work because you are using the MMC?

Am I wrong?

sorry for my English
[Nexus S Android Development] :
Audio is buffered when the CPU wakes up from sleep which happens as the CPU switches in and out of DEEP-IDLE many times per second due to being awoken by an interrupt. So no, you are not using the MMC all the time, only occasionally in a burst.
[Nexus S Android Development] Segner:
There are many people who don't use Bluetooth, and many others who could abandon Bluetooth temporarily. It would be great for the user to have a switch that, when switched on, triggers your type of deep idle with TOP=OFF. When switched off, it should go back to ezekeel's version (or an improved version of yours) with TOP=ON and thereby enable normal Bluetooth behavior. Is that possible?
[Nexus S Android Development] :
You must have missed my previous post here.

I'm not providing any switches. It adds additional unnecessary complication. If I can't implement it so it's transparent to the end user, the project will have failed as far as I am concerned.

I have a plan how to implement it, and I'm not even going to bother implementing TOP ON, because it saves no power what so ever, as has been discovered through testing. This defies logic and is unfortunate, but it proves that the normal IDLE is very efficient.
[Nexus S Android Development] :
So, I've finished the rewrite and I should be releasing it tomorrow, assuming no last minute issues. The text from the git commit is below:

v0.200 is a complete rewrite of the
majority of the idle2 codebase. 2 idle states have now been
fully implemented and are available at all times. The
states are IDLE and IDLE2, which is DEEP-IDLE TOP OFF.
DEEP-IDLE TOP ON is not implemented, as it has no benefit.

The hot code paths are now more optimised and faster.
Workqueues are used to inform idle2 of events from other subsystems,
such as audio, usb connected and bluetooth.
PM notifiers are used to notify idle2 of a suspend, although it should
never get into a situation where it is working at the same time as the
system is suspending.

The IDLE2 mode will only be activated when audio has been playing back
for more than 30 seconds, the device is not connected to USB, bluetooth is
not active (it can be enabled, but not be actively working) various clocks
are gated (in practice, this means that the screen has to be off), certain
subsystems are not active and there are no interrupts pending.

The early suspend and late resume hooks have been removed as they are not
required, as have the suspend and resume hooks.

Many of the idle2 specific functions have been split into idle2.h to keep
them separate from the stock code.

IDLE2 can be disabled with the following command:
echo 1 > /sys/module/cpuidle/parameters/idle2_disabled

Stats can be obtained from the standard cpuidle interface, which, for
IDLE2 is located at:
/sys/devices/system/cpu/cpu0/cpuidle/state1
[Nexus S Android Development] rasengan82:
Omg you are the best!
[Nexus S Android Development] :
New blog post about IDLE2 v0.201 here. I'll update the OP with the design changes later.

New kernel release with v0.201 for JB here and for ICS here.
[Nexus S Android Development] N@th_OC:
GREAT!!!

Thank you _thalamus, i almost eat my fingers waiting the JB update for your IDLE2 patch!

Thank you again, an amazing work, as usual... :good:
[Nexus S Android Development] :
Cheers.

Standalone patch is available here. It will apply to both ICS and JB kernels, although perhaps with some offsets on ICS, so best to use git am -3 so it can fall back to 3 way merge if needed. :)

To apply, do:

curl https://github.com/thalamus/android-kernel/commit/55ac0860cebac636159367d374cb9a7186874c06.patch | git am -3
[Nexus S Android Development] brenix:
Been testing v0.201 and seems to be working great.. Nice work