DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=pacbell.net;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=h8A8ZEBIf0v0ESZm7SEZFLfHm8OLk97QJrbp5eGK93T0IgP77werIpO4S586d4EmdMsmQzFoYj4//9KMwRbgov2MimGAaY+iFvwcEF6Yt4eFai48XnBK0o4e8hDOQPfaCH9sX+hFpK9USqElB0VYeeB2UfUZkQSgbrn1WEqUr1Q=;
Message-ID: <18366.69939.qm@web180315.mail.gq1.yahoo.com>
Date: Sat, 26 Jun 2010 09:54:00 -0700 (PDT)
From: David Brownell <david-b@pacbell.net>
Subject: Re: [linux-pm] [PATCH] PM: Make it possible to avoid wakeup events from being lost
To: linux-pm@lists.linux-foundation.org, "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: mark gross <640e9920@gmail.com>, Neil Brown <neilb@suse.de>,
       linux-pci@vger.kernel.org, Dmitry Torokhov <dmitry.torokhov@gmail.com>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       Arve@smtp1.linux-foundation.org, Florian Mickler <florian@mickler.org>,
       Jesse Barnes <jbarnes@virtuousgeek.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2668
Lines: 65

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

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.)

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.)

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.

(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.

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
> from it returns the current number of registered
> +??? ??? wakeup events and it
> blocks if some wakeup events are being
> +??? ??? processed at the
> time the file is read from.?


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