On Fri, 11 Jun 2010, Arve Hjønnevåg wrote: > > 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, > > That is one way to use it, and I did this so code that opened an input > device without reading from it would not prevent suspend forever. In > the last patchset I posted, I instead used an ioctl to enable the > suspend blocker. > > > 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. > > > > For incoming network traffic we use a wakelock with a timeout to > prevent suspend long enough for the data to make it to user-space > since we have not added wakelocks to the network stack. > We did this to avoid changing to the network stack, tty layer, etc. I see. These are examples where wakelocks are _not_ released by any userspace action, so they don't seem to fit well into my all-userspace scheme. At least, not in their current form. On the other hand, if the network/tty wakeup events eventually cause data to become available on a socket or device file, then they wouldn't need any special treatment in my scheme. The socket/file descriptors could be handled the same as any others. (Although you might need to change some apps, to make them follow the usual pattern of poll, activate suspend blocker, read, process, release suspend blocker.) In other words, the fact that everything has been moved into userspace means that you wouldn't have to worry about the missing wakelocks in the network stack or tty layer, and consequently wouldn't have to worry about using timed wakelocks there. > > Sure. But specifically, which drivers on Android generate wakeup > > events? And which of them don't fully handle their events in their > > interrupt handlers? > > > > Keypad, network, charger, rtc, but I'm sure I forgot some. > > > Maybe another way to put this is: Where in the kernel do you intend to > > add suspend blockers? > > > > In addition to the drivers that enable the wakeup events, we have > added suspend blockers to the input event code and power supply > framework. The tty layer and network stack would also need suspend > blockers to avoid using timeouts. I see. The keypad, charger (power supply), and rtc drivers sound pretty platform-specific. Probably nobody would complain too strongly about adding suspend blockers there. The input, network, and tty layers are more general, though. That's where you're most likely to encounter resistance. People have been complaining about "suspend blockers being added all throughout the kernel". It might help if you pointed out that it's just in these three layers (and maybe at only a few specific points within each layer). 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
