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 5 May 2010 19:50 On Wed, May 05, 2010 at 01:56:07PM -0700, Brian Swetland wrote: > From my point of view, the codec should be powered up while audio is > playing and powered down when it's not -- that's the approach I've This is what we've got already with Linux - we've had rather aggressive runtime PM for embedded audio as standard for years now. It's only very recently that mobile hardware has got to the point where you can actually totally kill the power without introducing problems but it's been getting pretty much as close as possible. > taken on MSM, regardless of suspend state. I don't view suspend as > something that stops audio playback in progress. Sort of similar to > how the modem doesn't power off down when the system is in suspend, > etc. This really does depend heavily on system design and the intended function of the suspend on the part of the initiator. In many systems suspend will remove sufficient power to stop audio running even if it were desired, and there's the idea with existing manually initiated suspends that the system should stop what it's doing and go into a low power, low responsiveness state. Some systems will initiate a suspend with active audio paths (especially those to or from the AP) which they expect to be stopped. > In effect, we have followed a sort of runtime pm model of > clocking/powering peripherals at the lowest possible level at all > times, which is why I've never viewed suspend_block as somehow > competing with runtime pm -- we always want all drivers/peripherals in Right, and this will work well on systems like your current devices because the problem hardware is not directly visible to the AP (the actual audio hardware is hidden behind the DSP which functions as autonomously as the modem does) so it's not affected by the Linux suspend process in the first place. It causes confusion when the power for the audio device is managed by Linux since the opportunistic suspend will include suspending the audio device and so the code handling the suspend then has to decide what exactly it's being asked to do. > the lowers power state. Sometimes the lowest power state possible is > higher than "full suspend" (for example when we can't meet latency > requirements on audio on 7201A) and suspend_blockers cover that case. In this situation there's no physical reason why the lower power state is not achievable so blocking the suspend would just waste power, it's just that our way of getting into it is creating some confusion. -- 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: Mark Brown on 5 May 2010 20:30 On Thu, May 06, 2010 at 01:33:59AM +0200, Rafael J. Wysocki wrote: > set up that way). Even without the patchset you may implement a power > manager in user space that will suspend the system whenever it thinks it's > idle. Clearly, but... > On Thursday 06 May 2010, Mark Brown wrote: > > In the primary existing application this change interoperates very poorly > > with at least the current audio subsystem since that handles suspend by > > ceasing all activity and powering as much as it can off, which is sensible for > > manual only suspends but highly undesirable for opportunistic suspend in > > phones. > You said that there's no fundamental difference between manual and > opportunistic suspend. It only matters what _you_ are going to use suspend > for. I agree that at the moment it's not suitable for aggressive power > management in phones because of the audio problem, but that applies to > "manual" as well as to "opportunistic" suspend. ....on the other hand there's exactly one existing application for this, and that's the one that's most likely to run into problems since it's a phone OS and aggressive power management is pretty important for phones. Merging a feature into mainline makes it much more something which one would expect to play nicely with the rest of the kernel - if it's something that isn't part of the standard kernel or userspaces it's much less surprising that additional changes may be required to produce a well integrated system. > You're saying that suspend is not suitable for one particular purpose in its > current form, which is entirely correct, but that doesn't imply that the > patchset is wrong. As I keep saying I agree that merging this is reasonable given the additional power savings it brings in practical systems today. As I also keep saying I do want to have some understanding about what the story is for dealing with the problems so that people can easily use this feature out of the box. Like I say, my current impression is that the best approach is for affected subsystems or drivers to implement a custom solution - does that match your understanding and that of the other PM maintainers? -- 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 5 May 2010 21:00 On Thursday 06 May 2010, Mark Brown wrote: > On Thu, May 06, 2010 at 01:33:59AM +0200, Rafael J. Wysocki wrote: > > > set up that way). Even without the patchset you may implement a power > > manager in user space that will suspend the system whenever it thinks it's > > idle. > > Clearly, but... > > > On Thursday 06 May 2010, Mark Brown wrote: > > > > In the primary existing application this change interoperates very poorly > > > with at least the current audio subsystem since that handles suspend by > > > ceasing all activity and powering as much as it can off, which is sensible for > > > manual only suspends but highly undesirable for opportunistic suspend in > > > phones. > > > You said that there's no fundamental difference between manual and > > opportunistic suspend. It only matters what _you_ are going to use suspend > > for. I agree that at the moment it's not suitable for aggressive power > > management in phones because of the audio problem, but that applies to > > "manual" as well as to "opportunistic" suspend. > > ...on the other hand there's exactly one existing application for this, > and that's the one that's most likely to run into problems since it's a > phone OS and aggressive power management is pretty important for phones. > > Merging a feature into mainline makes it much more something which one > would expect to play nicely with the rest of the kernel - if it's > something that isn't part of the standard kernel or userspaces it's much > less surprising that additional changes may be required to produce a > well integrated system. > > > You're saying that suspend is not suitable for one particular purpose in its > > current form, which is entirely correct, but that doesn't imply that the > > patchset is wrong. > > As I keep saying I agree that merging this is reasonable given the > additional power savings it brings in practical systems today. As I > also keep saying I do want to have some understanding about what the > story is for dealing with the problems so that people can easily use > this feature out of the box. > > Like I say, my current impression is that the best approach is for > affected subsystems or drivers to implement a custom solution - does > that match your understanding and that of the other PM maintainers? I agree that this appears to be the best approach for the time being, although I can only speak for myself. 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: Magnus Damm on 5 May 2010 21:50 On Wed, May 5, 2010 at 12:27 AM, Matthew Garrett <mjg(a)redhat.com> wrote: > On Tue, May 04, 2010 at 09:51:39AM -0400, Alan Stern wrote: > >> Another thing that Kevin is missing: There is more to the system than >> the devices and the CPU. �For example: RAM, an embedded controller (on >> modern desktop/laptop systems), a power supply, and so on. �Dynamic PM >> for the CPU and the devices won't power-down these things, but system >> PM will. > > Somewhat true - machines with C1E support will put the RAM into self > refresh when the cpu is idle, but you're right that there are various > components that we simply don't have control over in the desktop world > at present. As a contrast, at least on some embedded SoCs without firmware limitations the low level sleep code for Runtime PM / CPU Idle is shared with system wide suspend. So the RAM is put into self refresh regardless of entering a half-deep CPU Idle state or entering suspend-to-memory. I've heard that newer SH-Mobile ARM hardware monitors the memory bus activity behind the scenes and can put the system RAM into self refresh automatically. On older parts we had to manage that from CPU idle context. / magnus -- 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: Arve Hjønnevåg on 6 May 2010 00:30
On Wed, May 5, 2010 at 4:40 PM, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > On Wed, May 05, 2010 at 01:56:07PM -0700, Brian Swetland wrote: .... >> taken on MSM, regardless of suspend state. �I don't view suspend as >> something that stops audio playback in progress. �Sort of similar to >> how the modem doesn't power off down when the system is in suspend, >> etc. > > This really does depend heavily on system design and the intended > function of the suspend on the part of the initiator. �In many systems > suspend will remove sufficient power to stop audio running even if it > were desired, and there's the idea with existing manually initiated > suspends that the system should stop what it's doing and go into a low > power, low responsiveness state. �Some systems will initiate a suspend > with active audio paths (especially those to or from the AP) which they > expect to be stopped. > You can support both in the same driver in some cases (without a switch). If the hardware cannot wake the system when it needs more audio buffers, then the driver needs to block suspend while audio is playing. Since suspend blockers only block opportunistic suspend, the driver can also implement suspend to stop audio playback and it will only be called for forced suspend. -- Arve Hj�nnev�g -- 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/ |