Re: [PATCH 0/8] Suspend block api (version 8)

Alan Cox
2010-05-27T23:15:14Z

> The approach with user space power manager suggested by Dmitry and Alan Stern
> may work, but it still assumes some kind of suspend blockers to be present in
> the kernel. If we reject that too, I wonder what approach Google is supposed
> to use and still get the same battery life they get with suspend blockers.

I'm getting less convinced it needs suspend blockers at all for this case,
assuming that you are willing to have a policy that is based on

- assuming apps play nicely
- having the information to user space you need (who woke us, who blocked
us, events)
- dealing with offenders primarily from user space using that information

I'm fairly happy about the following so far

- we should have a common interface for seeing some pm events (like
duh ?) but it does need careful thought so the watcher doesn't change
the behaviour and break it. (Message "We are suspending", gosh someone
is running to receive the message, resume being the obvious case)

- Suspend is (for many platforms) just a cotinuation down the power
chain. Demonstrated and implemented on ARM. Very much the direction of
S0i1/S0i3 on x86 MID devices. Proved by the fact it has been done and
made to work, and by reading the Moorestown PR.

- Given a non forced (that is 'idle down') transition to a suspend level
we can implement a 'suspend as idle' on many embedded platforms in a
manner which is not racy at kernel level. Apparently implemented
already on ARM

- Given a non forced transition to such a suspend level and the reporting
of certain events we can do a full user space managed graphical UI type
environment policy in a race free fashion

- With notification of who caused a resume and maybe a bit of other
general stat gathering it is possible to identify and handle abuses of
power resource. Proved by the fact we can do this with powertop but
more elegance in the interfaces would be nice.

I am not sure if a pm event is what is needed for this or a sum 'hardware
triggered wake up' event.

I accept that current ACPI based laptops probably couldn't make use of
such a feature but I don't think this is important at the moment.

A resource constraint model might help further in the ACPI case. It's
useful for other stuff but it might well be a distraction and
implementation detail in terms of the basic question about what is needed
for something like Android.

At this point the input of the Android team and the Nokia people would
be rather more useful to me.

Alan