[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1006301535450.1707-100000@iolanthe.rowland.org>
Date: Wed, 30 Jun 2010 15:58:36 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: "Rafael J. Wysocki" <rjw@...k.pl>
cc: linux-pm@...ts.linux-foundation.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Neil Brown <neilb@...e.de>,
Matthew Garrett <mjg59@...f.ucam.org>,
mark gross <640e9920@...il.com>,
Arve Hjønnevåg <arve@...roid.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Florian Mickler <florian@...kler.org>,
<linux-pci@...r.kernel.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [update] Re: [PATCH] PM: Make it possible to avoid wakeup events
from being lost
On Wed, 30 Jun 2010, Rafael J. Wysocki wrote:
> > 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?
Keep track of the current expiration time in a static variable called
wakeup_timeout, and use 0 to indicate there is no timeout.
In pm_wakeup_event() (everything protected by the spinlock):
unsigned long new_timeout = jiffies + msecs_to_jiffies(msecs);
if (new_timeout == 0)
new_timeout = 1;
++event_count;
if (!wakeup_timeout || time_after(new_timeout, wakeup_timeout)) {
if (!wakeup_timeout)
++events_in_progress;
wakeup_timeout = new_timeout;
mod_timer(&wakeup_timer, wakeup_timeout);
}
In the timer routine:
if (wakeup_timeout && time_before_eq(wakeup_timeout, jiffies)) {
--events_in_progres;
wakeup_timeout = 0;
}
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists