public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Raj Kumar <rajkumar278@hotmail.com>
Cc: linux-pm@lists.linux-foundation.org
Subject: Re: One issue regarding the run time power management
Date: Wed, 3 Nov 2010 04:18:02 +0100	[thread overview]
Message-ID: <201011030418.02830.rjw@sisk.pl> (raw)
In-Reply-To: <BLU102-W6F8402163EAD81AFBF321EB490@phx.gbl>

On Tuesday, November 02, 2010, Raj Kumar wrote:
> 
> Hi,
>  
> There is a one issue coming regarding the run time power management during system suspend, Suppose
> system suspend is going on and before the suspend callback of driver is executed, driver issues a runtime resume to run time power management core before it gets
> the system suspend call back but System suspend is going on then how the run time power management prevents this condition?
>  
> As I saw the code during dpm_prepare, power usage count is incremented by 1 by calling pm_runtime_get_noresume(dev) and then it calls
> pm_runtime_barrier,
>  
> Since During System suspend, driver calls pm_runtime_get which will invoke 
>  
> atomic_inc(&dev->power.usage_count);
>  
> which increments the power usage count and calls pm_request_resume which does not have any check on power usage count,

pm_request_resume() called during system suspend will not have any effect, unless it is called before
the pm_runtime_barrier() in dpm_prepare(), in which case the device is going to be resumed and
system suspend will be aborted, because the PM workqueue if frozen before the suspend of
devices.

> So when System suspend is going on and it has not reached suspend call back of driver and driver submits run time resume request (if
> the device is suspended at runtime earlier)
>  
> Then How run time power management prevents device run time resume when the system suspend is going on as it does not
> check for power usage count?

The request to resume the device waits until the thawing of the PM workqueue.
if the driver needs to resume the device during suspend, it should use
pm_runtime_resume() for that, in which case the PM core doesn't care.

Thanks,
Rafael

  reply	other threads:[~2010-11-03  3:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02 20:38 One issue regarding the run time power management Raj Kumar
2010-11-03  3:18 ` Rafael J. Wysocki [this message]
2010-11-07 16:31   ` Alan Stern
2010-11-08 23:27     ` Rafael J. Wysocki
2011-03-22  9:31   ` Regarding the dedicated memory for hibernation Raj Kumar
2011-03-22 20:36     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201011030418.02830.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=rajkumar278@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox