[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090216135204.064f553b@infradead.org>
Date: Mon, 16 Feb 2009 13:52:04 -0800
From: Arjan van de Ven <arjan@...radead.org>
To: "Woodruff, Richard" <r-woodruff2@...com>
Cc: Alan Stern <stern@...land.harvard.edu>,
Kyle Moffett <kyle@...fetthome.net>,
Oliver Neukum <oliver@...kum.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
"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>,
Pavel Machek <pavel@....cz>,
Nigel Cunningham <nigel@...el.suspend2.net>,
Matthew Garrett <mjg59@...f.ucam.org>,
mark gross <mgross@...ux.intel.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, 16 Feb 2009 15:32:06 -0600
"Woodruff, Richard" <r-woodruff2@...com> wrote:
>
> - It provides a way to handle overdrive/turbo operating points out of
> band from the generically tuned cpufreq governors like ondemand. The
> way we characterize overdrive is stricter then what Intel has talked
> about for x86.
if you have an improved-for-your-systems governor then I'm sure that is
very welcome in the kernel.
I agree that perfect is the enemy of good.
I think just about all of us agree that the final decision needs to be
in the driver (possibly followed by something that gets various device
requests and combines it into hw settings); we're just talking about
what inputs feed into that decision ;)
And for different types of devices that's guaranteed to be different...
and sometimes we'll be hampered by existing interfaces, so we might end
up with hacky stuff.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.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