Marco Chen <[email protected]> writes:
> Hi Kan-Ru,
>
>>> 1. Changing PowerManager.screenEnabled is THE ONLY WAY to trigger the
>>> suspend.
>> This is not true. The android kernel could call suspend at anytime when
>> the wake lock count in kernel hits zero. When design power management
>> API we must remember that the user space has to cooperate with the
>> kernel. Wake up events could come from device drivers or user space.
>
> Basically it is true of system will go into real suspend state when wake lock
> count is 0.
> But please refer to the link as below
>
> http://code.google.com/p/bricked/source/browse/kernel/power/earlysuspend.c?repo=tenderloin&name=2a47e396d5&r=2a47e396d569c069bf7023202e336ec19bbf615c#168
>
> When Gecko set "/sys/power/state" to "on", there is a wakelock created by
> kernel - main_wake_lock.
> So there is no chance of wakelock count is 0 until
>
> PowerManager.screenEnabled = false -> Gecko set "/sys/power/state" to "mem"
> -> check wakelock is 0 or not.
If the phone wakes up without set /sys/power/state to "on" then the last
wake lock will determine when to trigger suspend. For example when we
use adb to debug, the "usb_bus_active" wake lock keeps the phone awake.
Tips: Use `adb shell cat /proc/wakelocks|column -t` to see which wake
locks are active.
> If the statement as below is still true then we don't need
> PowerManager.cpuSleepAllowed and just handled by system app itself.
>
> "1. Changing PowerManager.screenEnabled is THE ONLY WAY to trigger the
> suspend."
>
>> Please define powerLevel. Currently the Resource Lock API
>
> Honestly to say, I have no strong reason to change this.
> But just focus on rename the PowerManager.screenEnabled and split it to two
> functions - Suspend & Screen.
>
>> 1. System app can collect the minimal power level requests from each apps
>> then decide what is the minimal power level now.
>> 2. Then calling setPowerLevel() when any condition is triggered. (ex: power
>> key handling, idle time out or proximity event during phone call).
>> 3. App can really request screen to off by calling screenEnabled attribute.
>>>
>>>The third step does not depend on the first and second change.
>
> Yes, the third step didn't depends on first and second.
> What I want to mention is "suspend and screen off can be split into two
> different things"
Right, let's focus on splitting suspend and screen-off. Regardless of
the implementation detail, does this interface make sense to you?
partial interface PowerManager {
// Ask the system to suspend. Return true on success, false otherwise.
boolean suspend();
// Is the device's screen currently enabled?
attribute boolean screenEnabled;
// removed
// attribute boolean cpuSleepAllowed
};
Back to the implementation, if we use this approach then there will
always a wake lock when the phone is awake and suspend() is the only way
to put the device into suspend mode. Simple algorithm for suspend():
[ Initial state: WakeLock_main is on ]
1. Write "mem" to /sys/power/state, which removes WakeLock_main
2. [ Kernel tries to suspend ]
3. Write "on" to /sys/power/state, which creates WakeLock_main
4. Return true if suspend succeeded
Return fales if suspend failed
This practically disables the opportunistic suspend. We need to measure
how does this affect the power usage.
Kanru
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
