Re: Trying to understand new wakeup events architecture

[Daniel Drake <dsd@laptop.org>]

On Thu, 2011-01-13 at 20:34 +0100, Rafael J. Wysocki wrote:
> It looks like Daniel wants the wakeup events framework to store the last
> active wakeup source information somewhere (eg. in a file in /sys/power).
> I'm a little bit worried about that, because potentially there may be many
> wakeup events occuring at run time, in which case it would be a significant
> performance overhead to update the "last active wakeup source" info every
> time (and a scalability issue, because every code path handling a wakeup
> source would want to update the same sysfs file).  Also, collecting that
> information at run time doesn't seem to be particularly useful.

This was one thing that confused me reading about the wakeup events
architecture, and I'm still not entirely clear.

Your definition of "wakeup event" is an event that happens, during
regular system operation, that should prevent the system from going to
sleep. Is that accurate?

When I refer to "wakeup event" I'm referring exclusively to events that
happen when the system is suspended, that cause it to wake up and resume
operation.

> It may be useful to know what device has actually woken up the system from
> suspend.  To that end, I think the only really valid approach is to retrieve
> this information from the platform firmware early during resume and export
> it through a sysfs attribute afterwards.  We can develop a generic helper
> code for that second part, but the first one has to be platform-specific.
> 
> Daniel, what exactly does your user space use this information for?

We're talking the same language here. I'd welcome a generic helper.

There are several different cases, but here is one example that should
be illustrative:

1) System is idle, hence it goes to sleep with display on, with rtcwake
timer for 5 minutes in the future, as well as various other wakeup
sources active (keyboard, mouse, network, ...)

2) 5 minutes passes and system resumes. Userspace determines that the
wakeup source was the RTC alarm. In other words, the system is still
idle. Since the user doesn't seem to be doing anything and might not
even be watching, we dim the screen a bit to save some power. Then we go
back to sleep.

3) A few minutes later, the user starts typing. The system resumes.
Userspace checks the wakeup reason, notes that it was woken up due to
local user activity. So the display is restored to normal brightness.
The idle-check timer is started again, ready to go to sleep a minute or
so after user inactivity.




an alternative case for #3 is:

3b) A few minutes later, a network packet is received for the system.
The system resumes. Userspace checks the wakeup reason, notes that it
was woken up due to network activity. The brightness is *not* changed,
since if it were, it would appear very strange to anyone watching. The
system goes back to sleep within a few seconds, assuming that the user
is not present means that theres no need to sit around a long time
waiting for input.


Daniel