On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
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
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.
Did I miss anything?
James
--
