[PATCH] pm: print the name of failed suspend function for platform device

2013-02-04 Thread fli24
Print more info when platform device suspend function failed. Without this patch, we can not get the real platform device suspend API info. Example without this patch: pm_op(): platform_pm_suspend+0x0/0x50 returns -11 PM: Device power.0 failed to suspend: error -11 And with this patch:

[PATCH] pm: print the name of failed suspend function for platform device

2013-02-04 Thread fli24
Print more info when platform device suspend function failed. Without this patch, we can not get the real platform device suspend API info. Example without this patch: pm_op(): platform_pm_suspend+0x0/0x50 returns -11 PM: Device power.0 failed to suspend: error -11 And with this patch:

[PATCH V4] suspend: enable freeze timeout configuration through sys

2013-02-01 Thread fli24
At present, the value of timeout for freezing is 20s, which is meaningless in case that one thread is frozen with mutex locked and another thread is trying to lock the mutex, as this time of freezing will fail unavoidably. And if there is no new wakeup event registered, the system will waste at

[PATCH V4] suspend: enable freeze timeout configuration through sys

2013-02-01 Thread fli24
At present, the value of timeout for freezing is 20s, which is meaningless in case that one thread is frozen with mutex locked and another thread is trying to lock the mutex, as this time of freezing will fail unavoidably. And if there is no new wakeup event registered, the system will waste at

[PATCH V3] suspend: enable freeze timeout configuration through sys

2013-01-30 Thread fli24
At present, the value of timeout for freezing is 20s, which is meaningless in case that one thread is frozen with mutex locked and another thread is trying to lock the mutex, as this time of freezing will fail unavoidably. And if there is no new wakeup event registered, the system will waste at

[PATCH V3] suspend: enable freeze timeout configuration through sys

2013-01-30 Thread fli24
At present, the value of timeout for freezing is 20s, which is meaningless in case that one thread is frozen with mutex locked and another thread is trying to lock the mutex, as this time of freezing will fail unavoidably. And if there is no new wakeup event registered, the system will waste at

[PATCH V2] suspend: enable freeze timeout configuration through sys

2013-01-29 Thread fli24
At present, the timeout value for freezing tasks is fixed as 20s, which is too long for handheld device usage, especially for mobile phone. In order to improve user experience, we enable freeze timeout configuration through sys, so that we can tune the value easily for concrete usage, such as

[PATCH V2] suspend: enable freeze timeout configuration through sys

2013-01-29 Thread fli24
At present, the timeout value for freezing tasks is fixed as 20s, which is too long for handheld device usage, especially for mobile phone. In order to improve user experience, we enable freeze timeout configuration through sys, so that we can tune the value easily for concrete usage, such as

[PATCH] suspend: enable freeze timeout configuration through sysctl

2013-01-28 Thread fli24
At present, the timeout value for freezing tasks is fixed as 20s, which is too long for handheld device usage, especially for mobile phone. In order to improve user experience, we enable freeze timeout configuration through sysctl, so that we can tune the value easily for concrete usage, such as

[PATCH] suspend: enable freeze timeout configuration through sysctl

2013-01-28 Thread fli24
At present, the timeout value for freezing tasks is fixed as 20s, which is too long for handheld device usage, especially for mobile phone. In order to improve user experience, we enable freeze timeout configuration through sysctl, so that we can tune the value easily for concrete usage, such as