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:27:25 +0200 [thread overview]
Message-ID: <201106102227.25391.rjw@sisk.pl> (raw)
In-Reply-To: <20110610184222.GT26436@opensource.wolfsonmicro.com>
On Friday, June 10, 2011, Mark Brown wrote:
> On Fri, Jun 10, 2011 at 08:38:22PM +0200, Rafael J. Wysocki wrote:
> > On Friday, June 10, 2011, Mark Brown wrote:
>
> > > I think from an interface point of view it's something like
> > > UNIVERSAL_DEV_PM_OPS() and friends, probably with some additional ops
> > > that can do the glue bits like enabling wakeup and quiescing activity.
> > > I'd need to think harder about what exactly that'd look like - for my
> > > cases the fundamental thing I want to say is that there's one suspend
> > > routine and one resume routine and I'd like some framework code to work
> > > out when they're called.
>
> > Can your device generate wakeup signals?
>
> I am interested in a fairly large selection of devices but broadly
> speaking any off-SoC device can generate wakeups if it can generate
> interrupts.
So, there are a few things to consider:
* Can the device do things like DMA?
* Does the driver use a workqueue?
* Does it use timers?
In all of the above cases your system suspend handling will require extra
care to make sure those things won't get in the way of the suspend process.
Next, what subsystem (e.g. bus type) is the driver going to work with?
If the subsystem is "smart" enough, it can take care of many things, like
"powering off", wakeup preparations and so on.
Now, there are a few combinations possible. First, if the subsystem is
"smart" and the driver need not take care of the things listed above, then
very likely .runtime_suspend() and .suspend() can do the same and
UNIVERSAL_DEV_PM_OPS() can be used. Next, if the subsystem is "smart",
but the driver needs to take care of those things, then .suspend() has
more to do, but very likely .runtime_suspend() and .suspend_noirq() can
do the same, while .suspend() may simply prepare the device for the next
stage. And so on.
It's probably fair to say that everithing depends on the subsystem, what it
does and what it expects from the driver. In the extreme case, when the
subsystem is like the platform bus type, the driver unfortunately is on its
own and has to deal with the whole complexity.
Thanks,
Rafael
next prev parent reply other threads:[~2011-06-10 20:27 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 [this message]
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
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=201106102227.25391.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).