[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140814205143.GY6758@twins.programming.kicks-ass.net>
Date: Thu, 14 Aug 2014 22:51:43 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Ashwin Chaugule <ashwin.chaugule@...aro.org>
Cc: linux-kernel@...r.kernel.org, catalin.marinas@....com,
mike.turquette@...aro.org, morten.rasmussen@....com,
arjan@...ux.intel.com, mingo@...nel.org, len.brown@...el.com,
rjw@...ysocki.net, linaro-acpi@...ts.linaro.org, arnd@...db.de,
linux-acpi@...r.kernel.org, cpufreq@...r.kernel.org,
patches@...aro.org
Subject: Re: [RFC 0/3] Experimental patchset for CPPC
On Thu, Aug 14, 2014 at 03:57:07PM -0400, Ashwin Chaugule wrote:
>
>
> What is CPPC:
> =============
>
> CPPC is the new interface for CPU performance control between the OS and the
> platform defined in ACPI 5.0+. The interface is built on an abstract
> representation of CPU performance rather than raw frequency. Basic operation
> consists of:
Why do we want this? Typically we've ignored ACPI and gone straight to
MSR access, intel_pstate and intel_idle were created especially to avoid
ACPI, so why return to it.
Also, the whole interface sounds like trainwreck (one would not expect
anything else from ACPI).
So _why_?
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists