On Fri, May 14, 2010 at 03:18:13PM -0700, Arve Hjønnevåg wrote: > On Fri, May 14, 2010 at 1:27 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: > > > > Hello, > > > > On Mon, 3 May 2010, Arve Hjønnevåg wrote: > > > >> No, suspend blockers are mostly used to ensure wakeup events are not > >> ignored, and to ensure tasks triggered by these wakeup events > >> complete. > > > > Standard Linux systems don't need these, > > If you don't want to lose wakeup events they do. Standard Linux > systems support suspend, but since they usually don't have a lot of > wakeup events you don't run into a lot of problems. > What I do not quite understand is how exactly suspend blocks save us from missing wakeup events. Consider case when all events have been processed and system starts entering the sleep: we are in a half-sleep, half awake state, with some devices already put to sleep and some just now being processed. If user presses a key while physical input device is being suspended, what will happen? Do you expect interrupt routine abort suspend process? Initiate resume if suspend of the device has completed? Also, let's say device is suspended and is configured as a wakeup source while the rest of the system is still awake... If I press a key I do not think that it will necessarily abort suspend process. Or will it? 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. Thanks. -- Dmitry _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
