From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: linux-pm@lists.linux-foundation.org,
Alan Stern <stern@rowland.harvard.edu>,
linux-omap@vger.kernel.org
Subject: Re: [linux-pm] calling runtime PM from system PM methods
Date: Fri, 10 Jun 2011 22:45:11 +0200 [thread overview]
Message-ID: <201106102245.11703.rjw@sisk.pl> (raw)
In-Reply-To: <20110610185458.GU26436@opensource.wolfsonmicro.com>
On Friday, June 10, 2011, Mark Brown wrote:
> On Fri, Jun 10, 2011 at 08:49:03PM +0200, Rafael J. Wysocki wrote:
> > On Friday, June 10, 2011, Mark Brown wrote:
>
> > > It seems like everyone's agreeing with each other here - from the user
> > > side the request seems to be largely for core infastructure like
> > > UNIVERSAL_DEV_PM_OPS() (which I'm not sure is a good idea any more given
> > > that it doesn't do anything to handle the runtime/system interaction?).
>
> > I'm not sure what you mean here. First, UNIVERSAL_DEV_PM_OPS() actually
> > does what it says, defines a set of operations to use for system suspend,
> > hibernation and runtime PM all the same.
>
> Right, but in the light of what you guys are saying about the
> interactions between runtime suspend and resume I'm no longer clear that
> that is actually sane for something which does use runtime PM, and of
> course if a driver wants to support the wake configuration interface
> then this might also fall out of the window.
It is not generally safe and there are multiple factors deciding of it
(see the message I've just sent for details).
> > The Kevin's point originally was that it might be desirable to do things
> > like calling pm_runtime_suspend() from a driver's (system) .suspend()
> > callback, if I understood it correctly, and the answer was that it wasn't
> > the right thing to do (for reasons given elsewhere in the thread).
>
> Yeah, I think it is too.
>
> > Your point seems to be that simple drivers should not be required to
> > define separate callback routines, for example, for system suspend and
> > runtime PM. However, they aren't required to do so, they can point
> > all of their "suspend" callback pointers to the same routine, which is
> > what the UNIVERSAL_DEV_PM_OPS() macro does.
>
> So that's definitely safe? I guess this partly comes back to the thing
> I'm saying about how I'm finding all this stuff difficult to reason
> about, every time I see such discussion I get confused about needing to
> worry about it or not.
Well, it's just that multiple things go into play here: the subsystem, the
overall complexity of the driver and so on. I can probably say what's
good for a PCI driver, but that may not be suitable for a USB driver, for
one example.
Thanks,
Rafael
next prev parent reply other threads:[~2011-06-10 20:44 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-02 0:05 calling runtime PM from system PM methods Kevin Hilman
2011-06-02 14:18 ` [linux-pm] " Alan Stern
2011-06-02 17:10 ` Kevin Hilman
2011-06-02 18:38 ` Alan Stern
2011-06-06 18:29 ` Rafael J. Wysocki
2011-06-06 19:16 ` Alan Stern
2011-06-06 22:25 ` Kevin Hilman
2011-06-07 13:55 ` Alan Stern
2011-06-07 21:32 ` Rafael J. Wysocki
2011-06-07 22:34 ` Kevin Hilman
2011-06-08 22:50 ` Kevin Hilman
2011-06-09 5:29 ` Magnus Damm
2011-06-09 13:56 ` Alan Stern
2011-06-10 14:36 ` Mark Brown
2011-06-10 14:51 ` Alan Stern
2011-06-10 15:21 ` Mark Brown
2011-06-10 15:45 ` Alan Stern
2011-06-10 15:57 ` Mark Brown
2011-06-10 17:17 ` Alan Stern
2011-06-10 17:31 ` Mark Brown
2011-06-10 18:38 ` Rafael J. Wysocki
2011-06-10 18:42 ` Mark Brown
2011-06-10 20:27 ` Rafael J. Wysocki
2011-06-10 21:27 ` Alan Stern
2011-06-11 11:42 ` Mark Brown
2011-06-11 20:56 ` Rafael J. Wysocki
2011-06-13 12:22 ` [linux-pm] " Mark Brown
2011-06-10 18:49 ` Rafael J. Wysocki
2011-06-10 18:54 ` Mark Brown
2011-06-10 20:45 ` Rafael J. Wysocki [this message]
2011-06-10 23:52 ` Kevin Hilman
2011-06-11 16:42 ` Alan Stern
2011-06-11 22:46 ` Rafael J. Wysocki
2011-06-12 15:59 ` Alan Stern
2011-06-12 18:27 ` Rafael J. Wysocki
2011-06-15 21:54 ` Kevin Hilman
2011-06-16 0:01 ` Rafael J. Wysocki
2011-06-16 1:17 ` Kevin Hilman
2011-06-16 14:27 ` Alan Stern
2011-06-16 22:48 ` Rafael J. Wysocki
2011-06-17 19:47 ` Rafael J. Wysocki
2011-06-17 20:04 ` Alan Stern
2011-06-17 21:29 ` Rafael J. Wysocki
2011-06-18 11:08 ` Rafael J. Wysocki
2011-06-18 15:31 ` Alan Stern
2011-06-18 21:01 ` Rafael J. Wysocki
2011-06-18 23:57 ` Rafael J. Wysocki
2011-06-19 1:42 ` Alan Stern
2011-06-19 14:04 ` Rafael J. Wysocki
2011-06-19 15:01 ` Alan Stern
2011-06-19 19:36 ` Rafael J. Wysocki
2011-06-20 14:39 ` Alan Stern
2011-06-20 19:53 ` Rafael J. Wysocki
2011-06-16 22:30 ` Rafael J. Wysocki
2011-06-10 23:14 ` Kevin Hilman
2011-06-11 16:27 ` Alan Stern
2011-06-11 23:13 ` Rafael J. Wysocki
2011-06-06 18:01 ` 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=201106102245.11703.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--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).