Hi, I want to add one more thing here. Also architecture specific power management will be hooked up with the linux power management framework like using suspend_set_ops. Which will validate which power management modes will be supported by the hardware.
i.e when you do cat /sys/power/state you will see which modes are supported e.g. standby, mem cheers raj On Tue, Jun 15, 2010 at 10:33 PM, Mike Chan <[email protected]> wrote: > Two parts here, first part is for Frank, second is for the original > post (inline). > > Applications: > Once all apps have released their wakelocks > > App Framework: > Power manager service decides to suspend the device (if the user turns > off the screen) > by writing "mem" to /sys/power/state > > Kernel: > early suspend hooks get called, entry point is: > > > kerne/power/main.c: state_store().... > > 196 #ifdef CONFIG_SUSPEND > 197 for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, > state++) { > 198 if (*s && len == strlen(*s) && !strncmp(buf, *s, len)) > 199 break; > 200 } > 201 if (state < PM_SUSPEND_MAX && *s) > 202 #ifdef CONFIG_EARLYSUSPEND > 203 if (state == PM_SUSPEND_ON || valid_state(state)) { > 204 error = 0; > 205 request_suspend_state(state); > > // Early suspend here (screen off is triggered here) > > 206 } > 207 #else > 208 error = enter_state(state); > > // Regular linux suspend occurs here > > 209 #endif > 210 #endif > > The order which events occurs is the following: > > early suspend (triggered by pressing power button to turn screen off) > normal supsend hooks (triggered by last wakelock released from the kernel) > cpu sleep > normal resume > late resume (triggers by pressing power button to turn screen on) > > > If you want to debug suspend, theres a few things you can do. > enable CONFIG_PM_DEBUG and PM_VERBOSE, which combined will print out > to the dmesg when each driver suspends and resumes > > There is also: > /sys/module/wakelock/parameters/debug_mask > /sys/module/earlysuspend/parameters/debug_mask > > you can see the debug mask flags here: > http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=kernel/power/earlysuspend.c;h=84bed51dcdce79503d718186775e690560d4637b;hb=android-2.6.32 > > and > > http://android.git.kernel.org/?p=kernel/common.git;a=blob;f=kernel/power/wakelock.c;h=ca48bb8d316b9cfc0bf6db0c0a2c6667ceb44699;hb=android-2.6.32 > > -- Mike > > > > On Tue, Jun 15, 2010 at 8:46 AM, frank.sposaro <[email protected]> > wrote: >> Hi Raj. >> >> Any luck on this? >> I am trying to trace the full process of how things get shut down when >> the phone is suspended. >> Where I am at right now is that when the phone is suspended or resumed >> the earlysuspend.c >> file executes a function and places a earlysuspend struct on a >> work_queue. >> I'm trying to find the specific android power management that get's >> applied over top of the linux PM. (see graph in link below) >> Feeling like that graph may be slightly out of date and things moved >> around, but I may be missing something. >> I wish those writing Android Docs would time stamp everything. >> >> >> Power >> >> http://source.android.com/porting/power_management.html >> ----- Attempting to trace the tree above ---- >> >> PowerManager >> http://developer.android.com/reference/android/os/PowerManager.html >> >> PowerManagerService.java >> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=services/java/com/android/server/PowerManagerService.java;h=966ecb0bf5e34c61c54a73b22ade873b7e564b23;hb=HEAD >> >> * Not finding /lib/hardware/power.c or /drivers/android/power.c * >> >> spos...@mobiprog:~/android-source/donut$ find . power.c | grep power.c >> ./hardware/libhardware_legacy/power/power.c >> ./msm/arch/mips/au1000/common/power.c >> ./msm/arch/powerpc/platforms/pseries/power.c >> ./msm/arch/sparc64/kernel/power.c >> ./msm/drivers/acpi/power.c ---- Mabey this? ACPI Bus Power >> Management, but doesn't look Android Specific. 2002. See link below >> ./msm/drivers/parisc/power.c -- HP PARISC soft power switch >> support drive >> ./msm/drivers/power/apm_power.c >> ./msm/drivers/power/pda_power.c >> ./msm/drivers/input/apm-power.c >> ./msm/drivers/net/wireless/iwlwifi/iwl-power.c >> >> >> /* >> * acpi_power.c - ACPI Bus Power Management >> * ACPI power-managed devices may be controlled in two ways: >> * 1. via "Device Specific (D-State) Control" >> * 2. via "Power Resource Control". >> * This module is used to manage devices relying on Power Resource >> Control. >> * >> * An ACPI "power resource object" describes a software controllable >> power >> * plane, clock plane, or other resource used by a power managed >> device. >> * A device may rely on multiple power resources, and a power resource >> * may be shared by multiple devices. >> */ >> http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=drivers/acpi/power.c;h=c926e7d4a0d619fd5b16a3b8d4806b05bba5aeeb;hb=android-msm-2.6.29-donut >> >> >> ---- Additional NDK Files. These are Android Specific, but on top of >> the kernel ---- >> >> com_android_server_BatteryService.cpp >> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=services/jni/com_android_server_BatteryService.cpp;h=8e7cadc6b680fc420d341faa094c71922946fdab;hb=HEAD >> >> com_android_server_HardwareService.cpp >> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=services/jni/com_android_server_HardwareService.cpp;h=253e6558de36f943dc324415a9c41e6eb23cd308;hb=HEAD >> >> >> GlobalActions.java was PowerDialog.java >> http://android.git.kernel.org/?p=platform/frameworks/policies/base.git;a=blob;f=mid/com/android/internal/policy/impl/GlobalActions.java;h=c7d4b14bb7def6d47f32bc5efaacd91056d51be1;hb=HEAD >> >> Sleep and wake up as shown in dmesg >> <6>[16337.332275] request_suspend_state: wakeup (3->0) at >> 16331561233285 (2010-06-15 01:00:37.811553944 UTC) >> <4>[16337.527679] init sharp panel >> <6>[16343.192291] request_suspend_state: sleep (0->3) at >> 16337421218656 (2010-06-15 01:00:43.671569832 UTC) >> <4>[16343.234863] deinit sharp panel >> >> /* >> * prints "request_suspend_state" above >> * all is seems to do is create an earlysuspend struct >> * and place it on the work_queue >> */ >> earlysuspend.c >> http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=kernel/power/earlysuspend.c;h=84bed51dcdce79503d718186775e690560d4637b;hb=HEAD >> >> >> /* The early_suspend structure defines suspend and resume hooks to be >> called >> * when the user visible sleep state of the system changes, and a >> level to >> * control the order. They can be used to turn off the screen and >> input >> * devices that are not used for wakeup. >> * Suspend handlers are called in low to high level order, resume >> handlers are >> * called in the opposite order. If, when calling >> register_early_suspend, >> * the suspend handlers have already been called without a matching >> call to the >> * resume handlers, the suspend handler will be called directly from >> * register_early_suspend. This direct call can violate the normal >> level order. >> */ >> earlysuspend.h >> http://randomtechinfo.com/sdx/include/earlysuspend.h >> >> power.h >> http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=kernel/power/power.h;h=96cab35c3d22a3f1e337c141439c768dc4e4f4b3;hb=HEAD >> >> >> >> >> >> On Jun 1, 7:33 am, Raj Kumar <[email protected]> wrote: >>> Hi all, >>> >>> I have question regardingpowermanagement in kernel. What APIs are >>> available in linux kernel >>> forpowermanagement are available for device drivers? e.g. Driver is >>> interested in knowing the systempowerstartes. Which APIs the driver should >>> register for which it will >>> get notifications ofpowerstates >>> in system? >>> >>> Previously in linux kernel pm_register was used which is obselete now. >>> There are other things as well >>> like APM and ACPI. But for embedded devices, if the driver is >>> interested in getting the systempower >>> states from kernel, which APIs are used? >>> > > This is more linux PM specific not so much Android, but I don't mind > answering here, just for future reference in case you want a wider > audience. > > You can the register_pm_notifier() call which will register a > notifier_block and you will receive events PM_SUSPEND_PREPARE, > PM_POST_SUSPEND etc.. Only a few drivers use this, I suggest you only > use this if you have a particular spot in suspend/resume that you need > to be called. Or your driver doesn't fit well in the device tree > > More commonly is to use the struct dev_pm_ops and fill in your > .suspend_noirq .resume_noirq etc... > > pm_ops seems to be the new way to suspend instead of just using the > suspend/resume calls in say struct platform_driver. Chances are your > driver's struct will have a struct pm_dev_ops in there somewhere that > you can fill out when you register. > > Android has an extra early_suspend hook that gets called before all > linux-pm suspend hooks, which I explain above. > > -- Mike > >>> /r >> >> -- >> unsubscribe: [email protected] >> website: http://groups.google.com/group/android-kernel >> > > -- > unsubscribe: [email protected] > website: http://groups.google.com/group/android-kernel -- unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel
