On Thu, 10 Jun 2010, Arve Hjønnevåg wrote: > > You've lost me. If the power manager is sitting inside a select/poll, > > how can it miss the event (given that the event will make data > > available to be read on one of the descriptors being polled)? > > > > It cannot sit inside of select/poll all the time. > > > Or put it another way: With wakelocks, if the app doesn't use a suspend > > blocker then once it reads the event data and the timed wakelock is > > deactivated, there is nothing to prevent the system from immediately > > going into opportunistic suspend. My scheme can fail in the same way. > > Is that what you meant? > > > > No, if an app reads from a file descriptor and block suspend when the > read call returns, then suspend is blocked while processing the data. > If the driver uses a wakelock with a timeout this will fail if the > thread does not get to the suspend block call before the timeout > expires, but unrelated events that don't prevent the app from running > will not cause any problems. Wait a second. Maybe I have misunderstood how timeouts are supposed to work with wakelocks. I thought the idea was that the wakelock would be released when the timeout expires or the event queue is emptied, whichever comes first. Now it sounds like you're saying that the wakelock doesn't get released until the timeout expires, even if userspace finishes processing all pending events before then. > In your scheme the user-space power > manager may miss events on this file descriptor since select/poll will > not see an event if the app read that event right before the power > manager called select/poll. If the wakelock is supposed to remain active until the timeout expires then you are right. On the other hand, this seems like a rather strange and suspicious way of handling wakelocks. Why would you want to do it that way? > > There's one question that I don't remember ever seeing answered. To > > which kernel drivers do you intend to add suspend blockers? > > > > All drivers that generate wakeup events need to either use suspend > blockers directly or call into something else that does. For instance, > with the patch to block suspend while input events are queued to > user-space, an input driver that fully handles its events in its > interrupt handler does not need any additional suspend blockers, but > if the driver needs a work function or a timer to run before it > reports the event it needs to block suspend until it has reported the > event. Sure. But specifically, which drivers on Android generate wakeup events? And which of them don't fully handle their events in their interrupt handlers? Maybe another way to put this is: Where in the kernel do you intend to add suspend blockers? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
