[Galaxy S III Original Android Development] mamba720027:
I was wondering what it is too so did some googleing and found this post by "Entropy512" in reply to another xda member explaining of the various state.so taught it might clear up some questions.

"4th March 2012, 04:49 PM

Entropy512

Elite Recognized Developer Join Date: Aug 2007

Location: Owego, NY

Posts: 9,879

Quote:eek:riginally Posted by gingingingin

0: IDLE - CPU not clocked

1: AFTR - something not totally clear to me, but an alternative way to IDLE the CPU - ARM Off Top Running with L2 cache keeping its state

2: IDLE+LPA - IDLE + DEEP IDLE - also some parts of hardware are powered down

3: AFTR+LPA - AFTR + DEEP IDLE

These are not deep sleep states. Deep sleep is also known as "suspend" - where almost the entire system is shut down.

These are CPU idle states, which allow the core to save power even when the system is "running". They take significantly less time and energy to enter, but save less power. Also, there are only three of them - IDLE, LPA, AFTR. See arch/arm/mach-s5pv310/cpuidle.c in the kernel source for more details.

As an example, with kernels that have the cpuidle backport from the Tab 7 Plus:

IDLE is entered if the CPU is expected to be free for 4 msec (40 msec stock)

AFTR is entered if the CPU is expected to be free for 10 msec (disabled stock)

LPA is entered if the CPU is expected to be free for 40 msec (40 msec stock)

There are some rules that can cause lower states to be entered even if the cpuidle governor chooses LPA or AFTR. (cpuidle governor has nothing to do with cpufreq governor).

Your descriptions of the states are pretty close to what I understand them to be:

IDLE - clock is gated but power remains (does not eliminate any static power consumption)

AFTR - clock is gated, CPU core power removed, cache power remains - this eliminates a great deal of static power consumption - cannot be entered if second core is active

LPA - AFTR + removal of cache power - cannot be entered if second core is active

The above are why 100 MHz is pointless on our device, and in my experience, actually can increase power usage. The achievable voltage difference between 100 MHz and 200 MHz is insignificant for most peope, and if the voltages for two frequencies are the same, it's better to run at the higher frequency and drop into AFTR/LPA to shut off core power more often. The PDF linked from Ezekeel's post at http://xdaforums.com/show...4#post21785924 is a useful read on this topic, especially section 6. While it's fairly old, most of the concepts remain valid. For this reason, 500 MHz also doesn't consume much more power than 200 for a given fixed amount of load due to having the same voltage stock as 200 (however, it does increase some internal clocks I believe, leading to slightly increased power) - so when the screen is on I have it set to 500 MHz minimum.

This compares to suspend, aka deep sleep, which takes around 150 msec to enter and 650 msec to resume, and the CPU must be at 800 MHz (or at least have enough voltage to support 800 MHz operation) during this time. Entering suspend/resume is very costly in terms of power due to heavy interrupt load, which is involved in 90% of complaints about high "Android OS" battery usage on Gingerbread. However I believe from some of the testing I've run that improved cpuidle greatly reduces this penalty.

With the improved cpuidle patch, even when I use the Wake Lock app to hold a permanent wakelock for testing purposes, my standby drain is only 1.5%/hour or so. When not holding a wakelock, 0.5%/hour on wifi is easily achievable. It gets much worse at my desk at work, where the signal is weak and the cell radio eats huge amounts of power - there it's around 1%/hour.

Edit: As to task killers - all of the people saying "task killers are worthless" talk about memory management only. The fact is, unfortunately, that there are some crappy apps out there that use too much CPU or hold insanely long wakelocks that you just have to use occasionally. Facebook is still the #1 example here - Facebook is a major battery hog, therefore when you're done with it, you must kill it with fire. However, NEVER use an autokiller and never use it for memory management!"

Sent from my GT-I9300