[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1328971983.11320.5.camel@laptop>
Date: Sat, 11 Feb 2012 15:53:03 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc: Saravana Kannan <skannan@...eaurora.org>,
Ingo Molnar <mingo@...e.hu>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Todd Poynor <toddpoynor@...gle.com>,
Russell King <linux@....linux.org.uk>,
Nicolas Pitre <nico@...xnic.net>,
Oleg Nesterov <oleg@...hat.com>, cpufreq@...r.kernel.org,
linux-kernel@...r.kernel.org,
Anton Vorontsov <anton.vorontsov@...aro.org>,
linaro-kernel@...ts.linaro.org, Mike Chan <mike@...roid.com>,
Dave Jones <davej@...hat.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
kernel-team@...roid.com, linux-arm-kernel@...ts.infradead.org,
Arjan Van De Ven <arjan@...radead.org>
Subject: Re: [PATCH RFC 0/4] Scheduler idle notifiers and users
On Sat, 2012-02-11 at 14:39 +0000, Mark Brown wrote:
>
> For step downs this isn't such a big deal as we don't often care if the
> voltage drops immediately but for step ups it's critical as if the
> voltage hasn't ramped before the CPU tries to run at the higher
> frequency the CPU will brown out.
Why isn't all this done by micro-controllers, software writes a desired
state in some machine register (fast), micro-controller sets about
making it so in an asynchronous way. If it finds the settings have
changed by the time it reached its former goal, goto 1.
Having to actually wait for this in software is quite ridiculous.
--
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