From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux PM list <linux-pm@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Linux PCI <linux-pci@vger.kernel.org>,
Kevin Hilman <khilman@linaro.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Subject: Re: [PATCH RFC] PM / Runtime: Rework the "runtime idle" helper routine
Date: Thu, 30 May 2013 21:55:03 +0200 [thread overview]
Message-ID: <5291416.b4M4MTrzPC@vostro.rjw.lan> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1305301247370.1137-100000@iolanthe.rowland.org>
On Thursday, May 30, 2013 01:08:08 PM Alan Stern wrote:
> On Thu, 30 May 2013, Rafael J. Wysocki wrote:
>
> > > Since you're making this change, wouldn't it be a good idea to adopt
> > > Mika's original suggestion and turn on the RPM_AUTO bit in rpmflags
> > > when the use_autosuspend flag is set?
> >
> > I'm not actually sure. It can be done, but I'd prefer to do that as a separate
> > change in any case.
>
> That makes sense.
>
> > > What about cases where the runtime-idle callback does
> > > rpm_schedule_suspend or rpm_request_suspend? You'd have to make sure
> > > that it returns -EBUSY in such cases. Did you audit for this?
> >
> > As far as I could.
> >
> > I'm not worried about the subsystems modified by this patch, because the
> > functionality there won't change (except for PCI, that is).
>
> Right. The subsystems that _aren't_ modified are the ones to worry
> about -- like the USB callback. They are the ones where the behavior
> might change.
Right.
> > > > Index: linux-pm/Documentation/power/runtime_pm.txt
> > > > ===================================================================
> > > > --- linux-pm.orig/Documentation/power/runtime_pm.txt
> > > > +++ linux-pm/Documentation/power/runtime_pm.txt
> > > > @@ -660,11 +660,6 @@ Subsystems may wish to conserve code spa
> > > > management callbacks provided by the PM core, defined in
> > > > driver/base/power/generic_ops.c:
> > > >
> > > > - int pm_generic_runtime_idle(struct device *dev);
> > > > - - invoke the ->runtime_idle() callback provided by the driver of this
> > > > - device, if defined, and call pm_runtime_suspend() for this device if the
> > > > - return value is 0 or the callback is not defined
> > > > -
> > >
> > > The documentation for the runtime-idle callback needs to be updated too.
> >
> > Well, I actually couldn't find the part of it that would need to be updated. :-)
>
> How about this?
Looks good! :-)
May I add your sign-off to it?
Rafael
> Index: usb-3.10/Documentation/power/runtime_pm.txt
> ===================================================================
> --- usb-3.10.orig/Documentation/power/runtime_pm.txt
> +++ usb-3.10/Documentation/power/runtime_pm.txt
> @@ -144,8 +144,12 @@ The action performed by the idle callbac
> (or driver) in question, but the expected and recommended action is to check
> if the device can be suspended (i.e. if all of the conditions necessary for
> suspending the device are satisfied) and to queue up a suspend request for the
> -device in that case. The value returned by this callback is ignored by the PM
> -core.
> +device in that case. If there is no idle callback, or if the callback returns
> +0, then the PM core will attempt to carry out a runtime suspend of the device;
> +in essence, it will call pm_runtime_suspend() directly. To prevent this (for
> +example, if the callback routine has started a delayed suspend), the routine
> +should return a non-zero value. Negative error return codes are ignored by the
> +PM core.
>
> The helper functions provided by the PM core, described in Section 4, guarantee
> that the following constraints are met with respect to runtime PM callbacks for
> @@ -301,9 +305,10 @@ drivers/base/power/runtime.c and include
> removing the device from device hierarchy
>
> int pm_runtime_idle(struct device *dev);
> - - execute the subsystem-level idle callback for the device; returns 0 on
> - success or error code on failure, where -EINPROGRESS means that
> - ->runtime_idle() is already being executed
> + - execute the subsystem-level idle callback for the device; returns an
> + error code on failure, where -EINPROGRESS means that ->runtime_idle() is
> + already being executed; if there is no callback or the callback returns 0
> + then run pm_runtime_suspend(dev) and return its result
>
> int pm_runtime_suspend(struct device *dev);
> - execute the subsystem-level suspend callback for the device; returns 0 on
>
>
> Alan Stern
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
next prev parent reply other threads:[~2013-05-30 19:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-28 23:29 [PATCH RFC] PM / Runtime: Rework the "runtime idle" helper routine Rafael J. Wysocki
2013-05-29 8:29 ` Mika Westerberg
2013-05-29 14:51 ` Alan Stern
2013-05-29 22:18 ` Rafael J. Wysocki
2013-05-30 1:05 ` Aaron Lu
2013-05-30 17:08 ` Alan Stern
2013-05-30 19:55 ` Rafael J. Wysocki [this message]
2013-05-30 20:13 ` Alan Stern
2013-06-02 21:50 ` [PATCH 0/2] PM / Runtime: Rework the "runtime idle" helper routine (was: Re: [PATCH RFC] PM / Runtime: Rework the "runtime idle" helper routine) Rafael J. Wysocki
2013-06-02 21:52 ` [PATCH 1/2, v2] PM / Runtime: Rework the "runtime idle" helper routine Rafael J. Wysocki
2013-06-03 14:33 ` Alan Stern
2013-06-03 19:20 ` Rafael J. Wysocki
2013-06-04 5:14 ` Aaron Lu
2013-06-04 7:15 ` Lan Tianyu
2013-06-02 21:53 ` [PATCH 2/2] PM / Runtime: Update .runtime_idle() callback documentation Rafael J. Wysocki
2013-05-31 19:55 ` [PATCH RFC] PM / Runtime: Rework the "runtime idle" helper routine Kevin Hilman
2013-06-02 19:44 ` 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=5291416.b4M4MTrzPC@vostro.rjw.lan \
--to=rjw@sisk.pl \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.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