[MOD][KERNEL] Deep Idle

Search This thread

Ezekeel

Retired Recognized Developer
Jun 21, 2011
715
1,680
Updated the initial post with source code.


Awesome!!!
Ezekeel you are just our god in the Nexus S community!
I really want to do something to thank you.
As you said that you wouldn't accept donations, is there any other things I can do for you?

No... except of course you work for Google or Samsung and can get me a free Nexus Prime since otherwise I will not get one. My Nexus S is just about 4 month old and I cannot sell it, because then I would not be able to provide support/bugfixes for my tweaks anymore. And if I buy a second phone for this price my girlfriend would kill me. :D


I hope you have found an efficent and safe way to use it. This has already been done in SGS kernel long time ago, and has been removed.

Waiting your good news

Do you know, what the problem was? I only heard something about wakeup problems from sleep.
 

brenix

Senior Member
Mar 24, 2011
204
109
San Diego
Do you know, what the problem was? I only heard something about wakeup problems from sleep.

Hmm..I've just tried implementing this and have ran into this same issue..The phone boots and interacts fine until the screen turns off for a few seconds. When you try to turn it back on, it doesn't wake up...

Great work on this though.. Very exciting!
 

morfic

Inactive Recognized Developer
Aug 3, 2008
7,211
12,879
San Antonio
www.derkernel.com
It attempts to IDLE even under load.
It is apparent in just about everything, from scrolling in the launcher, opening apps to the obvious benchmarks.

EDIT: It seems to affect the GPU most. Running a benchmark, CPU scores are almost normal, but 3D ends up being 1/4th of before.
 
Last edited:

intheb0x

Senior Member
Dec 8, 2007
1,523
373
Racine WI
OnePlus 8
It attempts to IDLE even under load.
It is apparent in just about everything, from scrolling in the launcher, opening apps to the obvious benchmarks.

EDIT: It seems to affect the GPU most. Running a benchmark, CPU scores are almost normal, but 3D ends up being 1/4th of before.

even on this kernel of yours?

T144-NS-11102011 (1.44GHz with 240MHz bus/gpu)


are you saying its slow and sluggish?
 

morfic

Inactive Recognized Developer
Aug 3, 2008
7,211
12,879
San Antonio
www.derkernel.com
even on this kernel of yours?

T144-NS-11102011 (1.44GHz with 240MHz bus/gpu)


are you saying its slow and sluggish?

slow and sluggish is almost not strong enough a language to describe it, it certainly tries to idle the gpu when it should be using it.
the screen off animation is slow motion.
Testing it in TEUV right now, since there are a few differences in code i hoped it would be all my fault, no acts same AFTER the first time phone was slept with power button.
TEUV and T144 both felt ok after boot, until screen went off, going to see if i can collect something useful.
 

intheb0x

Senior Member
Dec 8, 2007
1,523
373
Racine WI
OnePlus 8
slow and sluggish is almost not strong enough a language to describe it, it certainly tries to idle the gpu when it should be using it.
the screen off animation is slow motion.
Testing it in TEUV right now, since there are a few differences in code i hoped it would be all my fault, no acts same AFTER the first time phone was slept with power button.
TEUV and T144 both felt ok after boot, until screen went off, going to see if i can collect something useful.

im currently running the TEUV version and wow it is sloww,
but i see why, i wonder if it can be tweaked some way, because the battery savings from this could be huge.

using your kernel for the first time today TEUV-NS-05102011 (0.88GHz with 220MHz bus/gpu,ExtraUnderVolted) i got a couple extra hours out of battery, it was great. im hoping once it :sets in: it will be even better, but ill continue to play.
if you need any more observations from me for this deep idle kernel, let me know, i may be switching back

my phone seems to be running hotter with this mod.
 
Last edited:

morfic

Inactive Recognized Developer
Aug 3, 2008
7,211
12,879
San Antonio
www.derkernel.com
im currently running the TEUV version and wow it is sloww,
but i see why, i wonder if it can be tweaked some way, because the battery savings from this could be huge.

