yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] brenix:
So far, things are working great. Below is some usage stats (only 20 mins or so) for analyzing if needed..

One thing I noticed was at first when the screen went off during music playing/bluetooth, it cut out the bluetooth connection. After re-enabling CONFIG_DEBUG_FS and running music/bluetooth again it was working fine. Not sure why it didn't work with debug filesystem disabled.. I might test again and report back if I get time, but I certainly wouldn't count it as an issue..

ROM: SlimJB v2.1

Kernel: 3.0.31 - By me

---------------IDLE2 v0.350 State Statistics--------------

C2 (TOP ON) C3 (TOP OFF)
----------------------------------------------------------
CPUidle requested state: 1635 105
State entered: 199 17
State completed: 199 17
State not completed: 0 0

Requested & completed: 12% 16%
Entered & completed: 100% 100%
Failed: 0% 0%

-----------------IDLE2 Failure Statistics-----------------
RTC MMC VIC I2S NAND Gate C3Gate DMA
----------------------------------------------------------
947 87 432 0 0 58 0 0

---------------------C1 Fallback Usage--------------------
State Entered: 1524

Fallback to C1 (Total): 87%

----------------IDLE2 Residency Statistics----------------
C1 (Fallback) C2 (TOP ON) C3 (TOP OFF)
----------------------------------------------------------
Total (us): 81868 14642266 951733
Average (us): 53 73579 55984
----------------------------------------------------------
[Nexus S Android Development] :
I picked those values because the last time I added idle2 (v0.213) those were the values that produced a result in /sys/devices/system/cpu/cpu0/cpuidle/state2/usage

Can i safely ignore this and defer to the error_stats instead?
[Nexus S Android Development] :
The vast majority of the code has changed. There is no need to change anything.

error_stats are correct, it takes them from the end of the idle state, even before the cpuidle subsystem is notified.
[Nexus S Android Development] :
I'll add it as an issue to look into. I'm not sure either, but then I haven't tested with CONFIG_DEBUG_FS not set because it's not a usual configuration.
[Nexus S Android Development] :
Ammeter readings @5V:

music on screen off

IDLE2 on

lows of 11dBu - 11.2dBu

IDLE2 off

lows of 11.6 - 11.8dBu

There's a small but measurable power saving even on my crappy old ammeter, for music at least.

According to the measurements I made of Ezekeel's Deep Idle, a bigger difference should be possible.

https://docs.google.com/spreadsheet/ccc?key=0AntDDKv-lS6IdEY4T3dXWVFDWk9lREdJNGFfU2NwRlE

I used the same equipment to measure but this time at 5V instead of 4V.
[Nexus S Android Development] :
Just as a matter of interest, change the latency of C1 to 1 and the residency to 10000 (which are the stock values). Then re-compare with idle2 disabled.

I expect that will increase the non idle2 current reading substantially.

And also, wfi (C1) wasn't correctly implemented in deep-idle and it would have made it much more expensive when you used the disable switch, hence the large difference.

You are comparing apples and oranges by trying to compare my implementation with didle.
[Nexus S Android Development] :
Okay, I tried it, but unfortunately on my kernel the current drawn is the same. C2 stats show 91% requested and completed success rate. (TOP=ON right?)
[Nexus S Android Development] :
Read my post again, you didn't do what I said.

What I want you to do is set the values of C1 (wfi) to stock values which are exit_latency 1 and target_residency 10000.

I then want you to build with idle2 disabled and test the current draw to get a baseline. Then you can compare against that. Other comparisons are pointless.

C2 is TOP block on, I'm more interested in C3 (TOP block off) savings, but if C2 is saving power, even better. :D
[Nexus S Android Development] :
Okay, I re-read it. But it still says:

When you said re-compare, did you mean re-compile?

I thought you meant compare using the sys switch:

echo 1 > /sys/module/cpuidle/parameters/idle2_disabled

So you want one built with:

device->states[0].exit_latency = 1;	/* uS */

device->states[0].target_residency = 10000;

...and S5P_IDLE2 disabled

vs one with the nominal IDLE2 values and S5P_IDLE2 enabled

...and you want to see the difference in the drain when the screen is on, but nothing is happening?
[Nexus S Android Development] :
What switch? I removed it. If you still have the switch, you have an old version.

No. I want to see the drain whilst it it unplugged, the screen is off and music is playing back...why on earth would you want to compare 2 completely different things? With all due respect, what the **** is the point of that?

Seriously, it's not complex. I don't talk in greek. Why is this so difficult? If you are trying to piss me off, it's working.
[Nexus S Android Development] :
Sorry. I'm trying to help, but I obviously misinterpreted what you wanted. It's not obvious to me at all. But I can see what you're saying now. I'm doing my best with what tools and skills I have.

