On Thu, Feb 12, 2009 at 4:34 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > On Thu, Feb 12, 2009 at 04:27:53PM -0800, Arve Hjønnevåg wrote: >> On Thu, Feb 12, 2009 at 3:31 AM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: >> > On Tue, Feb 10, 2009 at 05:49:14PM -0800, Arve Hjønnevåg wrote: >> > >> >> spin_lock(&client->buffer_lock); >> >> + wake_lock_timeout(&client->wake_lock, 5 * HZ); >> > >> > Why the timeout version? If your input handler vanishes for more than 5 >> > seconds then presumably you should be thinking about watchdoging the >> > entire system. >> >> The timeout allows the system to eventually suspend if someone opened >> the input device and but are not reading from it. We hit this once. I >> can remove the timeout, but these bugs are more visible in the stats >> if we keep timeout since the expire counts will be non-zero. > > Mm. I'm not convinced about kernel behaviour that's designed to work > around userspace failures. The assumption that your input consumer will > act within 5 seconds is a policy decision, so should probably be left to > userspace. I can make it a module param. I still need a default. I considering 0 (no wakelock), 5 seconds or infinite. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
