On Friday 28 May 2010, Alan Cox wrote: > > 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.
No, it's not. > 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. OK, I added Arve and Brian to the CC list. Thanks, Rafael -- 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
