Features Download
From: James Bottomley <James.Bottomley <at> suse.de>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
Newsgroups: gmane.linux.ports.arm.omap
Date: Tuesday 1st June 2010 21:01:25 UTC (over 7 years ago)
On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
> On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
> > You're the one mentioning x86, not me.  I already explained that some
> > MSM hardware (the G1 for example) has lower power consumption in S3
> > (which I'm using as an ACPI shorthand for suspend to ram) than any
> > suspend from idle C state.  The fact that current x86 hardware has the
> > same problem may be true, but it's not entirely relevant.
> As long as you can set a wakeup timer, an S state is just a C state with 
> side effects. The significant one is that entering an S state stops the 
> process scheduler and any in-kernel timers. I don't think Google care at 
> all about whether suspend is entered through an explicit transition or 
> something hooked into cpuidle - the relevant issue is that they want to 
> be able to express a set of constraints that lets them control whether 
> or not the scheduler keeps on scheduling, and which doesn't let them 
> lose wakeup events in the process.

Exactly, so my understanding of where we currently are is:

     1. pm_qos will be updated to be able to express the android suspend
        blockers as interactivity constraints (exact name TBD, but
        probably /dev/cpu_interactivity)
     2. pm_qos will be updated to be callable from atomic context
     3. pm_qos will be updated to export statistics initially closely
        matching what suspend blockers provides (simple update of the rw

After this is done, the current android suspend block patch becomes a
re-expression in kernel space in terms of pm_qos, with the current
userspace wakelocks being adapted by the android framework into pm_qos
requirements expressed to /dev/cpu_interactivity (or whatever name is
chosen).  Then opportunistic suspend is either a small add-on kernel
patch they have in their tree to suspend when the interactivity
constraint goes to NONE, or it could be done entirely by a userspace
process.  Long term this could migrate to the freezer and suspend from
idle approach as the various problem timers get fixed.

I think the big unresolved issue is the stats extension.  For android,
we need just a name written along with the value, so we have something
to hang the stats off ... current pm_qos userspace users just write a
value, so the name would be optional.  From the kernel, we probably just
need an additional API that takes a stats name or NULL if none
(pm_qos_add_request_named()?).  Then reading the stats could be done by
implementing a fops read routine on the misc device.

Did I miss anything?


To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
CD: 3ms