Anyway, I now have a non-IDLE2 build with the values you asked for.

The measurement with screen off and music on is between 11.8dBu and 12.5dBu (flucuates)
[Nexus S Android Development] kwibis:
LoL :good: Wonder how you'll treat your children xD
[Nexus S Android Development] :
Tbh, I get more frustrated at people who should know better asking moronic questions than noobs asking moronic questions. Use some initiative!

Specially when I end up being late for work because I'm answering dumb questions.

Anyway, it was out of order on my part and I apologise for it.

As for children, I won't be having any, so that will not be an issue.
[Nexus S Android Development] polobunny:
Have them fried with a bit of hot sauce, they're delicious.

Were you able to find someone who could help you with the ASM part of things?
[Nexus S Android Development] :
What I would be interested in is if you were to swap the C1 enter command with the C2/C3 enter command. This would make it slightly more comparable with deep idle.

What I mean is swap s5p_enter_idle_normal for s5p_enter_ idle_deep. That will make normal idle much more expensive and emulate how deep idle works. Also, crank up the residences of C2 and 3 so they aren't used so its a fair test of C1. A value of 99999999 should do the job.
[Nexus S Android Development] :
If you're still interested in me doing some amps measurements, maybe the best thing is for you to make the builds you want testing. You can label them A B C D ... so it's a blind test.
[Nexus S Android Development] :
I'm in the middle of a massive code refactor at the moment. I've moved all of idle2.h and 90% of the code in cpuidle.c into idle2.c, moved the extern calls from cpuidle.h to idle2.h and deleted cpuidle.h. And guess what, it all still works. :)

It won't affect performance though, because I haven't changed anything other than the location of the code.

Also added a function to clamp the cpu frequency at 400MHz when the screen is off and audio is active, should save a few kinteractive_up cycles.

I'll push the code now before I goto work, bug reports are welcome.
[Nexus S Android Development] :
Latest idle2 v0.360 here.
[Nexus S Android Development] :
I was excited to try this out. The needle is at about 10.6dBu, which at 5V translates to 2.3mA. Yesterday's low was 2.5mA (but this was at 100MHz of course). There is now also significantly less needle-bouncing. It's now much easier to get an eye on the central tendency of the needle.

I think with a 100mV INT UV* this reading would be down about 1mA to 1.3mA, which is roughly equivalent to the old readings I got with the apples (or oranges... which was which?)

I was so excited I made a little video! :victory:

http://youtu.be/gPuXpfZ-uzc

*I do not approve of UV, I'm just contextualising my original test
[Nexus S Android Development] :
Nice. You could try some different MHz values if you like to see if it makes. It's defined in idle2.c near the top.
[Nexus S Android Development] brenix:
This resolved the bluetooth/music issue I had... thanks!
[Nexus S Android Development] :
IMPORTANT

For anyone testing the latest version, there is an issue caused by a bug in the bcmdhd wireless driver.

To get the best possible residencies, wifi *must* be toggled off then on, or on then off after booting.

Unfortunately, I can't find a way around this at the moment. It seems when the wifi card is initialised, it isn't resetting something correctly, which is causing additional RTC_TICK wakeups until the wifi has been power cycled. Entering suspend then resuming does not resolve the issue either. It also occurs whether wifi is enabled or disabled, that makes no difference.

The bcmdhd code is an utter minefield, and although I did try to attempt to fix it, I didn't manage to.

I may add a function to toggle the wifi state during early boot, if I can figure out how to do it, but thats low on the priority list at the moment.
[Nexus S Android Development] :
Yay, bugfixing. :)

Alas not the wifi bug. :(

I have however fixed an issue which caused the modem to die occasionally, then die again and fail to recover. We need to wake from its IRQ and we weren't, so we now do.

I also enabled most of the other external interrupt wakeup sources, to avoid any more issues with devices going out to lunch.

I think I'm at the ultimate upper limit for residency too, I don't think there is much chance of getting much more than 10ms on average, due to the number of wakeups.

Will push some more code inabit.
[Nexus S Android Development] polobunny:
Although not a very clean way of doing things, wouldn't it be possible to switch wifi state using a simple init.d script?

Something such as "svc wifi enable/disable" to switch the wifi manager state would probably be enough. Can't test at the moment though.
[Nexus S Android Development] :
Indeed. But thats not the kind of thing I would implement, because it's nasty and dirty and has a lot in common with a public toilet.

If someone can find the functions that the android wifi service uses to switch the wifi state in the kernel, then I'll implement a hack to toggle on and off in idle2 which will resolve the issue. I think it uses the common 802.11 code.

I *really* don't have time to do that at the moment though, so if someone could investigate, find how it works and let me know the enable and disable calls I need, I would appreciate it a lot.

A patch fixing the issue using delayed work (it'll probably be a sleeping function, so won't be able to be called from an atomic context) would be even better, but the enable and disable calls will do. :)
[Nexus S Android Development] polobunny:
Agreed on everything. But without that kind of knowledge and/or until someone else looks at it, that should work as a temporary automated fix. I am lazy. :)
[Nexus S Android Development] :
Well, strangely enough, it has stopped happening here now. But I haven't changed anything which might stop it happening...

