On Sun, 1 Feb 2009, Rafael J. Wysocki wrote: > > In that case, why are you against using wakelocks to abort the suspend > > sequence? It covers the case where the driver knows that a call is > > coming in, without any confusion about when the abort condition > > clears. And, it avoids the overhead of freezing every process for an > > operation that is doomed to fail. > > I'm not really against (yet), I'm only trying to clearly understand the > benefit. > > The problem pointed out by Alan is real, the user expects the system to suspend > as soon as the button is pressed and wakelocks may get in the way. > > Your example is also good, but I think the problem in your example (phone > call coming in while suspending) may be resolved without wakelocks. Moreover, > it is a general problem of a wake-up event coming in while suspending and > it requires a general solution independent of wakelocks. I'm beginning to get the impression that we're really talking about two different kinds of suspend here. They can be described as "high-priority suspend" and "low-priority suspend". A high-priority suspend occurs when userspace writes "mem" to /sys/power/state. It should override wakelock settings and put the system to sleep as soon as possible (subject to abort by drivers, of course, but they better have a pretty good reason for aborting). A low-priority suspend is what Arve has been talking about; it occurs when the user pushes the phone's "power" button or the auto-suspend mechanism activates. It is subject to blocking by wakelocks, and there should also be a way (although I don't recall seeing it described) to cancel a low-priority suspend request while it is waiting for a wakelock to be released. The idea behind these low-priority suspends is that there are certain activities which should be atomic with respect to suspends, that is, the system should not normally be allowed to suspend while the activity is taking place. These are things that last longer than a single interrupt handler. Examples we have seen include waiting for all key presses to be released (because the keypad can't be enabled for wakeup if any keys are pressed) or waiting for a userspace process to finish playing a ring tone. If a high-priority suspend occurs while some keys are pressed, the keypad driver has a few possible courses of action: abort the suspend, re-enable the interrupt circuitry, or disable keypad wakeups. I'm not sure which would be best; the issue probably won't arise much. Similarly, a high-priority suspend while a ring tone is being played should cause the system to go to sleep right in the middle of playing. Normally we would expect that on a desktop or laptop, the only source of low-priority suspend requests would be the auto-suspend code. On a phone or other embedded device, we would not expect to see any high-priority suspend requests under normal circumstances. But of course there could always be exceptions, if someone wanted them. Early-suspend seems to be a completely different matter. In fact it isn't a suspend state at all, as far as I understand it. It's more like what you get simply by doing a runtime suspend on some collection of devices. I don't see that the kernel needs to treat it as a special state, and in might be possible to have a user program manage the whole thing -- provided the drivers in question implement runtime power management (as USB has done). Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
