From: Alan Stern <stern@rowland.harvard.edu> To: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Oliver Neukum <oliver@neukum.org>, linux-pm@lists.linux-foundation.org, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [linux-pm] Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Mon, 8 Jun 2009 22:49:21 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.0906082233490.19072-100000@netrider.rowland.org> (raw) In-Reply-To: <200906082331.58933.rjw@sisk.pl> On Mon, 8 Jun 2009, Rafael J. Wysocki wrote: > > Use of the RPM_UNKNOWN state isn't good. A bus may have valid reasons > > of its own for not carrying out an autosuspend. When this happens the > > device's state isn't unknown. > > I'm not sure what you mean exactly. > > If ->autosuspend() fails, the device power state may be known, but the core > can't be sure if the device is active. This information is available to the > driver and/or the bus type, which should change the status to whatever is > appropriate. But no matter what the driver or bus type sets the state to, your pm_autosuspend() will change it to one of RPM_UNKNOWN or RPM_SUSPENDED. Neither might be right. > The name of this constant may be confusing, but I didn't have any better ideas. It's not clear what RPM_ACTIVE, RPM_IDLE, and RPM_SUSPENDED are supposed to mean; this should be documented in the code. Also, why isn't there RPM_RESUMING? By the way, a legitimate reason for aborting an autosuspend is if the device's driver requires remote wakeup to be enabled during suspend but the user has disabled it. > > The scheme doesn't include any mechanism for communicating runtime > > power information up the device tree. When a device is autosuspended, > > its parent's driver should be told so that the driver can consider > > autosuspending the parent. > > I thought the bus type's ->autosuspend() callback could take care of this. Shouldn't this happen after the device's state has changed to RPM_SUSPENDED? That's not until after the callback returns. > > There should be a sysfs interface (like the one in USB) to allow > > userspace to prevent a device from being autosuspended -- and perhaps > > also to force it to be suspended. > > To prevent a device from being suspended - yes. To force it to stay suspended > - I'm not sure. I'm not sure either. Oliver Neukum requested it originally and it has been useful for debugging, but I haven't seen many places where it would come in useful in practice. > > What about devices that have more than two runtime power states? For > > example, you can't squeeze PCI's {D0,D1,D2,D3hot} range into {running, > > suspended}. > > That has to be bus type-specific. > > In the case of PCI all of the low power states (D1-D3) are in fact substates of > "suspended", because we generally need to quiesce the device before putting > it into any of these states. > > I'm not sure if we can introduce more "levels of suspension", so to speak, at > the core level, but in any case we can easily distinguish between "device > quiesced and in a low power state" and "device fully active". > > So, in this picture the device is "suspended" from the core's point of view > once it's bus type's ->autosuspend() callback has been successfully executed. This too should be documented in the code. Or in a Documentation file. Alan Stern
WARNING: multiple messages have this Message-ID (diff)
From: Alan Stern <stern@rowland.harvard.edu> To: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Oliver Neukum <oliver@neukum.org>, <linux-pm@lists.linux-foundation.org>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [linux-pm] Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Mon, 8 Jun 2009 22:49:21 -0400 (EDT) [thread overview] Message-ID: <Pine.LNX.4.44L0.0906082233490.19072-100000@netrider.rowland.org> (raw) In-Reply-To: <200906082331.58933.rjw@sisk.pl> On Mon, 8 Jun 2009, Rafael J. Wysocki wrote: > > Use of the RPM_UNKNOWN state isn't good. A bus may have valid reasons > > of its own for not carrying out an autosuspend. When this happens the > > device's state isn't unknown. > > I'm not sure what you mean exactly. > > If ->autosuspend() fails, the device power state may be known, but the core > can't be sure if the device is active. This information is available to the > driver and/or the bus type, which should change the status to whatever is > appropriate. But no matter what the driver or bus type sets the state to, your pm_autosuspend() will change it to one of RPM_UNKNOWN or RPM_SUSPENDED. Neither might be right. > The name of this constant may be confusing, but I didn't have any better ideas. It's not clear what RPM_ACTIVE, RPM_IDLE, and RPM_SUSPENDED are supposed to mean; this should be documented in the code. Also, why isn't there RPM_RESUMING? By the way, a legitimate reason for aborting an autosuspend is if the device's driver requires remote wakeup to be enabled during suspend but the user has disabled it. > > The scheme doesn't include any mechanism for communicating runtime > > power information up the device tree. When a device is autosuspended, > > its parent's driver should be told so that the driver can consider > > autosuspending the parent. > > I thought the bus type's ->autosuspend() callback could take care of this. Shouldn't this happen after the device's state has changed to RPM_SUSPENDED? That's not until after the callback returns. > > There should be a sysfs interface (like the one in USB) to allow > > userspace to prevent a device from being autosuspended -- and perhaps > > also to force it to be suspended. > > To prevent a device from being suspended - yes. To force it to stay suspended > - I'm not sure. I'm not sure either. Oliver Neukum requested it originally and it has been useful for debugging, but I haven't seen many places where it would come in useful in practice. > > What about devices that have more than two runtime power states? For > > example, you can't squeeze PCI's {D0,D1,D2,D3hot} range into {running, > > suspended}. > > That has to be bus type-specific. > > In the case of PCI all of the low power states (D1-D3) are in fact substates of > "suspended", because we generally need to quiesce the device before putting > it into any of these states. > > I'm not sure if we can introduce more "levels of suspension", so to speak, at > the core level, but in any case we can easily distinguish between "device > quiesced and in a low power state" and "device fully active". > > So, in this picture the device is "suspended" from the core's point of view > once it's bus type's ->autosuspend() callback has been successfully executed. This too should be documented in the code. Or in a Documentation file. Alan Stern
next prev parent reply other threads:[~2009-06-09 2:49 UTC|newest] Thread overview: 199+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-06-06 22:54 [RFC][PATCH 0/2] PM: Rearrange core suspend code Rafael J. Wysocki 2009-06-06 22:55 ` [RFC][PATCH 1/2] PM: Separate suspend to RAM functionality from core Rafael J. Wysocki 2009-06-06 22:55 ` Rafael J. Wysocki 2009-06-08 6:36 ` Pavel Machek 2009-06-08 6:36 ` Pavel Machek 2009-06-06 22:56 ` [RFC][PATCH 2/2] PM/Hibernate: Rename disk.c to hibernate.c Rafael J. Wysocki 2009-06-06 22:56 ` Rafael J. Wysocki 2009-06-08 6:37 ` Pavel Machek 2009-06-08 6:37 ` Pavel Machek 2009-06-07 20:51 ` [RFC][PATCH 0/2] PM: Rearrange core suspend code Alan Stern 2009-06-07 20:51 ` [linux-pm] " Alan Stern 2009-06-07 21:46 ` Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Rafael J. Wysocki 2009-06-07 21:46 ` Run-time PM idea (was: Re: [linux-pm] " Rafael J. Wysocki 2009-06-07 22:02 ` Run-time PM idea (was: " Oliver Neukum 2009-06-07 22:02 ` Run-time PM idea (was: Re: [linux-pm] " Oliver Neukum 2009-06-07 22:02 ` Oliver Neukum 2009-06-07 22:05 ` Run-time PM idea (was: " Oliver Neukum 2009-06-07 22:05 ` [linux-pm] " Oliver Neukum 2009-06-08 11:29 ` Rafael J. Wysocki 2009-06-08 11:29 ` [linux-pm] " Rafael J. Wysocki 2009-06-08 12:04 ` Oliver Neukum 2009-06-08 18:34 ` Rafael J. Wysocki 2009-06-09 7:25 ` Oliver Neukum 2009-06-09 7:25 ` [linux-pm] " Oliver Neukum 2009-06-09 14:33 ` Alan Stern 2009-06-09 14:33 ` [linux-pm] " Alan Stern 2009-06-09 14:33 ` Alan Stern 2009-06-09 14:48 ` Oliver Neukum 2009-06-09 14:48 ` Oliver Neukum 2009-06-09 14:48 ` Oliver Neukum 2009-06-09 22:44 ` [linux-pm] " Rafael J. Wysocki 2009-06-09 22:44 ` Rafael J. Wysocki 2009-06-08 18:34 ` Rafael J. Wysocki 2009-06-08 12:04 ` Oliver Neukum 2009-06-08 20:35 ` Alan Stern 2009-06-08 20:35 ` [linux-pm] " Alan Stern 2009-06-08 20:35 ` Alan Stern 2009-06-08 21:31 ` Rafael J. Wysocki 2009-06-09 2:49 ` Alan Stern [this message] 2009-06-09 2:49 ` Alan Stern 2009-06-09 22:57 ` Rafael J. Wysocki 2009-06-10 8:29 ` [patch update] " Rafael J. Wysocki 2009-06-10 8:29 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-10 14:20 ` [patch update] " Oliver Neukum 2009-06-10 14:20 ` [patch update] Re: [linux-pm] " Oliver Neukum 2009-06-10 19:27 ` Rafael J. Wysocki 2009-06-10 21:38 ` Oliver Neukum 2009-06-10 21:38 ` Oliver Neukum 2009-06-10 22:01 ` [patch update] " Rafael J. Wysocki 2009-06-10 22:01 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-10 23:07 ` Oliver Neukum 2009-06-10 23:07 ` Oliver Neukum 2009-06-10 23:42 ` [patch update] " Alan Stern 2009-06-10 23:42 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-10 23:42 ` Alan Stern 2009-06-11 13:48 ` Rafael J. Wysocki 2009-06-11 13:57 ` [patch update] " Oliver Neukum 2009-06-11 13:57 ` [patch update] Re: [linux-pm] " Oliver Neukum 2009-06-11 14:16 ` [patch update] " Alan Stern 2009-06-11 14:16 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-11 14:16 ` Alan Stern 2009-06-11 19:38 ` [patch update] " Rafael J. Wysocki 2009-06-11 19:38 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-11 13:48 ` [patch update] " Rafael J. Wysocki 2009-06-11 13:46 ` Rafael J. Wysocki 2009-06-11 13:46 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-10 23:07 ` [patch update] " Oliver Neukum 2009-06-10 21:38 ` Oliver Neukum 2009-06-10 19:27 ` Rafael J. Wysocki 2009-06-10 21:14 ` Alan Stern 2009-06-10 21:14 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-10 21:31 ` [patch update] " Rafael J. Wysocki 2009-06-10 21:31 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-10 23:15 ` [patch update] " Oliver Neukum 2009-06-10 23:15 ` [patch update] Re: [linux-pm] " Oliver Neukum 2009-06-10 23:15 ` Oliver Neukum 2009-06-11 5:27 ` [patch update] " Magnus Damm 2009-06-11 5:27 ` [patch update] Re: [linux-pm] " Magnus Damm 2009-06-11 5:27 ` Magnus Damm 2009-06-10 23:42 ` Alan Stern 2009-06-11 14:17 ` [patch update] " Rafael J. Wysocki 2009-06-11 14:17 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-11 14:52 ` [patch update] " Alan Stern 2009-06-11 14:52 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-11 15:06 ` Oliver Neukum 2009-06-11 15:06 ` Oliver Neukum 2009-06-11 15:22 ` Alan Stern 2009-06-11 15:22 ` Alan Stern 2009-06-11 16:05 ` Oliver Neukum 2009-06-11 16:05 ` Oliver Neukum 2009-06-11 18:36 ` [patch update] " Alan Stern 2009-06-11 18:36 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-11 18:36 ` Alan Stern 2009-06-11 21:05 ` [patch update] " Oliver Neukum 2009-06-11 21:05 ` [patch update] Re: [linux-pm] " Oliver Neukum 2009-06-11 21:05 ` Oliver Neukum 2009-06-12 2:16 ` Alan Stern 2009-06-12 2:16 ` Alan Stern 2009-06-12 8:15 ` Oliver Neukum 2009-06-12 14:32 ` [patch update] " Alan Stern 2009-06-12 14:32 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-12 14:32 ` Alan Stern 2009-06-12 19:09 ` [patch update] " Rafael J. Wysocki 2009-06-12 19:09 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-12 19:48 ` Alan Stern 2009-06-12 19:56 ` [patch update] " Rafael J. Wysocki 2009-06-12 19:56 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-12 21:23 ` Alan Stern 2009-06-12 23:06 ` [patch update] " Rafael J. Wysocki 2009-06-12 23:06 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-13 18:08 ` [patch update] " Alan Stern 2009-06-13 18:08 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-13 22:04 ` [patch update] " Rafael J. Wysocki 2009-06-13 22:04 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-12 21:23 ` [patch update] " Alan Stern 2009-06-12 19:48 ` Alan Stern 2009-06-12 8:15 ` Oliver Neukum 2009-06-12 2:16 ` Alan Stern 2009-06-11 16:05 ` Oliver Neukum 2009-06-11 15:22 ` Alan Stern 2009-06-11 15:06 ` Oliver Neukum 2009-06-11 19:43 ` Rafael J. Wysocki 2009-06-11 19:43 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-12 14:25 ` [patch update] " Alan Stern 2009-06-12 14:25 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-10 23:42 ` [patch update] " Alan Stern 2009-06-11 5:18 ` [patch update] Re: [linux-pm] " Magnus Damm 2009-06-11 5:18 ` Magnus Damm 2009-06-11 9:08 ` Oliver Neukum 2009-06-12 3:13 ` [patch update] " Magnus Damm 2009-06-12 3:13 ` [patch update] Re: [linux-pm] " Magnus Damm 2009-06-12 8:11 ` Oliver Neukum 2009-06-12 10:54 ` [patch update] " Magnus Damm 2009-06-12 10:54 ` [patch update] Re: [linux-pm] " Magnus Damm 2009-06-12 10:54 ` Magnus Damm 2009-06-12 8:11 ` [patch update] " Oliver Neukum 2009-06-11 9:08 ` Oliver Neukum 2009-06-11 5:18 ` Magnus Damm 2009-06-10 20:48 ` [linux-pm] " Alan Stern 2009-06-10 20:48 ` Alan Stern 2009-06-10 21:15 ` Rafael J. Wysocki 2009-06-10 21:15 ` [linux-pm] " Rafael J. Wysocki 2009-06-10 20:48 ` Alan Stern 2009-06-09 22:57 ` Rafael J. Wysocki 2009-06-09 2:49 ` Alan Stern 2009-06-09 7:31 ` [linux-pm] " Oliver Neukum 2009-06-09 7:31 ` Oliver Neukum 2009-06-09 23:02 ` Rafael J. Wysocki 2009-06-09 23:02 ` [linux-pm] " Rafael J. Wysocki 2009-06-09 7:31 ` Oliver Neukum 2009-06-08 21:31 ` Rafael J. Wysocki 2009-06-08 6:54 ` Ingo Molnar 2009-06-08 6:54 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 11:30 ` Rafael J. Wysocki 2009-06-08 13:05 ` Ingo Molnar 2009-06-08 13:11 ` Matthew Garrett 2009-06-08 13:22 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 13:22 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 13:32 ` Matthew Garrett 2009-06-08 13:46 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 13:46 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 13:54 ` Run-time PM idea (was: " Matthew Garrett 2009-06-08 13:54 ` Run-time PM idea (was: Re: [linux-pm] " Matthew Garrett 2009-06-08 14:24 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 14:24 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 14:35 ` Run-time PM idea (was: " Matthew Garrett 2009-06-08 14:35 ` Run-time PM idea (was: Re: [linux-pm] " Matthew Garrett 2009-06-08 14:44 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 14:44 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 14:51 ` Matthew Garrett 2009-06-24 15:03 ` Run-time PM idea (was: " Pavel Machek 2009-06-24 15:03 ` Run-time PM idea (was: Re: [linux-pm] " Pavel Machek 2009-06-08 14:51 ` Run-time PM idea (was: " Matthew Garrett 2009-06-19 1:50 ` Robert Hancock 2009-06-19 1:50 ` Robert Hancock 2009-06-08 13:58 ` Oliver Neukum 2009-06-08 13:58 ` Run-time PM idea (was: Re: [linux-pm] " Oliver Neukum 2009-06-08 13:58 ` Oliver Neukum 2009-06-08 13:32 ` Run-time PM idea (was: " Matthew Garrett 2009-06-08 13:39 ` Oliver Neukum 2009-06-08 13:39 ` Run-time PM idea (was: Re: [linux-pm] " Oliver Neukum 2009-06-08 13:44 ` Run-time PM idea (was: " Matthew Garrett 2009-06-08 13:44 ` Run-time PM idea (was: Re: [linux-pm] " Matthew Garrett 2009-06-08 14:21 ` Ingo Molnar 2009-06-08 14:30 ` Matthew Garrett 2009-06-08 15:06 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 15:06 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 15:11 ` Matthew Garrett 2009-06-08 15:11 ` Run-time PM idea (was: " Matthew Garrett 2009-06-08 16:29 ` Ray Lee 2009-06-08 16:29 ` Run-time PM idea (was: Re: [linux-pm] " Ray Lee 2009-06-08 16:29 ` Ray Lee 2009-06-08 14:30 ` Run-time PM idea (was: " Matthew Garrett 2009-06-09 22:44 ` Jiri Kosina 2009-06-09 22:44 ` Run-time PM idea (was: Re: [linux-pm] " Jiri Kosina 2009-06-08 14:21 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 13:11 ` Matthew Garrett 2009-06-08 13:05 ` Ingo Molnar 2009-06-08 11:30 ` 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=Pine.LNX.4.44L0.0906082233490.19072-100000@netrider.rowland.org \ --to=stern@rowland.harvard.edu \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@lists.linux-foundation.org \ --cc=oliver@neukum.org \ --cc=rjw@sisk.pl \ /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: linkBe 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.