But yes, I would very much prefer if someone else found the required functions. I *really* can't be arsed because it's not a bug with idle2 and it has already given me a headache today.

Edit: Lol, spoke too soon...it's still doing it.
[Nexus S Android Development] :
v0.370 pushed: https://github.com/thalamus/android-kernel/commit/474cdb2be8eee3fe1274ac4d5397bf792ca37b19
[Nexus S Android Development] madd0g:
Are those wakeups the same cause perhaps for those alarms for .TIME_TICK intent ? https://dl.dropbox.com/u/12542/Screenshot_2012-08-31-00-33-18.png
[Nexus S Android Development] :
No idea but I'm guessing probably not...
[Nexus S Android Development] q659503934:
i want to add deep idle into a galasxy s kernel is there a fully path？
[Nexus S Android Development] DerTeufel1980:
Not now, as you can see at github
[Nexus S Android Development] :
Ok, so, it seems I introduced a bug which completely broke suspend on v0.370.

The good news is I figured it out quickly and have fixed it. Fix is here.

The other good news is I noticed my device only losing 1.5% an hour in top block off mode whilst it was chugging away overnight with broken suspend.

That is *really* impressive and shows that IDLE2 is saving a ton of power because it's not using much more than suspend does.

Without all the expensive stat collection, I expect it would save even more and use a lot less CPU cycles.

If anyone wants to try a prebuilt kernel from the tip of the IDLE2-v3.xx-wip branch, here is one. Any comments about that prebuilt kernel please take to here.
[Nexus S Android Development] donbudafuko:
Share is the download at if looked all over an can't find it....im running the Fri Aug 10 version on my nexus s4g an it running great
[Nexus S Android Development] :
What? Can you kindly say that again in English? I have no idea what you are talking about. It's just a string of words randomly stuck together and it means utterly nothing to me.

And did you miss this from the OP?

No n00bs and no moronic questions please, think before post.
[Nexus S Android Development] DerTeufel1980:
Finally found the time to make some testing on sgs1.

Looking good so far. No issues till now. Will report again after weekend.

One question: you have removed the switch for disabling, which would be the part of the code to readd it. I am needing it, because I am compiling my kernel for multiple different (but similar devices), and some of them always crash with idle2 (they did with your older releaes as well as with deepidle).
[Nexus S Android Development] :
I'll work up a quick patch for you to re add it.
[Nexus S Android Development] didhiy:
Can this great stuffs may come to sph-d700 epic4g too? :fingercross
[Nexus S Android Development] :
For v0.370, seeing as all the AUDIO_ACTIVE stuff is commented out, I was expecting no C3 state for audio. However, I saw C3 accumulating, so I got the ammeter out. It's down at around 10.6dBu (5V) again, at 800MHz while audio is playing.

I confirmed that the wifi on/off toggle step is necessary too (although I suspect confirmation is the last thing you needed after posting a big bold warning about it), before this step the needle is stuck at 15dBu.
[Nexus S Android Development] :
I killed all the AUDIO_ACTIVE stuff because I wanted C2/C3 at any time during screen off.

I wonder if we should try 400MHz / 600MHz and maybe have a play with the residencies too?
[Nexus S Android Development] :
How you prepare a set of zImages again? Or is there any hope of a temporary /sys interface for residencies? I've got a good few hours on Tuesday morning where I could run a batch of tests.
[Nexus S Android Development] :
I'm not really wanting a load of stuff tested.

I'm interested in 8000, 10000 & 12000 residencies, MHz can wait, I honestly don't think it'll make much difference anyway, because the CPU is only clocked at that speed when it is awoken. In theory, 1000 MHz should provide the most powersaving, as it will allow it to race back to the idle state quicker.

/sys interface for residencies would be an arse to implement. I'm not even sure they are changeable on the fly.
[Nexus S Android Development] :
commit 840d3afc0179203f9cb2fd53f0d944df311a721d
Author: Will Tisdale <willtisdale@gmail.com>
Date: Mon Sep 3 01:03:00 2012 +0100

