Suspend block api (version 6)
in [Kernel]
|
Prev: mm: fix race between shift_arg_pages and rmap_walk
Next: [PATCH -next] power: fix block_io.c printk warning
From: Mark Brown on 7 May 2010 10:10 On Fri, May 07, 2010 at 04:41:02AM -0700, Arve Hj�nnev�g wrote: > 2010/5/7 Mark Brown <broonie(a)opensource.wolfsonmicro.com>: > > This goes back to the thing about a full system suspend being a > > sledgehammer which doesn't give enough information about what's going > > on when it's used like this. �As discussed we need a way to know that > > the connections involved are able to stay live during suspend (on a > > large proportion of systems suspend is going to mean that the relevant > > bits of the board will loose power so need to be shut down) and that > Are you trying to use the same driver on systems that can support > audio while suspend and on systems where this is impossible? If audio Yes, each chip in the audio subsystem gets its own device driver. All Linux systems using a given CODEC share the device specific driver code (modulo out of tree code, obviously). Further, the power management is mostly abstracted out of the individual device drivers into the embedded audio core so the individual drivers don't really take any decisions about power for themselves. > cannot work while suspended, supporting opportunistic suspend is easy. > You block suspend while audio is active. Right, but that's not really an interesting case here. > If the hardware does support some audio paths while suspended, I'll > ask again, is there a reason to turn them off on suspend? As the mail you're replying to says: > > that the intention of the user is that they should do so (this isn't > > clear in the general system, especially not if the suspend is initiated > > manually). this all comes down to the intention of the user when they initiated the suspend. > > With a runtime PM approach this is trivial - we just turn off anything > > that isn't in use at the current time. �I'll need to extend ASoC to add > > information about what to do on suspend to the existing power data. > OK, but is this at all related to opportunistic suspend? Well, opportunistic suspend is essentially blurring the lines between a suspend and runtime PM - it's using suspend as part of the automatic drive down into the lowest possible power state. I'm just saying that in a pure runtime PM model this issue doesn't come up since the suspend semantic is much clearer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kevin Hilman on 10 May 2010 14:10 Hello, I think many folks are still confused about exactly the problem being solved by this series as well as mixed up between opportunistic suspend and suspend blockers. Also, how this series impatcs the rest of the kernel (especially PM-aware drivers and subsystems) has caused a bit of confusion. To help with the confusion, I think a much clearer description of the problem being solved and the proposed solution is needed. To that end, I created a starting point for that below which summarizes how I understand the problem and the proposed solution, but of course this should be filled out in more detail and updated as part of the documentation that goes with this series. Hope this helps improve the understanding of this feature, Kevin Table of Contents ================= 1 Problem Statement 2 Solution: Opportunistic suspend 2.1 When to use a suspend blocker 2.2 Usage in PM aware drivers 1 Problem Statement ~~~~~~~~~~~~~~~~~~~~ Want to to hit deep power state, even when the system is not actually idle. Why? - some hardware is not capable of deep power states in idle - difficulty getting userspace and/or kernel to be idle 2 Solution: Opportunistic suspend ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Create an additional "idle path" which has new rules for determining idleness. When this new "idle" is reached, trigger full-system suspend. Since a suspend is triggered whenever the opportunity arises, this is called opportunistic suspend. The new rules for making the idleness decision are simple: 1. system may suspend if and only if no suspend blockers are held 2.1 When to use a suspend blocker ================================== [A list of reasons why suspend blockers might be used would be very helpful here.] - ensure wakeup events propagate to userspace (e.g. keypad example in doc) - screen is on - someone mentioned "Google use cases" (would be nice to hear about more of these) 2.2 Usage in PM aware drivers ============================== [An example of how a driver already using runtime PM would use a suspend blocker would also be helpful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 10 May 2010 16:30 On Monday 10 May 2010, Kevin Hilman wrote: > Hello, Hi Kevin, > I think many folks are still confused about exactly the problem being > solved by this series as well as mixed up between opportunistic > suspend and suspend blockers. Also, how this series impatcs the rest > of the kernel (especially PM-aware drivers and subsystems) has caused > a bit of confusion. > > To help with the confusion, I think a much clearer description of the > problem being solved and the proposed solution is needed. > > To that end, I created a starting point for that below which > summarizes how I understand the problem and the proposed solution, but > of course this should be filled out in more detail and updated as part > of the documentation that goes with this series. > > Hope this helps improve the understanding of this feature, Yes, I think this is helpful. > Table of Contents > ================= > 1 Problem Statement > 2 Solution: Opportunistic suspend > 2.1 When to use a suspend blocker > 2.2 Usage in PM aware drivers > > > 1 Problem Statement > ~~~~~~~~~~~~~~~~~~~~ > > Want to to hit deep power state, even when the system is not actually > idle. > > Why? > > - some hardware is not capable of deep power states in idle > - difficulty getting userspace and/or kernel to be idle > > 2 Solution: Opportunistic suspend > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Create an additional "idle path" which has new rules for determining > idleness. When this new "idle" is reached, trigger full-system > suspend. Since a suspend is triggered whenever the opportunity > arises, this is called opportunistic suspend. > > The new rules for making the idleness decision are simple: > > 1. system may suspend if and only if no suspend blockers are held > > 2.1 When to use a suspend blocker > ================================== > > [A list of reasons why suspend blockers might be used would be very > helpful here.] > > - ensure wakeup events propagate to userspace (e.g. keypad example in doc) > > - screen is on > > - someone mentioned "Google use cases" > (would be nice to hear about more of these) Yes, I think the Android developers know quite a few cases where suspend blockers are useful. > 2.2 Usage in PM aware drivers > ============================== > > [An example of how a driver already using runtime PM would use > a suspend blocker would also be helpful. When we have any drivers using both in the tree, they will be used as examples here. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 11 May 2010 12:20 On Tue, May 11, 2010 at 09:12:28AM -0700, Tony Lindgren wrote: > To me it sounds like this should only be allowed to happen when you do: > > # echo 1 > /sys/power/suspend_while_idle > > As it kills the timers and leads to non-standard behaviour of the apps > as they won't run :) > > And then the remaining question is how to make sure the use cases > below can be handled in a clean way. That's handled by the /sys/power/policy opportunistic/forced switch. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on 11 May 2010 12:20
* Rafael J. Wysocki <rjw(a)sisk.pl> [100510 13:27]: > On Monday 10 May 2010, Kevin Hilman wrote: > > Hello, > > Hi Kevin, > > > I think many folks are still confused about exactly the problem being > > solved by this series as well as mixed up between opportunistic > > suspend and suspend blockers. Also, how this series impatcs the rest > > of the kernel (especially PM-aware drivers and subsystems) has caused > > a bit of confusion. > > > > To help with the confusion, I think a much clearer description of the > > problem being solved and the proposed solution is needed. > > > > To that end, I created a starting point for that below which > > summarizes how I understand the problem and the proposed solution, but > > of course this should be filled out in more detail and updated as part > > of the documentation that goes with this series. > > > > Hope this helps improve the understanding of this feature, > > Yes, I think this is helpful. > > > Table of Contents > > ================= > > 1 Problem Statement > > 2 Solution: Opportunistic suspend > > 2.1 When to use a suspend blocker > > 2.2 Usage in PM aware drivers > > > > > > 1 Problem Statement > > ~~~~~~~~~~~~~~~~~~~~ > > > > Want to to hit deep power state, even when the system is not actually > > idle. > > > > Why? > > > > - some hardware is not capable of deep power states in idle > > - difficulty getting userspace and/or kernel to be idle > > > > 2 Solution: Opportunistic suspend > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Create an additional "idle path" which has new rules for determining > > idleness. When this new "idle" is reached, trigger full-system > > suspend. Since a suspend is triggered whenever the opportunity > > arises, this is called opportunistic suspend. I agree, this is is the right way to handle when to enter suspend. Especially if the system needs to run while waiting for something to happen before being able to suspend. > > The new rules for making the idleness decision are simple: > > > > 1. system may suspend if and only if no suspend blockers are held To me it sounds like this should only be allowed to happen when you do: # echo 1 > /sys/power/suspend_while_idle As it kills the timers and leads to non-standard behaviour of the apps as they won't run :) And then the remaining question is how to make sure the use cases below can be handled in a clean way. > > 2.1 When to use a suspend blocker > > ================================== > > > > [A list of reasons why suspend blockers might be used would be very > > helpful here.] > > > > - ensure wakeup events propagate to userspace (e.g. keypad example in doc) > > > > - screen is on > > > > - someone mentioned "Google use cases" > > (would be nice to hear about more of these) > > Yes, I think the Android developers know quite a few cases where suspend > blockers are useful. > > > 2.2 Usage in PM aware drivers > > ============================== > > > > [An example of how a driver already using runtime PM would use > > a suspend blocker would also be helpful. > > When we have any drivers using both in the tree, they will be used as examples > here. > > Thanks, > Rafael > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |