All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	linux-pm@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-pci@vger.kernel.org, linux-usb@vger.kernel.org,
	Kevin Hilman <khilman@linaro.org>,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend
Date: Wed, 13 Nov 2013 23:13:24 +0100	[thread overview]
Message-ID: <2003753.HAeVh74cdL@vostro.rjw.lan> (raw)
In-Reply-To: <1384360178-333-1-git-send-email-ulf.hansson@linaro.org>

On Wednesday, November 13, 2013 05:29:38 PM Ulf Hansson wrote:
> The PM core was preventing devices from going inactive during system
> suspend.

That's not even correct.  It prevents the runtime PM framework from being
used to suspend devices during system suspend and that's on purpose.  The
reason why is that we don't want asynchronous runtime suspends to happen
during system suspend and race with the suspend process.

> Remove this constraint and moreover try to inactivate devices
> by invoking pm_runtime_idle() before proceeding with device's
> suspend_late callbacks.
> 
> A great amount of drivers that uses runtime PM will benefit from this.

If the idea is to be able to do pm_runtime_suspend() from the system suspend
code path, this is not the way to go and it kind of indicates the lack of
understanding why things have been arranged this way.

If you want a driver to do the same thing for runtime PM and system
suspend/resume, point its .suspend_late() and .runtime_suspend() to the
same routine and analogously for .runtime_resume() and .resume_early()
(that may not work for PCI, though, because of the _noirq stuff, but that's
the PCI bus type issue).

Of course, the assumption behind .runtime_suspend() and .runtime_resume() is
that they will be run when the device is not in use, while system suspend
may actually happen when the device *is* in use and .suspend() should take
care of that if necessary.  So you may need .suspend() anyway.

One important property of system suspend is that it can happen at any time
and that's why the .suspend() and .resume() callbacks are needed (and this
also means that they can't be the same as .runtime_suspend() and
.runtime_resume() in general).

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

  parent reply	other threads:[~2013-11-13 22:00 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13 16:29 [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend Ulf Hansson
2013-11-13 19:16 ` Alan Stern
2013-11-13 19:16   ` Alan Stern
2013-11-13 22:21   ` Rafael J. Wysocki
2013-11-14 13:21   ` Ulf Hansson
2013-11-14 15:59     ` Alan Stern
2013-11-14 15:59       ` Alan Stern
2013-11-14 16:40       ` Ulf Hansson
2013-11-14 17:57         ` Alan Stern
2013-11-14 17:57           ` Alan Stern
2013-11-15  8:44           ` Ulf Hansson
2013-11-15  9:29             ` Bjørn Mork
2013-11-15  9:29               ` Bjørn Mork
2013-11-15 10:34               ` Ulf Hansson
2013-11-15 15:22             ` Alan Stern
2013-11-15 15:22               ` Alan Stern
2013-11-18 13:27               ` Ulf Hansson
2013-11-18 15:17                 ` Alan Stern
2013-11-18 15:17                   ` Alan Stern
2013-11-19 12:21                   ` Ulf Hansson
2013-11-19 13:21                     ` Rafael J. Wysocki
2013-11-19 15:35                     ` Alan Stern
2013-11-19 15:35                       ` Alan Stern
2013-11-19 16:45                       ` Kevin Hilman
2013-11-19 16:45                         ` Kevin Hilman
2013-11-19 18:03                         ` Alan Stern
2013-11-19 18:03                           ` Alan Stern
2013-11-19 18:43                           ` Kevin Hilman
2013-11-19 18:43                             ` Kevin Hilman
2013-11-21  9:00                           ` Ulf Hansson
2013-11-21  9:00                             ` Ulf Hansson
2013-11-21 15:54                             ` Alan Stern
2013-11-21 15:54                               ` Alan Stern
2013-11-22  8:19                               ` Ulf Hansson
2013-11-22 12:06                                 ` Rafael J. Wysocki
2013-11-20 10:52                       ` Ulf Hansson
2013-11-20 11:23                         ` Pavel Machek
2013-11-20 11:53                           ` Rafael J. Wysocki
2013-11-20 12:43                           ` Ulf Hansson
2013-11-20 16:58                             ` Alan Stern
2013-11-20 16:58                               ` Alan Stern
2013-11-20 19:55                               ` Pavel Machek
2013-11-20 16:55                         ` Alan Stern
2013-11-20 16:55                           ` Alan Stern
2013-11-13 22:13 ` Rafael J. Wysocki [this message]
2013-11-14 14:32   ` Ulf Hansson
2013-11-14 14:32     ` Ulf Hansson
2013-11-14 15:55     ` Alan Stern
2013-11-14 15:55       ` Alan Stern
2013-11-21  9:11       ` Ulf Hansson

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=2003753.HAeVh74cdL@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=khilman@linaro.org \
    --cc=len.brown@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=stern@rowland.harvard.edu \
    --cc=ulf.hansson@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.