Date:	Wed, 05 May 2010 16:03:32 -0700
From:	Kevin Hilman <khilman@...prootsystems.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Matthew Garrett <mjg@...hat.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Brian Swetland <swetland@...gle.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Arve Hjønnevåg <arve@...roid.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>
Subject: Re: [PATCH 0/8] Suspend block api (version 6)

Alan Stern <stern@...land.harvard.edu> writes:

> On Wed, 5 May 2010, Matthew Garrett wrote:
>
>> On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote:
>> 
>> > One the face of it, a runtime-PM solution would dictate that the
>> > codec's driver ought to turn off the codec whenever the driver thinks
>> > it isn't being used.  Ergo, if the driver didn't know when a call was
>> > in progress, it would use runtime PM to turn off the codec during a
>> > call.
>> 
>> Well, part of the problem is that right now most of our beliefs about 
>> imposed constraints tend to be based on what userspace is doing - "Don't 
>> power down the audio codec when userspace has it open", for instance. 
>> But that goes away with opportunistic suspend. In most cases you don't 
>> want the audio codec to stay awake just because userspace was using it 
>> to make bouncing cow noises, especially if you've just frozen userspace. 
>> So the problem becomes more complicated than it would otherwise be.
>
> It sounds like the problem can be stated simply enough: At the moment, 
> nobody knows when the codec should be powered down!  Userspace might 
> have some idea, but even if its ideas are right it has no way of 
> communicating them to the kernel.
>
> The power/control sysfs attribute was intended for just that purpose,
> although it was aimed at runtime PM rather than system PM.  
> Nevertheless, it or something like it could be used.  Of course, there 
> would still remain the issue of userspace telling the kernel not to 
> power down the codec while making bouncing cow noises -- but at this 
> point it's not really a kernel problem any more.

I guess what we're talking about here is a set of per-device
constraints that could be used by both [opportunistic|system] suspend
and runtime PM.  For lack of a better term, per-device PM QoS (as
compared to the current system-wide PM QoS.)

For example, if userspace (or some other device) has communicated that
it has a constraint on the audio HW, then both the suspend path and the
runtime PM path could check those constraints before making a decision
on how to act.  Hopefully the phone app would set a constraint and the
cow-noise app would not.  :)

On OMAP, we keep track of per-device constraints (currently latency
and throughput) in order to make proper run-time PM decicions in the
kernel, but we are realizing that we need a way for userspace to
communicate these constraints as well, so that userspace can make
power vs. performance policy decisions instead of the kernel.

Probably generalizing these into the LDM is the direction to go so
userspace can set constraints on a per-device (or per-class?) basis:

/sys/devices/.../power/constraint/throughput
/sys/devices/.../power/constraint/wakeup_latency
/sys/devices/.../power/constraint/... ?

Kevin
--
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