All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-pm@lists.linux-foundation.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Neil Brown" <neilb@suse.de>,
	"Matthew Garrett" <mjg59@srcf.ucam.org>,
	"mark gross" <640e9920@gmail.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Florian Mickler" <florian@mickler.org>,
	linux-pci@vger.kernel.org,
	"Jesse Barnes" <jbarnes@virtuousgeek.org>
Subject: Re: [update] Re: [PATCH] PM: Make it possible to avoid wakeup events from being lost
Date: Wed, 30 Jun 2010 21:27:37 +0200	[thread overview]
Message-ID: <201006302127.37432.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1006301351530.1707-100000@iolanthe.rowland.org>

On Wednesday, June 30, 2010, Alan Stern wrote:
> On Mon, 28 Jun 2010, Rafael J. Wysocki wrote:
> 
> > +/*
> > + * The functions below use the observation that each wakeup event starts a
> > + * period in which the system should not be suspended.  The moment this period
> > + * will end depends on how the wakeup event is going to be processed after being
> > + * detected and all of the possible cases can be divided into two distinct
> > + * groups.
> > + *
> > + * First, a wakeup event may be detected by the same functional unit that will
> > + * carry out the entire processing of it and possibly will pass it to user space
> > + * for further processing.  In that case the functional unit that has detected
> > + * the event may later "close" the "no suspend" period associated with it
> > + * directly as soon as it has been dealt with.  The pair of pm_stay_awake() and
> > + * pm_relax(), balanced with each other, is supposed to be used in such
> > + * situations.
> > + *
> > + * Second, a wakeup event may be detected by one functional unit and processed
> > + * by another one.  In that case the unit that has detected it cannot really
> > + * "close" the "no suspend" period associated with it, unless it knows in
> > + * advance what's going to happen to the event during processing.  This
> > + * knowledge, however, may not be available to it, so it can simply specify time
> > + * to wait before the system can be suspended and pass it as the second
> > + * argument of pm_wakeup_event().
> > + */
> 
> Since there's no longer any way to cancel a call to pm_wakeup_event()  
> or close the "no suspend" period early, there is no need to use
> dynamically-allocated delayed_work structures.  You can make do with a
> single static timer; always keep it set to expire at the latest time
> passed to pm_wakeup_event().

The decremenations of events_in_progress wouldn't be balanced with
incrementations this way.  Or do you have any clever way of dealing with
that in mind?

Rafael

  reply	other threads:[~2010-06-30 19:29 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-26 13:14 [PATCH] PM: Make it possible to avoid wakeup events from being lost Rafael J. Wysocki
2010-06-27 15:50 ` Alan Stern
2010-06-27 15:50 ` Alan Stern
2010-06-27 23:59   ` Rafael J. Wysocki
2010-06-27 23:59   ` Rafael J. Wysocki
2010-06-28 14:16     ` Alan Stern
2010-06-28 14:16     ` Alan Stern
2010-06-28 19:01       ` [update] " Rafael J. Wysocki
2010-06-28 19:01       ` Rafael J. Wysocki
2010-06-28 19:11         ` Jesse Barnes
2010-06-28 19:11         ` Jesse Barnes
2010-06-28 19:19         ` Alan Stern
2010-06-28 21:19           ` Rafael J. Wysocki
2010-06-28 21:19           ` Rafael J. Wysocki
2010-06-28 19:19         ` Alan Stern
2010-06-28 20:38         ` Greg KH
2010-06-28 20:38         ` Greg KH
2010-06-30  7:10         ` Florian Mickler
2010-06-30  7:10         ` Florian Mickler
2010-06-30 13:47           ` mark gross
2010-06-30 13:47           ` mark gross
2010-06-30 18:00         ` Alan Stern
2010-06-30 19:27           ` Rafael J. Wysocki [this message]
2010-06-30 19:58             ` Alan Stern
2010-06-30 19:58             ` Alan Stern
2010-06-30 23:52               ` Rafael J. Wysocki
2010-06-30 23:52               ` Rafael J. Wysocki
2010-07-01 13:58                 ` Alan Stern
2010-07-01 20:08                   ` Rafael J. Wysocki
2010-07-01 20:44                     ` Alan Stern
2010-07-01 21:05                       ` Rafael J. Wysocki
2010-07-01 21:05                       ` Rafael J. Wysocki
2010-07-01 20:44                     ` Alan Stern
2010-07-01 20:08                   ` Rafael J. Wysocki
2010-07-01 13:58                 ` Alan Stern
2010-06-30 19:27           ` Rafael J. Wysocki
2010-06-30 18:00         ` Alan Stern
2010-06-28 23:28     ` [linux-pm] " David Brownell
2010-06-29 19:57       ` Alan Stern
2010-06-29 19:57       ` [linux-pm] " Alan Stern
2010-06-28 23:28     ` David Brownell
2010-06-27 22:28 ` mark gross
2010-06-27 22:28 ` mark gross
2010-06-28 12:50   ` Rafael J. Wysocki
2010-06-29  4:43     ` mark gross
2010-06-29  4:43     ` mark gross
2010-06-28 12:50   ` Rafael J. Wysocki
2010-07-01 13:32 ` Pavel Machek
2010-07-01 15:08   ` Florian Mickler
2010-07-01 15:08   ` Florian Mickler
2010-07-01 19:02   ` Rafael J. Wysocki
2010-07-01 19:02   ` Rafael J. Wysocki
2010-07-02 18:14     ` Pavel Machek
2010-07-02 19:21       ` Rafael J. Wysocki
2010-07-02 19:21       ` Rafael J. Wysocki
2010-07-02 18:14     ` Pavel Machek
2010-07-01 13:32 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201006302127.37432.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=640e9920@gmail.com \
    --cc=arve@android.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=florian@mickler.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=neilb@suse.de \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.