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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20100512112227.GA4312@sirena.org.uk>
Date:	Wed, 12 May 2010 12:22:28 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arve Hj?nnev?g <arve@...roid.com>
Cc:	Kevin Hilman <khilman@...prootsystems.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	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>
Subject: Re: [PATCH 0/8] Suspend block api (version 6)

On Tue, May 11, 2010 at 06:11:09PM -0700, Arve Hj?nnev?g wrote:

> > 2.2 Usage in PM aware drivers
> > ==============================

> > [An example of how a driver already using runtime PM would use
> > ?a suspend blocker would also be helpful.

> An audio driver can block suspend while audio is playing. We don't
> currently use the runtime pm framework since this is new, but we do
> runtime pm by turning off clocks and power when the device is
> inactive.

Could you clarify what's going on here please?  What do you mean by an
"audio driver" here - there's several different classes of driver which
work together to produce the embedded audio subsystem and I'm not clear
which you're referring to here.  I'd not expect a chip-specific audio
driver to be taking suspend blockers at all except during things like
accessory detect handling which can take a long time.  A system-specific
driver could reasonably block during playback but doing it in a chip
specific driver sounds like a bit too much of a policy decision.

The kernel runtime PM framwwork tends not to come into play for anything
except MFD and SoC drivers with audio where they're a component of PM on
the larger chip and it's useful for coordinating with the other drivers
in play.  Otherwise we already have very detailed automatic power
management (especially for the CODECs) and there's no benefit in
bouncing through runtime PM.
--
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/