Re: [update] Re: [PATCH] PM: Make it possible to avoid wakeup events from being lost

Rafael J. Wysocki <rjw <at> sisk.pl>
2010-06-30 23:52:03 GMT

On Wednesday, June 30, 2010, Alan Stern wrote:
> On Wed, 30 Jun 2010, Rafael J. Wysocki wrote:
>
> > > Since there's no longer any way to cancel a call to pm_wakeup_event()
> > > or close the "no suspend" period early, there is no need to use
> > > dynamically-allocated delayed_work structures. You can make do with a
> > > single static timer; always keep it set to expire at the latest time
> > > passed to pm_wakeup_event().
> >
> > The decremenations of events_in_progress wouldn't be balanced with
> > incrementations this way. Or do you have any clever way of dealing with
> > that in mind?
>
> Keep track of the current expiration time in a static variable called
> wakeup_timeout, and use 0 to indicate there is no timeout.
I invented a slightly different version in the meantime, which is appended
as a patch on top of the original one (I don't want to modify the original
patch, since it's been reviewed already by several people and went to my
linux-next branch).
> In pm_wakeup_event() (everything protected by the spinlock):
>
> unsigned long new_timeout = jiffies + msecs_to_jiffies(msecs);
> if (new_timeout == 0)
> new_timeout = 1;
>
> ++event_count;
> if (!wakeup_timeout || time_after(new_timeout, wakeup_timeout)) {
> if (!wakeup_timeout)

(Adding linux-pm <at> lists.linux-foundation.org)
> -----Original Message-----
> From: Shilimkar, Santosh
> Sent: Tuesday, June 29, 2010 2:22 PM
> To: 'Kevin Cernekee'
> Cc: linux-kernel <at> vger.kernel.org; Russell King - ARM Linux
> Subject: Additional fix : (was [v2]printk: fix delayed messages from CPU
> hotplug events)
>
> Hi,
>
> I have faced similar issue as what is being described in below with
> latest kernel.
>
> ------------------------------------------------
> https://patchwork.kernel.org/patch/103347/
>
> When a secondary CPU is being brought up, it is not uncommon for
> printk() to be invoked when cpu_online(smp_processor_id()) == 0. The
> case that I witnessed personally was on MIPS:
>
> http://lkml.org/lkml/2010/5/30/4
>
> If (can_use_console() == 0), printk() will spool its output to log_buf
> and it will be visible in "dmesg", but that output will NOT be echoed to
> the console until somebody calls release_console_sem() from a CPU that
> is online. Therefore, the boot time messages from the new CPU can get
> stuck in "limbo" for a long time, and might suddenly appear on the
> screen when a completely unrelated event (e.g. "eth0: link is down")

Re: [PATCH] PM: Make it possible to avoid wakeup events from being lost

Pavel Machek <pavel <at> ucw.cz>
2010-07-01 13:32:08 GMT

Hi!
> <at> <at> -114,3 +114,17 <at> <at> Description:
> if this file contains "1", which is the default. It may be
> disabled by writing "0" to this file, in which case all devices
> will be suspended and resumed synchronously.
> +
> +What: /sys/power/wakeup_count
> +Date: July 2010
> +Contact: Rafael J. Wysocki <rjw <at> sisk.pl>
> +Description:
> + The /sys/power/wakeup_count file allows user space to avoid
> + losing wakeup events when transitioning the system into a sleep
> + state. Reading from it returns the current number of registered
> + wakeup events and it blocks if some wakeup events are being
> + processed at the time the file is read from. Writing to it
> + will only succeed if the current number of wakeup events is
> + equal to the written value and, if successful, will make the
> + kernel abort a subsequent transition to a sleep state if any
> + wakeup events are reported after the write has returned.
I assume that second suspend always succeeds?
I can't say I quite like the way two sysfs files interact with each
other, but it is certainly better then wakelocks...
Maybe we should create sys_suspend()?
--
--
(english) http://www.livejournal.com/~pavelmachek

Re: About run time power management in linux

I have seen in run time power management helper functions. I have some questions during deep sleep modes
and runtime sleep modes.

1) I have seen the code and found that when System wants to go to suspend (deep sleep mode), it has to check for
pm_runtime_barrier which inturn sees if there is a pending runtime resume then it will not allow system to supend.
So it means system suspend can not be done forcefully if the some peripheral jobs are running, correct?

2) it means when System deep sleep is going on, run time suspend will never come to peripheral as it checks for usage counter and
if it is zero then it will ask try again.

3) if run time suspend is going on, Then if system wants to go into deep sleep mode, it will wait for run time suspend to finish and then
gracefully do the shutdown. correct?

4) Is it mandatory for peripheral driver but not the bus driver to implement runtime_idle operation?

<div>
&nbsp;<br>
Hi Alan,<br>
&nbsp;<br>
I have seen in&nbsp;run time power management helper functions. I have some questions during deep sleep modes<br>
and runtime sleep modes.<br>
&nbsp;<br>
1)&nbsp;I have seen the code and found that when System wants to go to suspend (deep sleep mode), it has to check for<br>
pm_runtime_barrier which inturn sees if there is a pending runtime resume then it will not allow system to supend.<br>
So it means system suspend can not be done forcefully&nbsp;if the&nbsp;some peripheral jobs are running, correct?<br>
&nbsp;<br>
2) it means when System deep sleep is going on, run time suspend will never come&nbsp;to peripheral as it checks for usage counter and<br>
if it is zero then it will ask try again.<br>
&nbsp;<br>
3) if run time suspend is going on, &nbsp;Then if system wants to go into deep sleep mode, it will wait for run time suspend to finish and then <br>
gracefully do the shutdown. correct?<br>
&nbsp;<br>
4) Is it mandatory for peripheral driver but not the bus driver to implement runtime_idle operation?<br>
&nbsp;<br>
RegardsRaj<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br><br>&nbsp;<br>&gt; Date: Wed, 30 Jun 2010 12:25:21 -0400<br>&gt; From: stern <at> rowland.harvard.edu<br>&gt; To: rajkumar278 <at> hotmail.com<br>&gt; CC: linux-pm <at> lists.linux-foundation.org<br>&gt; Subject: RE: [linux-pm] About run time power management in linux<br>&gt; <br>&gt; On Wed, 30 Jun 2010, Raj Kumar wrote:<br>&gt; <br>&gt; &gt; Hi Alan,<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; First thanks for reply. ok as also seems to be in runtime.c, if device wants to suspend and resume<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; then device will call helper functions for pm core like pm_runtime_suspend and pm_runtime_resume,<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; which internally calls the runtime_resume of the bus and which in turn calls the runtime_resume of the driver.<br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; <br>&gt; &gt; correct ?<br>&gt; <br>&gt; Yes.<br>&gt; <br>&gt; Alan Stern<br>&gt; <br>
</div>