On Tuesday 01 June 2010, James Bottomley wrote: > 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: Thanks for the recap. > 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) I think that's not been decided yet precisely enough. I saw a few ideas here and there in the thread, but which of them are we going to follow? > 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 > interface?) > > 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. Is the original idea of having that information in debugfs objectionable? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
