[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0912090914330.3560@localhost.localdomain>
Date: Wed, 9 Dec 2009 09:19:46 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Alan Stern <stern@...land.harvard.edu>
cc: Mark Brown <broonie@...nsource.wolfsonmicro.com>,
"Rafael J. Wysocki" <rjw@...k.pl>, Zhang Rui <rui.zhang@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists