[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100511184718.GA8732@sirena.org.uk>
Date: Tue, 11 May 2010 19:47:19 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Brian Swetland <swetland@...gle.com>
Cc: Theodore Tso <tytso@....edu>, Arve Hj?nnev?g <arve@...roid.com>,
Alan Stern <stern@...land.harvard.edu>,
Matthew Garrett <mjg@...hat.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Kevin Hilman <khilman@...prootsystems.com>,
linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
Paul Walmsley <paul@...an.com>, magnus.damm@...il.com,
mark gross <mgross@...ux.intel.com>,
Arjan van de Ven <arjan@...radead.org>,
Geoff Smith <geoffx.smith@...el.com>, rebecca@...roid.com
Subject: Re: [PATCH 0/8] Suspend block api (version 6)
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@...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