On Tue, May 25, 2010 at 11:33 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Tue, May 25, 2010 at 02:25:08PM -0400, Alan Stern wrote: >> On Tue, 25 May 2010, Dmitry Torokhov wrote: >> >> > BTW, If you are concerned about events that already "left" physical >> > device but has not reached userspace yet - maybe instead of suspend >> > blockers we should make sure that all drivers throughout the chain >> > implement suspend/resume and refuse suspending if their queues are not >> > empty. In input land that would mean extending suspend routine in >> > input_dev and adding one to evdev. >> >> That's not the only problem. We also have to consider events that have >> reached userspace but not yet been fully processed. The user thread >> handling the event needs some way to prevent the system from suspending >> until it is all done. >> > > It is a problem if kernel initiated suspend transition on its own. I > believe that it is userspace responsibility to initiate sustend (and > make sure that needs of userspace, including processing of certain > events, are served beforehand). That only works if a single user-space thread initiates suspend and consumes all wakeup events (or if the user-space code that initiates suspend implements suspend blockers), and even then the kernel would still need to block suspend in same places as it does if the kernel initiates suspend. If a wakeup event happens right after user-space initiates suspend, that suspend must be aborted. By only initiating suspend from user-space, you force this to be a polling operation. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
