Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux