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: Matthew Garrett on 11 May 2010 13:40 On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote: > For the failed suspend path in the kernel, currently the kernel would > unwind back all the drivers because of the failed driver, but that path > should be possible to optimize. If you think it's possible to make this work then feel free to. But at the point where you're adding code to every driver's suspend function to determine whether or not it's got any pending events that userspace hasn't consumed yet, and adding code to every bit of userspace to allow it to indicate whether or not it's busy consuming events or just busy drawing 3D bouncing cattle, I think you've reinvented suspend blocks. -- 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 13:50 * Matthew Garrett <mjg(a)redhat.com> [100511 10:25]: > On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote: > > > For the failed suspend path in the kernel, currently the kernel would > > unwind back all the drivers because of the failed driver, but that path > > should be possible to optimize. > > If you think it's possible to make this work then feel free to. But at > the point where you're adding code to every driver's suspend function to > determine whether or not it's got any pending events that userspace > hasn't consumed yet, and adding code to every bit of userspace to allow > it to indicate whether or not it's busy consuming events or just busy > drawing 3D bouncing cattle, I think you've reinvented suspend blocks. Sorry, I have a working system that idles nicely and stays up on batteries for a long time while running. I don't need to implement anything like this :) Cheers, Tony -- 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 14:10 On Tue, May 11, 2010 at 10:48:58AM -0700, Tony Lindgren wrote: > * Matthew Garrett <mjg(a)redhat.com> [100511 10:25]: > > On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote: > > > > > For the failed suspend path in the kernel, currently the kernel would > > > unwind back all the drivers because of the failed driver, but that path > > > should be possible to optimize. > > > > If you think it's possible to make this work then feel free to. But at > > the point where you're adding code to every driver's suspend function to > > determine whether or not it's got any pending events that userspace > > hasn't consumed yet, and adding code to every bit of userspace to allow > > it to indicate whether or not it's busy consuming events or just busy > > drawing 3D bouncing cattle, I think you've reinvented suspend blocks. > > Sorry, I have a working system that idles nicely and stays up on > batteries for a long time while running. I don't need to implement > anything like this :) Right, but your system will only idle nicely if all of your userspace is well-written. It's not reasonable to expect that all userspace will be well-written and thus it's necessary to implement a power management strategy that doesn't require that. Refusing an implementation that achieves that on the basis that there's hypothetically a better way of doing it is entirely unreasonable. -- 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: Rafael J. Wysocki on 11 May 2010 14:20 On Tuesday 11 May 2010, Matthew Garrett wrote: > On Tue, May 11, 2010 at 10:24:43AM -0700, Tony Lindgren wrote: > > > For the failed suspend path in the kernel, currently the kernel would > > unwind back all the drivers because of the failed driver, but that path > > should be possible to optimize. > > If you think it's possible to make this work then feel free to. But at > the point where you're adding code to every driver's suspend function to > determine whether or not it's got any pending events that userspace > hasn't consumed yet, and adding code to every bit of userspace to allow > it to indicate whether or not it's busy consuming events or just busy > drawing 3D bouncing cattle, I think you've reinvented suspend blocks. Yeah, pretty much so. 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: Mark Brown on 11 May 2010 14:50
On Fri, May 07, 2010 at 02:30:25PM +0100, Mark Brown wrote: > I mean that I will extend the embedded audio subsystem that the kernel > already has (ASoC, in sound/soc) to support ignoring suspends for some > audio paths so that they can be kept up during suspend. This will be > primarily intended for use with opportunistic suspend but not specific > to it. Just for the record I've now done an implementation of this which should show up in -next when it's rebuilt and 2.6.35. It's not the most thoroughly tested code I've ever written but I'm fairly happy it'll do the right thing, especially for analogue basebands. The functionality needs to be explicitly requested by machine drivers so there should be no impact on systems using suspend in a more standard fashion. This means that there should be even less of an issue merging this from an audio point of view. -- 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/ |