idle2: v0.380
Post 0.370 suspend bugfix (revert that before applying this)
Exit latencies back to measured values
Statistics slimmed down significantly
Disable switch added for DerTeufel1980
Couple of tests removed which were never true or which made the state
bail for no reason.
Variable renames for consistency.
Use L2 cache OFF for C2 and C3 state. Resolves external abort issue and
should save more juice. As we were flushing it fully anyway, it makes
sense to turn it off to save power. It seems that the retention doesn't
work particularly well and the L2 goes corrupt.
Use TOP memory retention for C2, should save a bit more juice.
Adjust wakeup sources.
Refactor s5p_enter_idle_deep() to remove goto jumps.
Use disable_hlt() when PM_SUSPEND_PREPARE is notified.
Code cleanups of unused stuff.

arch/arm/mach-s5pv210/cpufreq.c | 9 +-
arch/arm/mach-s5pv210/cpuidle.c | 4 +-
arch/arm/mach-s5pv210/idle2.c | 419 +++++++++++++---------------
arch/arm/mach-s5pv210/idle2_stats.c | 56 +---
arch/arm/mach-s5pv210/include/mach/idle2.h | 2 +-
arch/arm/mach-s5pv210/sleep.S | 22 --
drivers/acpi/processor_idle.c | 1 -
include/linux/cpuidle.h | 1 -
sound/soc/samsung/s5pc1xx-i2s.c | 11 -
9 files changed, 209 insertions(+), 316 deletions(-)

Just pushed here.

You will need to revert the suspend bugfix patch, as I squashed it into v0.380.
[Nexus S Android Development] DerTeufel1980:
What is the reason for removing the idle freq code from cpufreq.c?

Idle2 seemed to be working well during weekend, but I am not sure, (at least for me) if there is a negative side effect, cause I am having some liveoc related code in this function.

Could I just remove the ifndef around the function, for testing? Or would this break idle2?
[Nexus S Android Development] :
Show me what code you are adding and I will take a look. It's only the suspend notifier code which is ifndeffed out. That shouldn't affect anything else.

Edit: I just had a look at the code. You could work around that easily enough.

Just declare pllbus_changing and sleep_freq as externs in idle2.c and do it in the notifier in there instead. Problem solved.
[Nexus S Android Development] DerTeufel1980:
great. thanks. i just wanted to post my code ;)

Edit: just for testing, it should work, to comment out the two functions for locking and unlocking the freq in idle2.c? And use the code for idle freq from cpufreq.c again.

I would love to see, if there is a noticeable difference between locking the cpu and letting it scale.

(i know locking is better, but I also know users are going to complain about the usage of 800 MHz, because they won't understand ;))
[Nexus S Android Development] :
I got around to this today:

8000 11.6 dBu (was higher so went the other way)

5000 10.6 dBu, C3 avg. stat was 10000µs.

4000 10.6 dBu, C3 avg. decreased to 9800µs.

3000 10.6 dBu, C3 avg. decreased again to 9400µs.

2000 10.6 dBu, C3 avg. decreased to 9000µs.

After this I wondered if I got the first measurement right, so went back to 8000 to double check, but it was 11.6dBu again.
[Nexus S Android Development] :
Makes sense. Was that with music playing?
[Nexus S Android Development] :
Well. It's not ideal. Scaling will introduce more work at a time when you want the system to be idle.
[Nexus S Android Development] :
Yes, same track as before. Thought bitrate might have some impact, so I'm sticking with the same mp3.
[Nexus 7 Q&A, Help & Troubleshooting] Scythe024:
I accidently clicked "always" use chrome to open this link, how do I reset it? Using it on Reddit is fun and wanted YouTube app to open it not browser
[Nexus 7 Q&A, Help & Troubleshooting] msavic6:
Here's what you do:

Settings>Apps> All Apps>Find Chrome and click on it> Scroll Down and Click *Clear Defaults*

You should be good to go now.
[Nexus 7 Q&A, Help & Troubleshooting] gtalum:
Manage Apps -> Chrome -> Clear defaults
[Nexus 7 Q&A, Help & Troubleshooting] Scythe024:
Thanks guys , I did it for Reddit is fun, but guess I chose the wrong one to do it to
[XPERIA X8 Q&A, Help & Troubleshooting] nandroidz:
Is there a Xperia lock screen that works on minicm9 :D:D:D:D
[XPERIA X8 Q&A, Help & Troubleshooting] TheArberator:
At the moment there is no Xperia Lockscreen for minicm9 but maybe Xmaster8 will port it soon.;)
[XPERIA X8 Q&A, Help & Troubleshooting] Chris95X8:
Not unless CM9 has Slide style lockscreen.
[XPERIA X8 Q&A, Help & Troubleshooting] Jeik:
IScreamdx has slide style!!so in will work on isdx for now.
[Galaxy S II Q&A, Help & Troubleshooting] tlf55:
Hi, i'm using LP4 with Siyah kernel right now, i was wondering how much is the average screen time with stock battery ?

