linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Kevin Hilman <khilman@deeprootsystems.com>,
	Alan Stern <stern@rowland.harvard.edu>
Cc: linux-pm@vger.kernel.org, linux-omap@vger.kernel.org,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Nishanth Menon <nm@ti.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND] PM / Runtime: let rpm_resume() succeed if RPM_ACTIVE, even when disabled
Date: Thu, 20 Sep 2012 23:58:24 +0200	[thread overview]
Message-ID: <201209202358.24400.rjw@sisk.pl> (raw)
In-Reply-To: <1348176542-28983-1-git-send-email-khilman@deeprootsystems.com>

On Thursday, September 20, 2012, Kevin Hilman wrote:
> From: Kevin Hilman <khilman@ti.com>
> 
> When runtime PM is disabled, what we want is for callbacks not to be
> called from then on.  However, currently, when runtime PM is disabled,
> operations such as 'get' will also fail even if the device is
> currently active.
> 
> Since calling 'get' on a device that is already RPM_ACTIVE does not
> involve calling the callbacks, it should be allowed to succeed, even
> if runtime PM is disabled.
> 
> This is particularily useful in runtime PM enabled drivers that are
> used during system suspend.  Because runtime PM is disabled during
> system suspend, currently any driver's use of pm_runtime_get* will
> fail with -EACCES.  This is expected if the device was already runtime
> suspended, but if the device is actually active (due to recent usage,
> autosuspend timeout not expired, or pm_runtime_resume() called in
> ->suspend() method), the pm_runtime_get*() call should actually
> succeed.

I'd say the problem is when the drive in question uses the return value of
pm_runtime_get_sync(), for example, to decide whether or not it is safe
to access the hardware.  In that case it may decide that accessing the
hardware is unsafe during system suspend, although that's not really the
case.  So the change you're proposing allows drivers of this kind  (and there
may be a substantial number of them) to be simplified slightly.

> To permit the usage described above, add a check to rpm_resume() so
> that success is returned in the case where a driver is suspended (it's
> ->suspend callback has been called) but is still RPM_ACTIVE.
> 
> This patch was developed in close collaboration with Rafael J. Wysocki
> <rjw@sisk.pl>
> 
> Tested on AM3730/Beagle-xM where wakeup IRQ firing during the late
> suspend phase triggers runtime PM activity in the I2C driver since the
> wakeup IRQ is on an I2C-connected PMIC.
> 
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Signed-off-by: Kevin Hilman <khilman@ti.com>

OK, I wonder if anyone has any objections against this.  Alan?

Rafael


> ---
> This version is just a resend with the vger address for linux-pm.
> 
>  drivers/base/power/runtime.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 7d9c1cb..dafa5ec 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -510,7 +510,8 @@ static int rpm_resume(struct device *dev, int rpmflags)
>  	if (dev->power.runtime_error)
>  		retval = -EINVAL;
>  	else if (dev->power.disable_depth > 0)
> -		retval = -EACCES;
> +		retval = dev->power.is_suspended && 
> +			dev->power.runtime_status == RPM_ACTIVE ? 1 : -EACCES;
>  	if (retval)
>  		goto out;
>  
> 

  reply	other threads:[~2012-09-20 21:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-20 21:29 [PATCH RESEND] PM / Runtime: let rpm_resume() succeed if RPM_ACTIVE, even when disabled Kevin Hilman
2012-09-20 21:58 ` Rafael J. Wysocki [this message]
2012-09-21 17:50   ` Alan Stern
2012-09-21 19:29     ` Rafael J. Wysocki
2012-09-21 20:22       ` Alan Stern
2012-09-21 21:40         ` Kevin Hilman

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=201209202358.24400.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=grygorii.strashko@ti.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nm@ti.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=stern@rowland.harvard.edu \
    /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;
as well as URLs for NNTP newsgroup(s).