[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090216231324.GA15435@srcf.ucam.org>
Date: Mon, 16 Feb 2009 23:13:24 +0000
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Pavel Machek <pavel@...e.cz>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
pm list <linux-pm@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Arve Hj?nnev?g <arve@...roid.com>,
Alan Stern <stern@...land.harvard.edu>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Nigel Cunningham <nigel@...el.suspend2.net>,
mark gross <mgross@...ux.intel.com>,
"Woodruff, Richard" <r-woodruff2@...com>,
Uli Luckas <u.luckas@...d.de>,
Igor Stoppa <igor.stoppa@...ia.com>,
Brian Swetland <swetland@...gle.com>,
Len Brown <lenb@...nel.org>
Subject: Re: [RFD] Automatic suspend
On Mon, Feb 16, 2009 at 11:58:31PM +0100, Pavel Machek wrote:
> If no devices are being used, and next wakeup is far enough in the
> future, just put system to sleep. Long enough == so far away that
> suspend/wakeup is short compared to that... like 20 seconds on PC.
This is intrinsically difficult with PCs, since we have such a poorly
defined set of wakeup events. We can't wakeup on generic network
traffic, just WoL. Many machines won't wake up on keyboard events.
Meanwhile, on embedded it's becoming a less interesting problem because
idle and suspended are often now equivalent states. Concentrating on
runtime PM of as much hardware as possible is arguably more interesting
for the majority of use cases.
--
Matthew Garrett | mjg59@...f.ucam.org
--
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