On Tue, 2011-08-09 at 13:49 +0900, MyungJoo Ham wrote: > On Tue, Aug 9, 2011 at 11:27 AM, Liu, ShuoX <shuox.liu@xxxxxxxxx> wrote: > > From: ShuoX Liu <shuox.liu@xxxxxxxxx> > > > > Record S3 failure time about each reason and the latest two failed > > devices' names in S3 progress. > > We can check it through 'suspend_stats' entry in debugfs. > > > > The motivation of the patch: > > > > We are enabling power features on Medfield. Comparing with PC/notebook, > > a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far > > more frequently. If it can't enter suspend-2-ram in time, the power > > might be used up soon. > > > > We often find sometimes, a device suspend fails. Then, system retries > > s3 over and over again. As display is off, testers and developers > > don't know what happens. > > > > Some testers and developers complain they don't know if system > > tries suspend-2-ram, and what device fails to suspend. They need > > such info for a quick check. The patch adds suspend_stats under > > debugfs for users to check suspend to RAM statistics quickly. > > > > If not using this patch, we have other methods to get info about > > what device fails. One is to turn on CONFIG_PM_DEBUG, but users > > would get too much info and testers need recompile the system. > > > > In addition, dynamic debug is another good tool to dump debug info. > > But it still doesn't match our utilization scenario closely. > > 1) user need write a user space parser to process the syslog output; > > 2) Our testing scenario is we leave the mobile for at least hours. > > Then, check its status. No serial console available during the > > testing. One is because console would be suspended, and the other > > is serial console connecting with spi or HSU devices would consume > > power. These devices are powered off at suspend-2-ram. > > > > Thank Greg and Rafael for their great comments. > > > > Change Log: > > V3: Change some programming styles. > > V2: > > 1) Change the sysfs entry to debugfs. > > 2) Add some explanation in document file. > > > > Contribution: > > yanmin_zhang@xxxxxxxxxxxxxxx > > > > Signed-off-by: ShuoX Liu <shuox.liu@xxxxxxxxx> > > --- > > Documentation/power/basic-pm-debugging.txt | 19 +++++++++ > > drivers/base/power/main.c | 35 ++++++++++++++-- > > include/linux/suspend.h | 16 +++++++ > > kernel/power/main.c | 59 ++++++++++++++++++++++++++++ > > kernel/power/suspend.c | 15 ++++++- > > 5 files changed, 136 insertions(+), 8 deletions(-) > > > > This patch looks very helpful. Great! :) > > Anyway, how about including the error value induced by the device > along with the device name? > For example, > > failed_devs: > last_failed: alarm -5 > adc -10 > > or > > failed_devs: > last_failed: alarm > adc > last_errorno: -5 > -10 > > Or, even, we may consider including the failed step: > failed_devs: > last_failed: alarm > adc > last_errorno: -5 > -10 > last_step: suspend > suspend_noirq > It's a good idea! We would change it to output like above format. Thanks MyunJoo. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