Only for sms, no data, no wifi, no game or other app ..

Mine is around 4h30 from 100% to 15% of battery .. I m asking to myself if i change kernel or tweak a bit this one could i have more ?

Thanks
[Galaxy S II Q&A, Help & Troubleshooting] saobang3886:
4h30 is screen on time? I use 4.0.4 LPM, stock kernel and have 2 day use normal with ~4h screen on :)
[Galaxy S II Q&A, Help & Troubleshooting] tlf55:
Yeah i'm not talking about use time.. Just Screen Time ..

Because i'm fully using my phone so i can stand only one day barely but my screen time is about 4h30 when it has 15% battery remaining
[Sprint HTC EVO 4G LTE] simpat1zq:
I've never seen the price this low for an SDXC. It's on Amazon for $60. Will this SDXC card work with the EVO 4G LTE?
[Sprint HTC EVO 4G LTE] eyeisdasteve:
Its $98, but yes.
[Sprint HTC EVO 4G LTE] DioTGT:
It actually is 59.95...but it ships from 1 to 2 months. So its going to take a while.
[Sprint HTC EVO 4G LTE] pre2epic4g:
Is this a class 10 card?
[Sprint HTC EVO 4G LTE] kaos420:
I got mine off ebay class 10 64 bucks

Sent from my ice cream powered Evo Lte!
[Nexus 7 Accessories] duglas:
So I saw the post about the Blurex coming out with a Nexus 7 case so I thought I would try it in my HTC Flyer case I had laying around.. The Nexus fit into the case perfectly and it holds it nicely, but I did not have access to the 2 buttons on the side.. I cut the side of the case with the only thing I could find handy (wire strippers) and hacked it up but I made it so I could use the buttons and have a nice functional case now. The case is only $19.99 on Amazon shipped because the Flyer is out of production and might not be worth it to some but will work fine because I had it laying around..

The cuts look awful but can be cleaned up and made to look almost perfect with 5 minutes of work..

Here is a link to the case.. I know if the Nexus 7 Blurex comes out soon and costs the same then this is a stupid option, but if the Nexus 7 Blurex case ends up being $29.99 or more than I think the $20 one is worth it..

http://www.amazon.com/dp/B005AZEFPG/ref=pe_175190_21431760_cs_sce_dp_1
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] sayhellotwoheaven:
Hi guys.

I looking for a protection for my lww, but i doesn't know what to chosse... Between Silicone and TPU, What do you recommend me for lww?
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] Someguyfromhell:
Personal opinion - None.

Those cases ruin the design of the phone, it doesn't look so nice with a case.

It is better to take care of your phone, I've had mine since October and only once it fell and then were luckily no damages.
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] krlwarrior:
I agree with you, I just use an old sock to protect my phone, i keep it safe and clean :P
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] MSTHETERROR:
Use the white coloured Green Heart pouch that comes with it :p
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] sayhellotwoheaven:
LOL but i haven't now lmao :(
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] mskyaxl:
silicon, definitely!

I have one for my LWW, maybe the phone is ugly with it but it's safe and clean.
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] dexter1123:
I would also recommend Silicon...I am using white color. It will protect your phone's body from scratched & damage...

I started using it after 8 months of purchasing LWW and by that time the finishing stuff started coming out from all 4 corners and Sony service center told this is normal wear and tear therefore not covered in warranty (see how bad the quality is)...so just go for silicon case asap, it wont damage ur phone
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] nussbaum:
I also prefer _real_ silicone cover over TPU because it is more sticky in the hand and softer when hitting the ground...:)

Xperia mini (smultron), CM10 150, Xtended kernel + rom
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] Ecou81:
Silicone definetly!

It absorbs shocks better!
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] benjpopfilter:
try looking for WELLMAX MAGIC ICE CREAM CASE! :)
[Sony Ericsson Xperia Mini, Mini Pro, Xperia Pro, A] #{Script-Kiddie}:
I saw a YT-Video about this case... it isn't magic.

No rainbows, no tesla-blasters, no self-destruction...

Just a case! :eek:

I order a TPU-Case, because it look's nice.

Bad english, FTW! :crying: