Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)
in [Kernel]
|
Prev: futex: Take mmap_sem for get_user_pages in fault_in_user_writeable
Next: [PATCH v9 0/8] Loongson: YeeLoong: add platform drivers
From: Mark Brown on 9 Dec 2009 11:50 On Wed, Dec 09, 2009 at 11:23:00AM -0500, Alan Stern wrote: > On Wed, 9 Dec 2009, Mark Brown wrote: > > I'm not convinced that helps with the fact that the suspend may take a > > long time - ideally we'd be able to start the suspend process off but > > let other things carry on while it completes without having to worry > > about something we're relying on getting suspended underneath us. > The suspend procedure is oriented around device structures, and what > you're talking about isn't. It's something separate which has to be > finished before _any_ of the audio devices are suspended. In this context the "subsystem" actually has a struct device associated with it so does appear in the device flow. > How long does it take to bring down the entire embedded audio > subsystem? And how critical is the timing for typical systems? Worst case is about a second for both resume and suspend which means two seconds total but it's very hardware dependant. The latency budget for suspend and resume are both zero in an ideal world, users want to be able to suspend as much as possible which means they'd like it to take no perceptible time at the human level. Some hardware is at the point where that's getting realistic but the folks on older hardware still want to get as close to that as they can. -- 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: Alan Stern on 9 Dec 2009 12:20 On Wed, 9 Dec 2009, Mark Brown wrote: > > How long does it take to bring down the entire embedded audio > > subsystem? And how critical is the timing for typical systems? > > Worst case is about a second for both resume and suspend which means two > seconds total but it's very hardware dependant. A second seems awfully long. What happens if audio isn't being played when the suspend occurs? Can't you shorten things with no artifacts in that case? If audio _is_ being played when a suspend occurs, users probably don't mind audible artifacts. In fact, they probably expect some. Alan Stern -- 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: Linus Torvalds on 9 Dec 2009 12:30 On Wed, 9 Dec 2009, Alan Stern wrote: > > If audio _is_ being played when a suspend occurs, users probably don't > mind audible artifacts. In fact, they probably expect some. I'd say it's physically impossible not to get them. If you're really suspending your audio hardware, it _will_ be quiet ;) I suspect somebody is draining existing queues or something, or just probing for an external analog part. Neither of which is really sensible or absolutely required in an embedded suspend/resume kind of situation. Especially for STR, just "leave all the data structures around, and just stop the DMA engine" is often a perfectly fine solution - but drivers don't do it, exactly because we've often had the mentality that you re-initialize everything under the sun. I can see _why_ a driver would do that ("we re-use the same code that we use on close/open or module unload/reload"), but it doesn't change the fact that it's stupid to do if you worry about latency. And yeah, turning it async might hide the problem. But the code word there is "hide" rather than "fix". Linus -- 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 9 Dec 2009 12:50 On Wed, Dec 09, 2009 at 08:57:32AM -0800, Linus Torvalds wrote: > On Wed, 9 Dec 2009, Mark Brown wrote: > > Worst case is about a second for both resume and suspend which means two > > seconds total but it's very hardware dependant. > I would seriously suggest just looking at the code itself. > Maybe the code is just plain sh*t? If we're talking embedded audio, we're > generally talking SoC chips (maybe some external audio daughtercard), and Yes, usually this is a SoC plus one or more external devices handling the mixed signal parts of things all soldered down onto a board. > quite frankly, it sounds to me like you're just wasting your own time. > There is no way that kind of hardware really needs that much time. Some of the older hardware really does need that much time, sadly. More recent hardware got that down much lower (into the low hundreds of ms where it's much less of an issue but still present) and current generations basically don't have the problem any more but for worst case a second is a good approximation. The problem comes when you've got audio outputs referenced to something other than ground which used to happen because no negative supplies were available in these systems. To bring these up from cold you need to bring the outputs up to the reference level but if you do that by just turning on the power you get an audible (often loud) noise in the output from the square(ish) waveform that results which users don't find acceptable. The initial solution was to ramp the voltage on the outputs in such a way that the waveform that appears on the outputs isn't audible, which broadly boils down to ramping it slowly. People were very aware of the problems so later generations of devices added features which allowed this to happen much more quickly than the original implementations had, but still noticably slow in terms of the timescales people need. Current generation hardware solves the problem by using charge pumps to provide a negative supply, allowing ground referenced outputs which are just a win all round for this and other reasons. They're fast enough to allow the power up to be brought completely in line with the start of the audio stream, taking this out of suspend and resume entirely. > Now, I can easily see one-second delays in code that simply has never been > thought about or cared about it. We used to have things like that in the > serial code where just probing for non-existent serial ports took half a > second per port because there was a timeout. It's a deliberate delay waiting for the voltages to ramp, there's plenty of things that need to be fixed or optimised in the code but those that are causing issues these days really are just explicitly inserted delays waiting for things to happen in hardware that do actually take that long. > Because bad coding is much more likely to be the real reason. Would that it were - you wouldn't believe the amount of time that's been spent over the years tuning for this. -- 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: Linus Torvalds on 9 Dec 2009 13:00
On Wed, 9 Dec 2009, Mark Brown wrote: > > The problem comes when you've got audio outputs referenced to something > other than ground which used to happen because no negative supplies were > available in these systems. To bring these up from cold you need to > bring the outputs up to the reference level but if you do that by just > turning on the power you get an audible (often loud) noise in the output > from the square(ish) waveform that results which users don't find > acceptable. Ouch. A second still sounds way too long - but whatever. However, it sounds like the nice way to do that isn't by doing it synchronously in the suspend/resume code itself, but simply ramping it down (and up) from a timer. It would be asynchronous, but not because the suspend itself is in any way asynchronous. Done right, it might even result in a nice volume fade of the sound (ie if the hw allows for it, stop the actual sound engine late on suspend, and start it early on resume, so that sound works _while_ the whole reference volume rampdown/up is going on) Linus -- 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/ |