All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org, linux-pci@vger.kernel.org,
	Greg KH <gregkh@suse.de>, LKML <linux-kernel@vger.kernel.org>,
	Linux-pm mailing list <linux-pm@lists.linux-foundation.org>
Subject: Re: [linux-pm] [RFC] PCI: Runtime power management
Date: Fri, 14 Aug 2009 13:30:59 +0100	[thread overview]
Message-ID: <20090814123059.GA27995@srcf.ucam.org> (raw)
In-Reply-To: <20090813214701.GC14532@srcf.ucam.org>

On Thu, Aug 13, 2009 at 10:47:01PM +0100, Matthew Garrett wrote:

> Ugh. I'd really prefer us to assume that drivers are able to cope unless 
> proven otherwise. Userspace policy makes sense where we don't have any 
> idea whether something will work or not, but I'd really expect that most 
> PCI drivers will either cope (in which case they'll have enabling code) 
> or won't (in which case they won't). Why would we want userspace to 
> influence this?

Though, thinking about it, you're right that setting this does override 
user policy. I think we need an additional flag to indicate that the 
device supports runtime wakeup and test that as well when doing 
device_may_wakeup().

> > This misses the point.  The whole idea of runtime_idle is to tell you 
> > that the device is idle and might be ready to be suspended.  If you're 
> > going to call pm_schedule_suspend anyway, there's no reason to invoke 
> > pm->runtime_idle.
> 
> My understanding of the API was that pm_device_put() invokes 
> runtime_idle if the refcount hits 0. The bus layer has no idea of the 
> refcount, and calling suspend directly from the driver would defeat the 
> point of the system-wide recounting.

>From the API docs:

"The action performed by a bus type's ->runtime_idle() callback is 
totally dependent on the bus type 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."

