Hello,
On 4 February 2015 at 09:33, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Tuesday, February 03, 2015 10:23:31 PM Ashwin Chaugule wrote:
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:
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.
Analogously, if _CPC is present on a non-ARM platform.
Hm. Currently CPPC is available only under Kconfig.arm under cpufreq. My understanding is that X86 will use HWP (CPPC equivalent) through intel_pstate (using MSRs). I'm not aware of any other non-ARM platform that could use this as of yet, although in theory, any platform with ACPI support should be able to.
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 not sure if we can do that in general, though.
Curious to know why we couldn't check for _CPC in the acpi-cpufreq driver and bail if it is found? FWIW, the spec also states that if _CPC is present it supersedes _PSS and friends (section 8.4.5.1.10)
I'm open to any suggestions on how to handle this.
Let me think about that a bit more.
Much appreciated!
Cheers, Ashwin