How to do suspend/resume Debug "turn" under Android or Linux

Transferred from: http://blog.csdn.net/jacobywu/article/details/24735521

Directory (?) [-]

1. Question
2. Answer
1. Add Boot Parameters No_console_suspend
2. Initcall_debug
3. Suspend_test
4. Wakelock
5. Power0
6. Earlysuspend
7. Suspendresume hours fine Tune

Question:

How to get enough information under Linux or Android to do the fine tune of power management?

Answer:

Under Linux or Android, when it comes to power management, there are often not enough information that can be used as a reference and reference in Debug.

We have compiled several commonly used parameters or command for the designer to get enough informaiton to do suspend/resume function Debug.

Add boot Parameters no_console_suspend

Basically, we often use the console as the information source for the Suspend function's debug, but the original source code in the suspend process will get the console off. So we see a certain degree and then we never see the message again.

But we do not know what is happening in the suspend process, which can cause no suspend.
For this, we'll add no_console_suspend to the kernel activation. In am/dm37x APM, modify the Boot.scr file

#!/bin/shcat <<eof > Boot.cmdif fatload MMC 0 82000000 uimagethen Echo * * * * Kernel:/dev/mmcblk0p1/uimage *****f Iecho * * * * * RootFS:/dev/mmcblk0p2 *****# pantherboard DVI output#setenv Bootargs ' CONSOLE=TTYO2,115200N8 Androidboot.console=ttyo2 mem=512m root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1 _static_vrfb_alloc=y omapdss.def_disp=dvi vram=32m omapfb.mode=dvi:1280x720mr-32 omapfb.vram=0:16M mpurate=1000 ' # Pantherboard LCD outputsetenv Bootargs ' console=ttyo2,115200n8 androidboot.console=ttyo2 mem=512M root=/dev/mmcblk0p2 RW rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode= lcd:800x480mr-32 vram=8m omapfb.vram=0:8m mpurate=1000 '

Just add no_console_suspend to the boot parameters.

Setenv Bootargs ' console=ttyo2,115200n8 androidboot.console=ttyo2 mem=512m root=/dev/mmcblk0p2 rw rootfstype=ext3 Rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8m omapfb.vram=0:8m mpurate=1000 no_console_suspend '

If it is OMAP4 APM, please modify the kernel reference file (in U-boot Source code)

This is a basic reference, so it can be used on Android or Linux. After kernel the console suspend, no matter what happened in it, you couldn't see it on the console. With this reference, most of the dead machines at Suspend/resume can see the information of kernel panic through the console, so we'll know where the problem is. Because there are times when the resume is wrong, or suspend to the back of the wrong console does not add this can not be seen.

But this number may cause some time suspend or resume failure in Ti omap3/omap4/am37x/dm37x, and if you have caught the problem there, you can disable it, or it will probably not be able to debug it any longer.

Initcall_debug

This same kernel, the use of the time machine is, when we do not know that the driver in the suspend/resume process is wrong, you can use this to find out the problem. After this, kernel will report the status of each driver or task in the suspend time. We can do this with these information,check in suspend, each task and driver have completed the suspend of the preparation work ...

There are two ways to open this.
One is command under console to activate this function ...

Echo 1 >/sys/module/kernel/parameters/initcall_debugecho 9 >/PROC/SYS/KERNEL/PRINTK

The first command above is to open the Initcall_debug, which is all the kernel will have.

The second command is to improve the kernel message class, because initcall of this information is kern_debug level, so you need to improve the level of PRINTK to see, otherwise suspend/resume time hanging, You will not have the opportunity to see this information.

Another way to activate it is to write it in the kernel's activation parameters.

Setenv Bootargs ' console=ttyo2,115200n8 androidboot.console=ttyo2 mem=512m root=/dev/mmcblk0p2 rw rootfstype=ext3 Rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8m omapfb.vram=0:8m mpurate=1000 initcall_debug no_console_suspend '

In the same way, this can also cause AM37X/DM37X/OMAP4 APM to suspend the problem. So once you know where the problem is, please disable this number out.

suspend_test

This method can be used in the form of RTC Software to do the Suspend/resume of the loop, although it is not enough for Android, (and also to simulate a power_key up to be enough), but for testing the stability of driver, there is a certain use. Don't think that suspend can be a few times, so you can get through thousands of tests. This suspend is 5 seconds to wake up with RTC and then back to Android for 5 seconds to sleep, but for general Linux you can write a script to get him to sleep again, or maybe this tool is more useful rtcwakeup (Google Rtcwakeup).

How to use:
Edit a kernel with this function, make menuconfig to choose

These two options, burn a new kernel, and then open the device you need to test, like wifi,3g.

echo "core" >/sys/power/pm_testecho "mem" >/sys/power/state

This way, it Sleeps and awakens.

Wakelock

The biggest thing about Android and Linux in power Management is the Wakelock machine. Android sometimes encounters suspend, or suspend to the final, inexplicable wake up problem. These may be caused by wakelock, or by users of Wakelock. How to fine tune, use the console to set the Android system:

15 is the f that represents the 16, and in Wakelock, all the debug information is opened and the code is now set. If it's not enough, it might change to 255.
So you can see kernel and frameworks on the operation, application and release of Wakelock. Look at the application and release it to the right.
Note: One of the wakelock is a timeout, that is to say how many milliseconds later, will be self-release, for these wakelock, the application and release may be impossible.

power.0

Sometimes I see the system suspend to the end, and then we encounter power.0 and then suspend fail, and then the whole system goes back. This is Android, because power.0 is the last stroke of Android registration to suspend, it checks to see if there is a wakelock before the CPU enters suspend, and if there are no wakelock at this time, Then it will return-ebusy and then cause the whole suspend to fail. The way to check this problem is to open the debug information on the wakelock above and then see which one goes to Wakelock and then release it.

This is probably the wrong wrong message:

    Pm_noirq_op (): platform_pm_suspend_noirq+0x0/0x38 returns-11    

Earlysuspend

In Android, the other one and power management related to the machine called Earlysuspend, the same can be opened debug message, for Android earlysuspend debug use:

To print the relevant debug information, such as the earlysuspend to be called.

suspend/resume hours fine tune

Sometimes you have to try to suspend/resume too slow a problem. One way is to use the Initcall_debug, then put the PRINTK time stamp, and then see that the process is the slowest, and then check the reason why
I have a patch that is used to adjust the problem, but upstream doesn't accept it, but it doesn't have to be done with this kind of torture, but if you want to use it, you can go down and use it.

Address here: http://www.spinics.net/lists/linux-pm/msg24063.html

The usage is, after you hit this patch, in kernel, choose Pm_debug, Suspend_device_time_debug these two choices.

and then

Like what

Note here is the microsecond oh ... It will shoot those driver that are slow in the Suspend/resume, and then you go and take it out.

How to do suspend/resume Debug "turn" under Android or Linux