using your kernel for the first time today TEUV-NS-05102011 (0.88GHz with 220MHz bus/gpu,ExtraUnderVolted) i got a couple extra hours out of battery, it was great. im hoping once it :sets in: it will be even better, but ill continue to play.
if you need any more observations from me for this deep idle kernel, let me know, i may be switching back

my phone seems to be running hotter with this mod.

i switched sim from g2x to NS, there is no data, correct.
wifi comes on normal and i can get online
airplane mode hangs, so no radio kickstart possible

logs tomorrow, i'm falling asleep over here
 

intheb0x

Senior Member
Dec 8, 2007
1,523
373
Racine WI
OnePlus 8
i switched sim from g2x to NS, there is no data, correct.
wifi comes on normal and i can get online
airplane mode hangs, so no radio kickstart possible

logs tomorrow, i'm falling asleep over here

so far everything is working normal here, wifi, and 3g..
will post more as i go along.
nexus s 4g with sprint here.
 
Last edited:

Ezekeel

Retired Recognized Developer
Jun 21, 2011
715
1,680
I am having no trouble with the mobile data connection. Also I have not experienced any change in the responsiveness of the UI. I use BFS, maybe that is the difference.
 

KalimochoAz

Retired Recognized Developer
Oct 9, 2007
1,110
1,648
Tarragona
@Ezekeel: very nice work!

@KalimochoAz: any chance to get a CM nightly with this build in?

I have tested this some time ago, and it was inestable. I hope Ezekeel implementation is stable so I can add it, as I have added some other of his codes.

Talking about who started this, I have no idea. I took some time ago from Samsung galaxy, but I really now this is not coded by them. I think is an internal implementation from Samsung, but I'm not at all sure.

What I have found in the past is that it has some problems on wake up, for example on some cases that you receive a call, it start to fail all the threads, but that was my code, that can be buggy. So lets Ezekeel work on this and meanwhile I will try to test his code and see if I can also help on it, if is needed

Kalim
 

FloHimself

Senior Member
May 27, 2010
558
218
I have tested this some time ago, and it was inestable. I hope Ezekeel implementation is stable so I can add it, as I have added some other of his codes.

I'd like to test the current implementation. Can you point me to the current kernel source of the CM nightlys (CM github isn't the latest?) and provide a current kernel config?
 

KalimochoAz

Retired Recognized Developer
Oct 9, 2007
1,110
1,648
Tarragona
Updated the initial post with source code.




No... except of course you work for Google or Samsung and can get me a free Nexus Prime since otherwise I will not get one. My Nexus S is just about 4 month old and I cannot sell it, because then I would not be able to provide support/bugfixes for my tweaks anymore. And if I buy a second phone for this price my girlfriend would kill me. :D




Do you know, what the problem was? I only heard something about wakeup problems from sleep.

No, I had a lot to do before release, so I have deprecated the code for the future. I have seen that at wake up, not with power turn on but with alarms, calls... sometimes system hangs. Since I nedded more loggin in kernel to check what happends.

Now I will habe more time to check it again, so I will try to keep you informed of what I see. I agree this trick saves a lot of battery.
 
  • Like
Reactions: Romonster

KalimochoAz

Retired Recognized Developer
Oct 9, 2007
1,110
1,648
Tarragona
I'd like to test the current implementation. Can you point me to the current kernel source of the CM nightlys (CM github isn't the latest?) and provide a current kernel config?

No, is not updated. I'm finishing some cleaning at the code and I will merge all during this week. On the other hand if you want to test it

http://bit.ly/DeepIdleV2_4 ( CM Kernel with Ezekeel modif. )
http://bit.ly/Release71 ( CM kernel from Release 7.1 )

but this is just for test, is not official at all. ( in my phone this implementation and my own implementation of this trick is BUGGY )

All you test it, feel free to post here logs in order to help on:

adb shell logcat
adb shell klogtail

Kalim
 
Last edited:

FloHimself

