public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Linux-pm mailing list" <linux-pm@lists.linux-foundation.org>,
	Oliver Neukum <oliver@neukum.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Greg KH <gregkh@suse.de>, Arjan van de Ven <arjan@infradead.org>
Subject: Re: [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 5)
Date: Fri, 26 Jun 2009 23:49:41 +0200	[thread overview]
Message-ID: <200906262349.42851.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0906241724020.22054-100000@iolanthe.rowland.org>

On Wednesday 24 June 2009, Alan Stern wrote:
> On Wed, 24 Jun 2009, Rafael J. Wysocki wrote:
> 
> > +config PM_RUNTIME
> > +	bool "Run-time PM core functionality"
> > +	depends on PM
> > +	---help---
> > +	  Enable functionality allowing I/O devices to be put into energy-saving
> > +	  (low power) states at run time (or autosuspended) after a specified
> > +	  period of inactivity and woken up in response to a hardware-generated
> > +	  wake-up event or a driver's request.
> > +
> > +	  Hardware support is generally required for this functionality to work
> > +	  and the bus type drivers of the buses the devices are on are
> > +	  responsibile for the actual handling of the autosuspend requests and
> 
> s/ibile/ible/
> 
> > @@ -165,6 +168,28 @@ typedef struct pm_message {
> >   * It is allowed to unregister devices while the above callbacks are being
> >   * executed.  However, it is not allowed to unregister a device from within any
> >   * of its own callbacks.
> > + *
> > + * There also are the following callbacks related to run-time power management
> > + * of devices:
> > + *
> > + * @runtime_suspend: Prepare the device for a condition in which it won't be
> > + *	able to communicate with the CPU(s) and RAM due to power management.
> > + *	This need not mean that the device should be put into a low power state.
> > + *	For example, if the device is behind a link which is about to be turned
> > + *	off, the device may remain at full power.  Still, if the device does go
> 
> s/Still, if/If/ -- the word "Still" seems a little odd in this context.
> 
> > + *	to low power and if device_may_wakeup(dev) is true, remote wake-up
> > + *	(i.e. hardware mechanism allowing the device to request a change of its
> 
> s/i.e. /i.e., a /
> 
> > + *	power state, such as PCI PME) should be enabled for it.
> > + *
> > + * @runtime_resume: Put the device into the fully active state in response to a
> > + *	wake-up event generated by hardware or at a request of software.  If
> 
> s/at a request/at the request/
> 
> > + *	necessary, put the device into the full power state and restore its
> > + *	registers, so that it is fully operational.
> 
> 
> > + * RPM_ACTIVE		Device is fully operational, no run-time PM requests are
> > + *			pending for it.
> > + *
> > + * RPM_IDLE		It has been requested that the device be suspended.
> > + *			Suspend request has been put into the run-time PM
> > + *			workqueue and it's pending execution.
> > + *
> > + * RPM_SUSPENDING	Device bus type's ->runtime_suspend() callback is being
> > + *			executed.
> > + *
> > + * RPM_SUSPENDED	Device bus type's ->runtime_suspend() callback has
> > + *			completed successfully.  The device is regarded as
> > + *			suspended.
> > + *
> > + * RPM_WAKE		It has been requested that the device be woken up.
> > + *			Resume request has been put into the run-time PM
> > + *			workqueue and it's pending execution.
> > + *
> > + * RPM_RESUMING		Device bus type's ->runtime_resume() callback is being
> > + *			executed.
> 
> Remember to add RPM_NOTIFY.
> 
> 
> > +/**
> > + * __pm_get_child - Increment the counter of unsuspended children of a device.
> > + * @dev: Device to handle;
> > + */
> > +static void __pm_get_child(struct device *dev)
> > +{
> > +	atomic_inc(&dev->power.child_count);
> > +}
> > +
> > +/**
> > + * __pm_put_child - Decrement the counter of unsuspended children of a device.
> > + * @dev: Device to handle;
> > + */
> > +static void __pm_put_child(struct device *dev)
> > +{
> > +	if (!atomic_add_unless(&dev->power.child_count, -1, 0))
> > +		dev_WARN(dev, "Unbalanced counter decrementation");
> > +}
> 
> I think we don't need this dev_WARN.  It should be straightforward to
> verify that the increments and decrements balance correctly, and the
> child_count field isn't manipulated by drivers.
> 
> In fact, these don't need to be separate routines at all.  Just call
> atomic_inc or atomic_dec directly.
> 
> > +
> > +/**
> > + * __pm_runtime_suspend - Run a device bus type's runtime_suspend() callback.
> > + * @dev: Device to suspend.
> > + * @sync: If unset, the funtion has been called via pm_wq.
> > + *
> > + * Check if the run-time PM status of the device is appropriate and run the
> > + * ->runtime_suspend() callback provided by the device's bus type.  Update the
> > + * run-time PM flags in the device object to reflect the current status of the
> > + * device.
> > + */
> > +int __pm_runtime_suspend(struct device *dev, bool sync)
> > +{
> > +	struct device *parent = NULL;
> > +	unsigned long flags;
> > +	int error = -EINVAL;
> 
> Remove the initializer.
> 
> > +
> > +	might_sleep();
> > +
> > +	spin_lock_irqsave(&dev->power.lock, flags);
> > +
> > + repeat:
> > +	if (dev->power.runtime_status == RPM_ERROR) {
> 
> Insert:		error = -EINVAL;
> 
> > +		goto out;
> > +	} else if (dev->power.runtime_status & RPM_SUSPENDED) {
> 
> ...
> 
> 
> > +void pm_runtime_put(struct device *dev)
> > +{
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&dev->power.lock, flags);
> > +
> > +	if (!__pm_runtime_put(dev)) {
> > +		dev_WARN(dev, "Unbalanced counter decrementation");
> 
> "decrementation" isn't a word -- or if it is, it shouldn't be.  :-)  
> Just use "decrement".  Similarly in other places.
> 
> > +/**
> > + * pm_runtime_add - Update run-time PM fields of a device while adding it.
> > + * @dev: Device object being added to device hierarchy.
> > + */
> > +void pm_runtime_add(struct device *dev)
> > +{
> > +	dev->power.runtime_notify = false;
> > +	INIT_DELAYED_WORK(&dev->power.suspend_work, pm_runtime_suspend_work);
> 
> Doesn't INIT_DELAYED_WORK belong in pm_runtime_init?
> Do we want the bus subsystem to be responsible for doing:
> 
> 	dev->power.runtime_disabled = false;
> 	pm_runtime_put(dev);
> 
> after calling device_add?  Or should device_add do it?
> 
> 
> > Index: linux-2.6/include/linux/pm_runtime.h
> > ===================================================================
> > --- /dev/null
> > +++ linux-2.6/include/linux/pm_runtime.h
> 
> > +static inline struct device *suspend_work_to_device(struct work_struct *work)
> > +{
> > +	struct delayed_work *dw = to_delayed_work(work);
> > +	struct dev_pm_info *dpi;
> > +
> > +	dpi = container_of(dw, struct dev_pm_info, suspend_work);
> > +	return container_of(dpi, struct device, power);
> > +}
> 
> You don't need to iterate container_of like this.  You can do:
> 
> 	return container_of(dw, struct device, power.suspend_work);
> 
> > +
> > +static inline struct device *work_to_device(struct work_struct *work)
> > +{
> > +	struct dev_pm_info *dpi;
> > +
> > +	dpi = container_of(work, struct dev_pm_info, work);
> > +	return container_of(dpi, struct device, power);
> > +}
> 
> Similarly here.
> 
> These two routines aren't used outside of runtime.c.  They should be
> moved into that file.  The same goes for pm_children_suspended and
> pm_suspend_possible.
> 
> > +
> > +static inline void __pm_runtime_get(struct device *dev)
> > +{
> > +	atomic_inc(&dev->power.resume_count);
> > +}
> 
> Why introduce __pm_runtime_get?  Just make this pm_runtime_get.
> 
> > +static inline void pm_runtime_remove(struct device *dev)
> > +{
> > +	pm_runtime_disable(dev);
> > +}
> 
> You forgot to decrement the parent's child_count if dev isn't
> suspended (and then do a idle_notify on the parent).  Because of this 
> additional complexity, don't inline the routine.
> 
> > Index: linux-2.6/drivers/base/dd.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/base/dd.c
> > +++ linux-2.6/drivers/base/dd.c
> > @@ -23,6 +23,7 @@
> >  #include <linux/kthread.h>
> >  #include <linux/wait.h>
> >  #include <linux/async.h>
> > +#include <linux/pm_runtime.h>
> >  
> >  #include "base.h"
> >  #include "power/power.h"
> > @@ -202,8 +203,12 @@ int driver_probe_device(struct device_dr
> >  	pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
> >  		 drv->bus->name, __func__, dev_name(dev), drv->name);
> >  
> > +	pm_runtime_disable(dev);
> > +
> >  	ret = really_probe(dev, drv);
> >  
> > +	pm_runtime_enable(dev);
> > +
> 
> Shouldn't we guarantee that a device isn't probed while it is in a
> suspended state?  So this should be
> 
> 	pm_runtime_get(dev);
> 	ret = pm_runtime_resume(dev);
> 	if (ret == 0)
> 		ret = really_probe(dev, drv);
> 	pm_runtime_put(dev);	
> 
> It might be nice to have a simple combined pm_runtime_get_and_resume
> for this sort of situation.

Just to clarify, the last version of the patch I sent didn't address the
comments from this, but this was not because I didn't agree with them, but
I was just focusing on simplifying drivers/base/power/resume.c .

I'll address them in the next version.

Best,
Rafael

  parent reply	other threads:[~2009-06-26 21:49 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-22 23:21 [PATCH] PM: Introduce core framework for run-time PM of I/O devices (rev. 3) Rafael J. Wysocki
2009-06-23 17:00 ` Rafael J. Wysocki
2009-06-23 17:10 ` Alan Stern
2009-06-24  0:08   ` Rafael J. Wysocki
2009-06-24  0:36     ` [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 4) Rafael J. Wysocki
2009-06-24 19:24       ` [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 5) Rafael J. Wysocki
2009-06-24 21:30         ` Alan Stern
2009-06-25 16:49           ` [linux-pm] " Alan Stern
2009-06-25 21:58             ` Rafael J. Wysocki
2009-06-25 23:17               ` Rafael J. Wysocki
2009-06-26 18:06               ` Alan Stern
2009-06-26 20:46                 ` [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 6) Rafael J. Wysocki
2009-06-26 21:13                   ` Alan Stern
2009-06-26 22:32                     ` Rafael J. Wysocki
2009-06-27  1:25                       ` Alan Stern
2009-06-27 14:51                       ` Alan Stern
2009-06-27 21:51                         ` [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 7) Rafael J. Wysocki
2009-06-28 10:25                     ` [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 6) Rafael J. Wysocki
2009-06-28 21:07                       ` Alan Stern
2009-06-29  0:15                         ` Rafael J. Wysocki
2009-06-29  3:05                           ` Alan Stern
2009-06-29 14:09                             ` Rafael J. Wysocki
2009-06-29 14:29                               ` Alan Stern
2009-06-29 14:54                                 ` Rafael J. Wysocki
2009-06-29 15:27                                   ` Alan Stern
2009-06-29 15:55                                     ` Rafael J. Wysocki
2009-06-29 16:10                                       ` Alan Stern
2009-06-29 16:39                                         ` Rafael J. Wysocki
2009-06-29 17:29                                           ` Alan Stern
2009-06-29 18:25                                             ` Rafael J. Wysocki
2009-06-29 19:25                                               ` Alan Stern
2009-06-29 21:04                                                 ` Rafael J. Wysocki
2009-06-29 22:00                                                   ` Alan Stern
2009-06-29 22:50                                                     ` Rafael J. Wysocki
2009-06-30 15:10                                                       ` Alan Stern
2009-06-30 22:30                                                         ` [RFC] Run-time PM framework (was: Re: [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 6)) Rafael J. Wysocki
2009-07-01 15:35                                                           ` Alan Stern
2009-07-01 22:19                                                             ` Rafael J. Wysocki
2009-07-02 15:42                                                               ` Rafael J. Wysocki
2009-07-02 15:55                                                               ` Alan Stern
2009-07-02 17:50                                                                 ` Rafael J. Wysocki
2009-07-02 19:53                                                                   ` Alan Stern
2009-07-02 23:05                                                                     ` Rafael J. Wysocki
2009-07-03 20:58                                                                       ` Alan Stern
2009-07-03 23:57                                                                         ` Rafael J. Wysocki
2009-07-04  3:12                                                                           ` Alan Stern
2009-07-04 21:27                                                                             ` Rafael J. Wysocki
2009-07-05 14:50                                                                               ` Alan Stern
2009-07-05 21:47                                                                                 ` Rafael J. Wysocki
2009-06-26 21:49           ` Rafael J. Wysocki [this message]
2009-06-25 14:57         ` [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 5) Magnus Damm
2009-06-26 22:02           ` 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=200906262349.42851.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=arjan@infradead.org \
    --cc=gregkh@suse.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=magnus.damm@gmail.com \
    --cc=mingo@elte.hu \
    --cc=oliver@neukum.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