Hi Rafael,
On 3 February 2015 at 17:33, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Tuesday, January 27, 2015 04:03:58 PM Ashwin Chaugule wrote:
CPPC stands for Collaborative Processor Performance Controls and is defined in the ACPI v5.0+ spec. It describes CPU performance controls on an abstract and continuous scale allowing the platform (e.g. remote power processor) to flexibly optimize CPU performance with its knowledge of power budgets and other architecture specific knowledge.
This patch introduces a CPUFreq driver which works with existing CPUFreq governors. The backend CPPC methods for parsing the CPPC table and reading/writing using CPPC semantics are abstracted away such that they can be used by any other CPPC based CPUFreq driver in the future.
First question: How do we ensure that this won't interact negatively with the existing ACPI cpufreq driver? In particular, what is there to allow users to use the driver they want?
The existing ACPI cpufreq driver isnt enabled on ARM. (At a minimum, it needs spec updates in the PSS sections for ARM.) For ARM64 servers, CPPC is the preferred choice. But you're right, if someone adds PSS support on ARM then we need a way to make these two mutually exclusive at runtime. IIUC on X86, intel_pstate is skipped if it finds PSS/PPC? On ARM64 servers, we'd want it the other way. i.e. if the acpi-cpufreq driver detects CPC then it skips its init. I'm open to any suggestions on how to handle this.
Thanks, Ashwin