linux-kernel - Re: [PATCH 0/8] Suspend block api (version 6)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100507133025.GA23983@rakim.wolfsonmicro.main>
Date:	Fri, 7 May 2010 14:30:25 +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 05:37:21AM -0700, Brian Swetland wrote:
> On Fri, May 7, 2010 at 5:25 AM, Mark Brown

> > It's unfortunate that I only noticed that this was actually wakelocks
> > very late in the day but I think I can get an implementation which
> > handles paths that ignore suspends done quickly.

> Do you mean an implementation of embedded linux audio or an
> implementation of suspend blockers "which handles paths that ignore
> suspends"?  I assume you mean the former, but maybe I misunderstand.

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.

I have no intention of touching suspend blockers, except in that some of
the drivers I'm responsible for should probably use suspend blockers for
similar reasons to the other users you're merging but that's less urgent.

> We've done a lot of work around multicore SoCs where the baseband
> generally owns a lot of the audio routing and so on,

Multicore isn't really the term here - obviously on something like the
OMAP4 or the current nVidia devices you've got a multicore AP but may or
may not have an integrated baseband.  The distinction is down to how
much visibility the AP has of the audio hardware, which is in general
orthogonal to how the silicon is split and packaged.

>                                                      but we do as
> general policy not disable audio, codecs, and amps while playback or
> record is underway.

Yeah, I know.  I have been keeping an eye on the Android stuff, though
none of the audio side has been mainlined yet.

>                      I suppose for environments more like a pc laptop
> where the expectation is the world stops when you close the lid a
> different policy would be preferable.

Yes, quite.  It all depends on what the intention of the user is when
they do a suspend.  Clearly if the suspend was initiated automatically
because the system is apparently idle the intention is different to if
it was initiated because the user performed some explicit action.

> We typically fire up codecs and amps when playback starts (if they
> were off), and usually set a timer for a couple seconds after playback
> stops to spin them down (since you tend to have to delay while they're
> powering up to avoid pops, etc, and if the system just played a short
> sound there's a reasonable chance it'll follow that with another).

This is exactly what ASoC does - the two biggest wins it offers are that
it allows reuse of the code specific to a given piece of silicon on all
boards using that silicon and that it provides automatic runtime power
management in the core by keeping track of which audio paths are live.

There is the slight wrinkle that you don't really want to *fully* power
down devices that don't have ground referenced outputs since they take
a relatively long time to bring their reference level up without audible
artifacts in the output.
--
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/