On 20/07/15 23:07, Rafael J. Wysocki wrote:

On Monday, July 20, 2015 03:22:09 PM Sudeep Holla wrote:

quoted

On 09/07/15 19:04, Ashwin Chaugule wrote:

quoted

This driver utilizes the methods introduced in the previous
patch - "ACPI: Introduce CPU performance controls using CPPC"
and enables usage with existing CPUFreq governors.

Signed-off-by: Ashwin Chaugule <redacted>
Reviewed-by: Al Stone <redacted>
---
   drivers/cpufreq/Kconfig.arm    |  16 ++++
   drivers/cpufreq/Makefile       |   2 +
   drivers/cpufreq/cppc_cpufreq.c | 197 +++++++++++++++++++++++++++++++++++++++++
   3 files changed, 215 insertions(+)
   create mode 100644 drivers/cpufreq/cppc_cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 4f3dbc8..578384d 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm

@@ -272,3 +272,19 @@ config ARM_PXA2xx_CPUFREQ
   	  This add the CPUFreq driver support for Intel PXA2xx SOCs.

   	  If in doubt, say N.
+
+config ACPI_CPPC_CPUFREQ
+	tristate "CPUFreq driver based on the ACPI CPPC spec"
+	depends on ACPI_CPPC_LIB
+	default n
+	help
+	  This adds a CPUFreq driver which uses CPPC methods
+	  as described in the ACPIv5.1 spec. CPPC stands for
+	  Collaborative Processor Performance Controls. It
+	  is based on an abstract continuous scale of CPU
+	  performance values which allows the remote power
+	  processor to flexibly optimize for power and
+	  performance. CPPC relies on power management firmware
+	  for its operation.

Why is this ARM specific ? It might be used only on ARM but doesn't mean
it should be visible only on ARM ACPI systems.

Why bother people with considering Kconfig options that are useless to them?

I agree to some extent, but main worry is that we are then making these
features architecture specific while ACPI is supposed to be architecture
agnostic. I was just trying to avoid doing so.

Regards,
Sudeep