From: "Rafael J. Wysocki" <rjw@sisk.pl> To: Alan Stern <stern@rowland.harvard.edu> Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>, Linux-pm mailing list <linux-pm@lists.linux-foundation.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [patch update] Re: Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Thu, 11 Jun 2009 16:17:34 +0200 [thread overview] Message-ID: <200906111617.34635.rjw@sisk.pl> (raw) In-Reply-To: <Pine.LNX.4.44L0.0906101933220.29717-100000@netrider.rowland.org> On Thursday 11 June 2009, Alan Stern wrote: > On Wed, 10 Jun 2009, Rafael J. Wysocki wrote: > > > > You know, it doesn't make any sense to have a suspend and a resume > > > both pending at the same time. > > > > > > So you could add only a delayed_work structure and use its embedded > > > work_struct for resume requests. > > > > I thought so too, but I was wrong. ;-) > > > > If resume is requested while the suspend hasn't completed yet, we should > > queue it (it's totally valid to request a suspending device to resume IMO), but > > the delayed work is still being used by the workqueue code, so we can't modify > > it. > > Where is the delayed work still being used? There's even a comment in > run_workqueue() that says a work_struct can be freed by the function it > calls. You are right, I overlooked the comment and it wasn't clear to me from looking at the code. > > > We might want to do a runtime suspend even if the device's children > > > aren't already suspended. For example, you could suspend a link while > > > leaving the device on the other end of the link at full power -- > > > especially if powering down the device is slow but changing the link's > > > power level is fast. > > > > Well, this means that the dependencies between devices in the device tree are > > pretty much useless for the run-time PM as far as the core is concerned. In > > which case, why did you mention them at all? > > The dependencies aren't totally useless. It's still true that before > you resume a device, you have to autoresume its parent. Well, in fact if we don't have the requirement that the children of a device have to be suspended for it to be able to suspend too, we have to check all parents up the device tree up to the one that doesn't have a parent and autoresume the ones that aren't active. > And it's still true that when you suspend a device, the parent should be > given a chance to autosuspend. > > I guess the real point is that the decision about whether all children > must be suspended should be made by the driver, not the PM core. The point here is what the core is supposed to do. Does it need to handle this at all or leave it to the bus type and driver? After reconsidering it for a while I think that we should define what "suspended" is supposed to mean from the core point of view. And my opinion is that it should mean "device doesn't communicate with the CPUs and RAM due to power management". That need not be power management of the device itself, but such that leads to the device not doing I/O. Under this definition all devices behind an inactive link are suspended, because they can't do any I/O. Which appears to makes sense, because their drivers have to be notified before the link is suspended and the link has to be turned on for the devices to be able to communicate with the CPU and RAM. If this definition is adopted, then it's quite clear that the device can only be suspended if all of its children are suspended and it's always necessary to resume the parent of a device in order to resume the device itself. > > > I haven't checked the details of the code yet. More later... > > One more thought... The autosuspend and autoresume callbacks need to > be mutually exclusive with probe and remove. So somehow the driver > core will need to block runtime PM calls. That's correct and I'm going to take care of this. > It might also be nice to make sure that the driver core autoresumes a > device before probing it and autosuspends a device (after some > reasonable delay) after unbinding its driver. Agreed. Best, Rafael
WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@sisk.pl> To: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oliver@neukum.org>, "Linux-pm mailing list" <linux-pm@lists.linux-foundation.org>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [patch update] Re: [linux-pm] Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Thu, 11 Jun 2009 16:17:34 +0200 [thread overview] Message-ID: <200906111617.34635.rjw@sisk.pl> (raw) In-Reply-To: <Pine.LNX.4.44L0.0906101933220.29717-100000@netrider.rowland.org> On Thursday 11 June 2009, Alan Stern wrote: > On Wed, 10 Jun 2009, Rafael J. Wysocki wrote: > > > > You know, it doesn't make any sense to have a suspend and a resume > > > both pending at the same time. > > > > > > So you could add only a delayed_work structure and use its embedded > > > work_struct for resume requests. > > > > I thought so too, but I was wrong. ;-) > > > > If resume is requested while the suspend hasn't completed yet, we should > > queue it (it's totally valid to request a suspending device to resume IMO), but > > the delayed work is still being used by the workqueue code, so we can't modify > > it. > > Where is the delayed work still being used? There's even a comment in > run_workqueue() that says a work_struct can be freed by the function it > calls. You are right, I overlooked the comment and it wasn't clear to me from looking at the code. > > > We might want to do a runtime suspend even if the device's children > > > aren't already suspended. For example, you could suspend a link while > > > leaving the device on the other end of the link at full power -- > > > especially if powering down the device is slow but changing the link's > > > power level is fast. > > > > Well, this means that the dependencies between devices in the device tree are > > pretty much useless for the run-time PM as far as the core is concerned. In > > which case, why did you mention them at all? > > The dependencies aren't totally useless. It's still true that before > you resume a device, you have to autoresume its parent. Well, in fact if we don't have the requirement that the children of a device have to be suspended for it to be able to suspend too, we have to check all parents up the device tree up to the one that doesn't have a parent and autoresume the ones that aren't active. > And it's still true that when you suspend a device, the parent should be > given a chance to autosuspend. > > I guess the real point is that the decision about whether all children > must be suspended should be made by the driver, not the PM core. The point here is what the core is supposed to do. Does it need to handle this at all or leave it to the bus type and driver? After reconsidering it for a while I think that we should define what "suspended" is supposed to mean from the core point of view. And my opinion is that it should mean "device doesn't communicate with the CPUs and RAM due to power management". That need not be power management of the device itself, but such that leads to the device not doing I/O. Under this definition all devices behind an inactive link are suspended, because they can't do any I/O. Which appears to makes sense, because their drivers have to be notified before the link is suspended and the link has to be turned on for the devices to be able to communicate with the CPU and RAM. If this definition is adopted, then it's quite clear that the device can only be suspended if all of its children are suspended and it's always necessary to resume the parent of a device in order to resume the device itself. > > > I haven't checked the details of the code yet. More later... > > One more thought... The autosuspend and autoresume callbacks need to > be mutually exclusive with probe and remove. So somehow the driver > core will need to block runtime PM calls. That's correct and I'm going to take care of this. > It might also be nice to make sure that the driver core autoresumes a > device before probing it and autosuspends a device (after some > reasonable delay) after unbinding its driver. Agreed. Best, Rafael
next prev parent reply other threads:[~2009-06-11 14:17 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 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 ` Rafael J. Wysocki [this message] 2009-06-11 14:17 ` 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=200906111617.34635.rjw@sisk.pl \ --to=rjw@sisk.pl \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@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: 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.