On Mon, Feb 2, 2009 at 7:27 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > If you'd like a way for the kernel to communicate to userspace that the > last wakelock has been unlocked, you could use a signal or a select. > But the simplest way would be to make a process block on reading a > sysfs file until the last wakelock is released. I do not want the kernel to communicate to userspace that the last wakelock has been unlocked, I want it to suspend right away. I was answering your question about why the kernel needs to be involved. Yes I could add a notification that tells user-space to suspend again, but it would not offer any additional functionality over my current solution. >> Also, what do you mean by a runtime PM interface? > > I'm making a distinction between system PM and runtime (also known as > dynamic) PM. With system PM the entire system goes into a low-power > state -- that's what we mean when we talk about suspend or hibernation. > With runtime PM the system as a whole remains running while selected > devices are individually put into a low-power state. > > For example, right now Linux will put a USB host controller into a > low-power state if no USB devices are plugged into it. This runtime PM > interface is described in Documentation/usb/power-management.txt. You > might want to use some of those mechanisms for controlling your > devices. OK, but I don't think this affects our use of wakelocks. > For example, if one process tries to start an auto-suspend, and at the > same time another process writes "mem" to /sys/power/state? Then the > second process should take precedence and the system should go into > suspend. When it wakes up again, the first process would still be > waiting for an auto-suspend to occur. I suppose the details don't > matter much because it's not likely to crop up often. I'll make a change to make any write to /sys/power/state disable wakelocks. I'll probably also add a config option to remove /sys/power/state. Before I post another patch series I have a few questions: - Should I merge the wakelock and early-suspend api patches with their implementations? (I initially implemented the api on top of the old android_power driver, but we not longer use this) - Once wakelocks are disabled by writing to /sys/power/state, is there any demand for re-enabling wakelock support? - Are there any objections to using /sys/power/request_state to specify the state to enter when all wakelocks unlocked. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
