But I think "why a system woke up" question is probably less important then the decision of "when should it go back to sleep?".
Currently suspend is initiated by userland. So its outside of the kernel's scope for the moment.
But I can see one potential issue where maybe there's a system that will suspend after 15 minutes of X-idle. A alarm timer fires, and then wakes the system to do some work, but that work takes longer then 15 minutes, so the work gets cut off when the system suspends again.
You could have the application contact the power-management daemon and inhibit suspend while the critical work was being done (much like how slideshow or movie applications do this). This would probably work for the most part, but there are still some races between the wakeup and the userland inhibit message being sent.
And indeed, as Paul mentioned there are a number of different approaches being worked with here, with wakelocks being the most contentious, but also most complete.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds