From: Magnus Damm <magnus.damm@gmail.com> To: Oliver Neukum <oliver@neukum.org> Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>, 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: Fri, 12 Jun 2009 12:13:12 +0900 [thread overview] Message-ID: <aec7e5c30906112013q2d2827feh54192d518156f203@mail.gmail.com> (raw) In-Reply-To: <200906111108.40785.oliver@neukum.org> Hi Oliver, On Thu, Jun 11, 2009 at 6:08 PM, Oliver Neukum<oliver@neukum.org> wrote: > Am Donnerstag, 11. Juni 2009 07:18:46 schrieb Magnus Damm: >> 3) When all devices in the power domain are suspended the bus code can >> turn off the power. The reason why I'd like to only autosuspend when > > So you are saying that you have power dependencies independent > of the device tree? I can think of the following power dependencies: - hardware bus topology - clocks - power domains >> all devices are idle is simply that we don't get any power savings >> from the per device autosuspend() callbacks, only from turning off >> power to the entire per-domain. So bindly autosuspending and >> autoresuming devices is just pure overhead unless we know we can do it >> for all devices in the domain. > > Why can't you do this within the framework? You simply suspend when > all a domain's devices have been autosuspended. So you mean I should handle that in my arch/bus specific dev->bus->pm->autosuspend() code? So instead of calling dev->driver->pm->autosuspend() straight away I keep track of the use count of the power domain and when the domain is unused I call dev->driver->pm->autosuspend() for all devices in the power domain before powering off? I guess hooking in things in dev->bus->pm->autosuspend() is doable, but then dev->power.runtime_status will be set to RPM_SUSPENDED even though the actual device isn't suspended at all. And RPM_IDLE state will be more or less unused since the drivers should pass a delay of zero to make sure the bus code gets notified about the idle state straight away. Basically, for my use case it would make more sense to let the bus_type directly decide when a device should be suspended instead of using a timeout before calling the bus_type code. I rather let the bus_type decide if a timeout should be used or not instead of using it for all bus_types. So I guess the plan is that drivers directly should invoke pm_request_suspend() to notify the bus that they are idle? (I guess similar to my platform_device_idle()?) For my use case there is no point in having the delay in pm_request_suspend(), we want to notify the bus about the per-device idleness straight away. Using a delay in pm_request_suspend() before calling the bus type autosuspend will just keep the current per-device state away from the bus level and make sure we _cannot_ enter deep sleep states. Which I believe will result in worse battery life because we spend more time than necessary in not-so-deep sleep states. So yes, I'd like to do things in dev->bus->pm->autosuspend(), and the code is quite close. I can't figure out why anyone would want the suspend delay at the current level though, but I guess other busses want to use that? Thanks for your comments, / magnus
WARNING: multiple messages have this Message-ID (diff)
From: Magnus Damm <magnus.damm@gmail.com> To: Oliver Neukum <oliver@neukum.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Alan Stern <stern@rowland.harvard.edu>, 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: Fri, 12 Jun 2009 12:13:12 +0900 [thread overview] Message-ID: <aec7e5c30906112013q2d2827feh54192d518156f203@mail.gmail.com> (raw) In-Reply-To: <200906111108.40785.oliver@neukum.org> Hi Oliver, On Thu, Jun 11, 2009 at 6:08 PM, Oliver Neukum<oliver@neukum.org> wrote: > Am Donnerstag, 11. Juni 2009 07:18:46 schrieb Magnus Damm: >> 3) When all devices in the power domain are suspended the bus code can >> turn off the power. The reason why I'd like to only autosuspend when > > So you are saying that you have power dependencies independent > of the device tree? I can think of the following power dependencies: - hardware bus topology - clocks - power domains >> all devices are idle is simply that we don't get any power savings >> from the per device autosuspend() callbacks, only from turning off >> power to the entire per-domain. So bindly autosuspending and >> autoresuming devices is just pure overhead unless we know we can do it >> for all devices in the domain. > > Why can't you do this within the framework? You simply suspend when > all a domain's devices have been autosuspended. So you mean I should handle that in my arch/bus specific dev->bus->pm->autosuspend() code? So instead of calling dev->driver->pm->autosuspend() straight away I keep track of the use count of the power domain and when the domain is unused I call dev->driver->pm->autosuspend() for all devices in the power domain before powering off? I guess hooking in things in dev->bus->pm->autosuspend() is doable, but then dev->power.runtime_status will be set to RPM_SUSPENDED even though the actual device isn't suspended at all. And RPM_IDLE state will be more or less unused since the drivers should pass a delay of zero to make sure the bus code gets notified about the idle state straight away. Basically, for my use case it would make more sense to let the bus_type directly decide when a device should be suspended instead of using a timeout before calling the bus_type code. I rather let the bus_type decide if a timeout should be used or not instead of using it for all bus_types. So I guess the plan is that drivers directly should invoke pm_request_suspend() to notify the bus that they are idle? (I guess similar to my platform_device_idle()?) For my use case there is no point in having the delay in pm_request_suspend(), we want to notify the bus about the per-device idleness straight away. Using a delay in pm_request_suspend() before calling the bus type autosuspend will just keep the current per-device state away from the bus level and make sure we _cannot_ enter deep sleep states. Which I believe will result in worse battery life because we spend more time than necessary in not-so-deep sleep states. So yes, I'd like to do things in dev->bus->pm->autosuspend(), and the code is quite close. I can't figure out why anyone would want the suspend delay at the current level though, but I guess other busses want to use that? Thanks for your comments, / magnus
next prev parent reply other threads:[~2009-06-12 3:13 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 ` [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 ` Magnus Damm [this message] 2009-06-12 3:13 ` 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=aec7e5c30906112013q2d2827feh54192d518156f203@mail.gmail.com \ --to=magnus.damm@gmail.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@lists.linux-foundation.org \ --cc=oliver@neukum.org \ /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.