Re: [linux-pm] [PATCH] PM: Make it possible to avoid wakeup eventsfrom being lost

[Alan Stern]

On Sat, 26 Jun 2010, David Brownell wrote:

> This is a repeat of an issue I posted before, but
> which for some reason I never saw email back ...

I replied to one of your emails on this topic.  Maybe you didn't see 
the reply.

> basically, I think the notion of counting wakeup
> events seems dubious on common hardware, so the
> focus might perhaps better be placed on ensuring
> userspace just receives events rather than
> trying to track events which in one context ended
> up being wakeup events.  (That's simpler, and the
> system is by definition awake if it can handle any
> events at all.)

I disagree.  There's no question that userspace will eventually receive 
these events.  The question is whether they will be received in a 
timely manner.

The "counting" isn't meant as a way of keeping track of the absolute
number of these events.  It's more like a technique for seeing how many
remain outstanding at any time.

> Thing is, "wakeup" is, for e.g. most ARMs, just a hardware attribute of what's otherwise a routine
> event, which happens in other contexts and needs
> to be handled consistently .... nothing special
> about having woken the system too, the result ought to
> be the same regardless (from the user P.O.V.) ...  (Common Examples include SoC peripheral IRQs that can wake the system (including GPIO and other types
> of external IRQ signal.)

There's nothing wrong with that.  All these routine events may qualify
as "wakeup" events.  The real deciding factor is whether the event
should cause tasks to be unfrozen (if they have already been frozen by
the PM core).  If yes then it is a "wakeup" event; otherwise it isn't.

> BRIEFLY:  if that event doesn't arrive reliably,
> it's an issue regardless of wakeup:  either TX from
> kernel, or RX in userspace. Such bugs would need to
> be fixed.  Having them fixed will help the wakeup scenarios too of course.

That is irrelevant to the topic at hand.  We know that these events 
arrive; what we don't know is that they will properly block tasks 
from being frozen (or will unfreeze them if they are already frozen).

> (The raciness issues might boil down to something as simple as not letting userspace know about transition events to/from suspend states, but that issue
> ought to be cleanly separable; ISTR other messages on the suspend blocker threads have shown how to work with such clean factoring.)
> 
> 
> 
> So trying to track whether a given event is what
> woke the system will often be implausible, since
> several such events might each have fired (one
> or more concurrent wakeup sources, even ... it
> could be indeterminate which one[s] happened.)
> And the event could fire without being a wakeup.

It doesn't matter which event(s) woke the system, and Rafael's patch 
doesn't try to track this.

> Yes, there are a few cases (like USB remote wakeup
> signaling and some PCI mechanisms, plus a few BIOS
> assisted situations) where certain events may be
> identifiable as wakeup sources, perhaps runtime not
> system-wide).  But the common case just includes
> an event, not the ability to know that event had
> the "woke whole system from low power state"
> side effect too.

> > +        The
> > /sys/power/wakeup_count file allows user space to avoid
> > +        losing wakeup events
> > when transitioning the system into a sleep
> > +        state.  Reading

This could have been phrased better:  The /sys/power/wakeup_count file
allows user space to put the system into a sleep state conditionally
subject to the arrival of concurrent wakeup events, which will either
block the sleep transition or cause it to fail.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/