> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