Senior Member
May 27, 2010
558
218
Sure it would be nice to compile this from source, but for testing the binary blob is really enough. Thank you!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 128
    I recently had a discussion with someone regarding the benefits of screen-off profiles/daemons that put a limit on the CPU frequency while the screen is switched off for the sake of reducing the power consumption and thus prolonging the battery runtime. My argument was that putting a hard limit on the CPU frequency would rather have a detrimental effect of the battery runtime since this would hinder the CPU from racing-to-idle. I also argued that due to this race-to-idle effect, in general restricting the CPU frequency is not beneficial to the battery runtime and in contrast to intuition overclocking should reduce the average battery drain (as long as no disproportionate increase in voltage is necessary).

    Since this is just theory and Morfic noted that his experience seems to indicate otherwise and that limiting the CPU frequency does actually decrease the battery drain, I put this theory to the test and logged the battery charge over 10h of FLAC playback in Airplane mode with the screen switched off.
    idled.jpg

    As one can see, limiting the frequency to a maximum of 880MHz does indeed reduce the power consumption.

    Thus it seems that race-to-idle does not properly work on this device. But why? The answer is that, while the technical manual showed that the hardware supports six different power states: NORMAL, IDLE, DEEP-IDLE, STOP, DEEP-STOP and SLEEP, a quick look into the source code revealed that (besides SLEEP) only the most rudimentary power saving state IDLE is actually implemented in the kernel. And for this IDLE state no parts of the hardware are powered down; the only thing that essentially happens is that the CPU clock is set to zero.

    For the real power savings to kick in, one would have to power down parts of the hardware (at least the CPU) and that is exactly what the DEEP-IDLE state is supposed to do. Unfortunately this was not implemented. So, following the technical manual I tried to implement this DEEP-IDLE state on my own... and failed miserably. Well, not that miserably... at least I had an idea where the problem was. However I had no idea how to fix it since I did not know enough about the hardware details, had no experience working that close to the CPU and also the manual was far from instructive.

    So I googled to maybe find someone smarter than me who had figured out a solution and found out that "some guys" already tried to implement this DEEP-IDLE state for the Galaxy S, however that did not work for some reason. I located the source code in some older version of sixstringsg's Glitch kernel, made some modification, put it into my reference kernel and everything is running fine for more than two days now.

    I have repeated the above test runs on a kernel including the deep-idle state.
    deepidle.jpg

    The battery drain is reduced to 17-18% compared to the 41%/46% (880MHz/1320MHz) obtained without deep-idle support. Thus the battery consumption is reduced by more than 55%. Also we see that with the kernel including deep-idle both 880MHz and 1320MHz yield almost the same average battery drain, showing that race-to-idle actually does work as long as the power saving features are properly supported. So, once these modifications are implemented in your favorite kernel, there should be no need for limiting the frequency anymore and you should be able to blast away without wasting a thought about the battery drain. Also, there is no reason anymore not to overclock your device, except of course the thermal limit of the device auto-incinerating in your hand.


    Changes to the source code: http://www.pastie.org/2679956


    BUGFIX:

    1. While the screen is on, only the normal IDLE state is used.
    2. Removed DEEP IDLE state with TOP=ON.
    3. For the DEEP IDLE state with TOP=OFF, all external interrupt
    wakeup sources except XEINT[30] (key input) are disabled and
    all internal wakeup sources are disabled.

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


    BUGFIX #2:

    1. The reserved values of S5P_WAKEUP_MASK are not touched.
    2. Only XEINT[22] = GPH2[6] = GPIO_nPOWER = GPIO_N_POWER and
    and XEINT[29] = GPH3[5] = GPIO_OK_KEY are enabled as external
    wakeup sources.
    3. Only RTC TICK and I2S are enabled as wakeup sources.

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


    BUGFIX #3:

    For DEEP IDLE the same wakeup interrupt sources are used as for the
    sleep state plus at least XEINT[22] = GPH2[6] = GPIO_nPOWER =
    GPIO_N_POWER, XEINT[29] = GPH3[5] = GPIO_OK_KEY, RTC TICK and I2S.

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


    BUGFIX #4:

    Implemented a sysfs interface (/sys/class/misc/deepidle) for enabling/disabling the use of the DEEP IDLE state.

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


    BUGFIX #5:

    Fixed the BT problem and made sure the DEEP IDLE state is not used when the device is going to/waking from suspend (SLEEP).

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


    BUGFIX #6:

    1. Mimicking the procedure for the SLEEP state, when entering/returning
    from the DEEP IDLE state, a notification is send to kernel modules
    using 'pm_notifier_call_chain'. This will cause CPUfreq to statically
    set the frequency to SLEEP_FREQ and prevent further frequency changes
    until the system returns from DEEP IDLE.
    2. The APLL lock is not modified.

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


    BUGFIX #7:

    Fixed GPS problems.

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


    BUGFIX #8:

    The DEEP IDLE with TOP=ON is used while GPS or BT are running.

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


    BUGFIX #9:
    Notifications using 'pm_notifier_call_chain' when entering/leaving DEEP IDLE have been removed.

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

    Test kernel: http://www.multiupload.com/K8ZXS5HTLS
    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


    BUGFIX #10:

    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


    BUGFIX #11:

    Notifications using 'pm_notifier_call_chain' when entering/leaving DEEP IDLE have been removed.

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


    BUGFIX #12:

    Removed RTC TICK as wakeup source and added RTC ALARM.

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


    BUGFIX #13:

    Added ST as wakeup source.

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


    BUGFIX #14:

    Added KEY as wakeup source.

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


    No further patches will be published here. I have set up a git repo for all my tweaks. Each mod has its own branch to keep the tweaks cleanly separated and one can simply pull the latest patches from the corresponding branch.

    https://github.com/Ezekeel/GLaDOS-nexus-s/tree/deepidle



    As I said above, this code is almost entirely written by "some other guys". I just made some improvements and extensions to it. Unfortunately I have no idea who these great people are, so I cannot give any credit (yet). However I asked sixstringsg and he told me he would ask around.


    CAM bug

    There is a bug in the Google Talk app with video-chat which causes the CAM submodule to be activated on boot. As a consequence the DEEP IDLE state will not be used. Opening the camera app once and then closing it, shuts down the CAM module so after that the DEEP IDLE state will be used properly. The Talk version without video-chat does not have this issue. Unfortunately both version are shown as Version 1.3 in the application info, however the app size differs (740KB with video-chat, 500KB without video-chat) as well as the permissions (with video-chat additionally has the permission 'Hardware controls').

    without video-chat:
    screenshot1320779961364.jpg
    screenshot1320779976559.jpg



    with video-chat:
    talk21.jpg
    talk22.jpg



    A big thank you to FloHimself for tracking down the problem!
    5
    Could someone please tell me how to check whether the "Deep Idle" is enabled in a kernel or not ? If it is disabled by default, Please guide me with the method & app to be used to enable it.. Thanks in advance.. !

    use cat command from the terminal like this->

    cat /sys/class/misc/deepidle/enabled

    if shows 0 than its off , if shows 1 its on
    if you want to turn it on/(off) do this command
    //*****************************************
    // this how to turn this ON
    echo 1 > /sys/class/misc/deepidle/enabled
    //*****************************************
    //this is how to turn it OFF
    echo 0 > /sys/class/misc/deepidle/enabled
    dont you all worry i will write a script to help all you guys who dont know linux/unix commands...
    today it will be out i will post a thread...
    4
    I updated to CM7.1 and Netarchy 2.3.5 and after a lot of testing found the problem.

    Notifications using 'pm_notifier_call_chain' when entering/leaving DEEP IDLE have been removed.

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

    Test kernel: http://www.multiupload.com/K8ZXS5HTLS
    4
    Fixed the BT problem and made sure the DEEP IDLE state is not used when the device is going to/waking from suspend (SLEEP).

    Bugfix: http://www.pastie.org/2723702
    4
    I'd like to test the current implementation. Can you point me to the current kernel source of the CM nightlys (CM github isn't the latest?) and provide a current kernel config?

    No, is not updated. I'm finishing some cleaning at the code and I will merge all during this week. On the other hand if you want to test it

    http://bit.ly/DeepIdleV2_4 ( CM Kernel with Ezekeel modif. )
    http://bit.ly/Release71 ( CM kernel from Release 7.1 )

    but this is just for test, is not official at all. ( in my phone this implementation and my own implementation of this trick is BUGGY )

    All you test it, feel free to post here logs in order to help on:

    adb shell logcat
    adb shell klogtail

    Kalim