Though perhaps the device level runtime_idle shouldn't be void - that 
way the bus can ask the driver whether its suspend conditions have been 
satisfied? Right now there doesn't seem to be any way for the bus to ask 
that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  parent reply	other threads:[~2009-08-14 12:31 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-08 14:25 [PATCH] PM: Introduce core framework for run-time PM of I/O devices (rev. 14) Rafael J. Wysocki
2009-08-09 21:13 ` [PATCH update] PM: Introduce core framework for run-time PM of I/O devices (rev. 15) Rafael J. Wysocki
2009-08-09 21:13 ` Rafael J. Wysocki
2009-08-12 10:37   ` Magnus Damm
2009-08-12 15:47     ` Alan Stern
2009-08-12 15:47     ` Alan Stern
2009-08-12 20:13     ` Rafael J. Wysocki
2009-08-12 20:13     ` Rafael J. Wysocki
2009-08-12 10:37   ` Magnus Damm
2009-08-13  0:29   ` [RFC] PCI: Runtime power management Matthew Garrett
2009-08-13  0:29   ` Matthew Garrett
2009-08-13  0:35     ` [RFC] usb: Add support for runtime power management of the hcd Matthew Garrett
2009-08-13 12:16       ` Oliver Neukum
2009-08-13 12:16       ` [linux-pm] " Oliver Neukum
2009-08-13 12:30         ` Matthew Garrett
2009-08-13 12:30         ` [linux-pm] " Matthew Garrett
2009-08-13 14:26           ` Oliver Neukum
2009-08-13 14:26           ` [linux-pm] " Oliver Neukum
2009-08-13 21:42             ` Matthew Garrett
2009-08-13 21:42             ` Matthew Garrett
2009-08-13 15:22       ` Alan Stern
2009-08-13 15:22       ` Alan Stern
2009-08-13 21:47         ` Matthew Garrett
2009-08-13 21:47         ` Matthew Garrett
2009-08-13  0:35     ` Matthew Garrett
2009-08-13 15:17     ` [RFC] PCI: Runtime power management Alan Stern
2009-08-13 21:47       ` Matthew Garrett
2009-08-14 12:30         ` Matthew Garrett
2009-08-14 12:30         ` Matthew Garrett [this message]
2009-08-14 14:43           ` Alan Stern
2009-08-14 14:43           ` [linux-pm] " Alan Stern
2009-08-14 17:05             ` Rafael J. Wysocki
2009-08-14 17:05             ` [linux-pm] " Rafael J. Wysocki
2009-08-14 17:13               ` Rafael J. Wysocki
2009-08-14 17:13               ` [linux-pm] " Rafael J. Wysocki
2009-08-14 19:01                 ` Alan Stern
2009-08-14 19:01                 ` Alan Stern
2009-08-14 20:05             ` [linux-pm] " Rafael J. Wysocki
2009-08-14 22:21               ` Matthew Garrett
2009-08-15 14:18                 ` Rafael J. Wysocki
2009-08-15 14:18                 ` [linux-pm] " Rafael J. Wysocki
2009-08-15 15:53                   ` Alan Stern
2009-08-15 15:53                   ` [linux-pm] " Alan Stern
2009-08-15 20:54                     ` Rafael J. Wysocki
2009-08-15 20:54                     ` [linux-pm] " Rafael J. Wysocki
2009-08-15 20:58                       ` Matthew Garrett
2009-08-15 20:58                       ` [linux-pm] " Matthew Garrett
2009-08-15 21:21                         ` Rafael J. Wysocki
2009-08-15 21:21                           ` Rafael J. Wysocki
2009-08-15 21:27                           ` [linux-pm] " Matthew Garrett
2009-08-15 21:44                             ` Rafael J. Wysocki
2009-08-15 21:44                             ` [linux-pm] " Rafael J. Wysocki
2009-08-16 16:09                               ` Alan Stern
2009-08-16 16:09                               ` Alan Stern
2009-08-15 21:27                           ` Matthew Garrett
2009-08-16 15:57                           ` Alan Stern
2009-08-16 15:57                           ` [linux-pm] " Alan Stern
2009-08-16 16:04                             ` Matthew Garrett
2009-08-16 16:04                             ` [linux-pm] " Matthew Garrett
2009-08-16 15:50                       ` Alan Stern
2009-08-16 15:50                       ` [linux-pm] " Alan Stern
2009-08-14 22:21               ` Matthew Garrett
2009-08-14 20:05             ` Rafael J. Wysocki
2009-08-13 21:47       ` Matthew Garrett
2009-08-13 15:17     ` Alan Stern
2009-08-14 17:37     ` Jesse Barnes
2009-08-14 17:37     ` Jesse Barnes
2009-08-14 19:15       ` Rafael J. Wysocki
2009-08-14 19:15       ` Rafael J. Wysocki
2009-08-14 21:22     ` Rafael J. Wysocki
2009-08-14 22:30       ` Matthew Garrett
2009-08-14 22:30       ` Matthew Garrett
2009-08-15 14:41         ` Rafael J. Wysocki
2009-08-15 15:24           ` Rafael J. Wysocki
2009-08-15 15:24           ` Rafael J. Wysocki
2009-08-15 14:41         ` Rafael J. Wysocki
2009-08-14 21:22     ` Rafael J. Wysocki
2009-08-13 20:56   ` [PATCH update 2x] PM: Introduce core framework for run-time PM of I/O devices (rev. 16) Rafael J. Wysocki
2009-08-13 21:03     ` Paul Mundt
2009-08-13 21:03     ` Paul Mundt
2009-08-13 21:14       ` Rafael J. Wysocki
2009-08-13 21:14       ` Rafael J. Wysocki
2009-08-14  9:08     ` Magnus Damm
2009-08-14 17:19       ` Rafael J. Wysocki
2009-08-14 17:19       ` Rafael J. Wysocki
2009-08-14  9:08     ` Magnus Damm
2009-08-14 17:25     ` [PATCH update 3x] PM: Introduce core framework for run-time PM of I/O devices (rev. 17) Rafael J. Wysocki
2009-08-14 17:25     ` Rafael J. Wysocki
2009-08-13 20:56   ` [PATCH update 2x] PM: Introduce core framework for run-time PM of I/O devices (rev. 16) 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=20090814123059.GA27995@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=linux-usb@vger.kernel.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 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.