On Wed, 02 Jun 2010 10:05:11 -0500
James Bottomley <James.Bottomley@suse.de> wrote:
But unblocking suspend at the moment is independent to getting idle.
If you have the requirement to stay in the highest-idle level (i.e.
best latency you can get) that does not (currently) mean, that you can
To preserve that explicit fall-through while still having working
run-time-powermanagement I think the qos-constraints need to be
<disclaimer: just from what I read>
Provided you can reach the same power state from idle, current suspend
could probably also be implemented by just the freezing part and a hint
to the idle-loop to provide accelerated fall-through to lowest power.
At that point, you could probably merge the constraints.
But the freezing part is also the hard part, isn't it? (I have no
idea. Thomas seems to think about cgroups for that and doing smth about the timers.)