[PATCH v7 0/8] CPUFreq driver using CPPC methods

[PATCH v7 0/8] CPUFreq driver using CPPC methods

[Ashwin Chaugule]

CPPC:
====

CPPC (Collaborative Processor Performance Control) is a new way to control CPU
performance using an abstract continous scale as against a discretized P-state scale
which is tied to CPU frequency only. It is defined in the ACPI 5.0+ spec. In brief,
the basic operation involves:
- OS makes a CPU performance request. (Can provide min and max tolerable bounds)

- Platform (such as BMC) is free to optimize request within requested bounds depending
on power/thermal budgets etc.

- Platform conveys its decision back to OS

The communication between OS and platform occurs through another medium called (PCC)
Platform communication Channel. This is a generic mailbox like mechanism which includes
doorbell semantics to indicate register updates. See drivers/mailbox/pcc.c

This patchset introduces a CPPC based CPUFreq driver that works with existing governors
such as ondemand. The CPPC table parsing and the CPPC communication semantics are
abstracted into separate files to allow future CPPC based drivers to implement their
own governors if required.

Initial patchsets included an adaptation of the PID governor from intel_pstate.c. However
recent experiments led to extensive modifications of the algorithm to calculate CPU
busyness. Until it is verified that these changes are worthwhile, the existing governors
should provide for a good enough starting point for ARM64 servers.

Finer details about the PCC and CPPC spec are available in the latest ACPI 5.1
specification.[2]

Testing:
=======

This was tested on an SBSA compatible ARMv8 server with CPPCv2
firmware running on a remote processor. I verified that each CPUs
performance limits were detected and that new performance requests
were made by the on-demand governor proportional to the load on each
CPU. I also verified that using the acpi_processor driver correctly
maps the physical CPU ids to logical CPU ids, which helps in picking
up the proper _CPC details from a processor object, in the case where
CPU physical ids may not be contiguous.

Changes since V6:
- Separated PSS and CST from ACPI processor driver in two patches.
- Made new Kconfig symbols auto selectable from Arch Kconfigs.

Changes since V5:
- Checkpatch cleanups.
- Change pss_init to pss_perf_init. Rec by Srinivas Pandruvada.
- Explicit comment explaining why postcore_initcall to pcc mailbox.
- Fold acpi_processor_syscore_init/exit into CONFIG_ACPI_CST.
- Added patch with dummy functions used by ACPI_HOTPLUG_CPU.

Changes since V4:
- Misc cleanups. Addressed feedback from Rafael.
- Made acpi_processor.c independent of C-states, P-states and others.
- Per CPU scanning for _CPC is now made from acpi_processor.c
- Added new Kconfig options for legacy C states and P states to enable future
support for newer alternatives as defined in the ACPI spec 6.0.

Changes since V3:
- Split CPPC backend methods into separate files.
- Add frontend driver which plugs into existing CPUfreq governors.
- Simplify PCC driver by moving communication space mapping and read/write
	into client drivers.

Changes since V2:
- Select driver if !X86, since intel_pstate will use HWP extensions instead.
- Added more comments.
- Added Freq domain awareness and PSD parsing.

Changes since V1:
- Create a new driver based on Dirks suggestion.
- Fold in CPPC backend hooks into main driver.

Changes since V0: [1]
- Split intel_pstate.c into a generic PID governor and platform specific backend.
- Add CPPC accessors as PID backend.

[1] - http://lwn.net/Articles/608715/
[2] - http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf
[3] - https://patches.linaro.org/40705/


Ashwin Chaugule (8):
  PCC: Initialize PCC Mailbox earlier at boot
  ACPI: Split out ACPI PSS from ACPI Processor driver
  ACPI: Decouple ACPI idle and ACPI processor drivers
  ACPI: Introduce CPU performance controls using CPPC
  CPPC: Add a CPUFreq driver for use with CPPC
  ACPI: Add weak routines for ACPI CPU Hotplug
  CPPC: Probe for CPPC tables for each ACPI Processor object
  PCC: Enable PCC only when needed

 arch/arm64/Kconfig              |   1 +
 arch/x86/Kconfig                |   1 +
 drivers/acpi/Kconfig            |  41 +-
 drivers/acpi/Makefile           |   8 +-
 drivers/acpi/acpi_processor.c   |  18 +
 drivers/acpi/cppc_acpi.c        | 812 ++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/processor_driver.c |  90 +++--
 drivers/cpufreq/Kconfig         |   2 +-
 drivers/cpufreq/Kconfig.arm     |  16 +
 drivers/cpufreq/Kconfig.x86     |   2 +
 drivers/cpufreq/Makefile        |   2 +
 drivers/cpufreq/cppc_cpufreq.c  | 197 ++++++++++
 drivers/mailbox/Kconfig         |   2 +-
 drivers/mailbox/pcc.c           |   8 +-
 include/acpi/cppc_acpi.h        | 137 +++++++
 include/acpi/processor.h        | 129 +++++--
 16 files changed, 1392 insertions(+), 74 deletions(-)
 create mode 100644 drivers/acpi/cppc_acpi.c
 create mode 100644 drivers/cpufreq/cppc_cpufreq.c
 create mode 100644 include/acpi/cppc_acpi.h

-- 
1.9.1

[PATCH v7 1/8] PCC: Initialize PCC Mailbox earlier at boot

[Ashwin Chaugule]

This change initializes the PCC Mailbox earlier than
the ACPI processor driver. This enables drivers introduced
in follow up patches (e.g. CPPC) to be probed via the ACPI
processor driver interface. The CPPC probe requires the PCC
channel to be initialized for it to query each CPUs performance
capabilities.

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Reviewed-by: Al Stone <al.stone@linaro.org>
---
 drivers/mailbox/pcc.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 7e91d68..fcda63e 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -352,4 +352,10 @@ static int __init pcc_init(void)
 
 	return 0;
 }
-device_initcall(pcc_init);
+
+/*
+ * Make pcc init postcore so that users of this mailbox
+ * such as the ACPI Processor driver have it available
+ * at their init.
+ */
+postcore_initcall(pcc_init);
-- 
1.9.1

[PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Ashwin Chaugule]

The ACPI processor driver is currently tied too closely
to the ACPI P-states (PSS) and other related constructs
for controlling CPU performance.

The newer ACPI specification (v5.1 onwards) introduces
alternative methods to PSS. These new mechanisms are
described within each ACPI Processor object and so they
need to be scanned whenever a new Processor object is detected.
This patch introduces a new Kconfig symbol to allow for
finer configurability among the two options for controlling
performance states. There is no change in functionality and
the option is auto-selected by the architecture Kconfig files.

The following patchwork introduces CPPC: A newer method of
controlling CPU performance. The OS is not expected to support
CPPC and PSS at runtime. So the kconfig option lets us make
these two mutually exclusive at compile time.

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
---
 arch/x86/Kconfig                |  1 +
 drivers/acpi/Kconfig            | 19 ++++++---
 drivers/acpi/Makefile           |  6 +--
 drivers/acpi/processor_driver.c | 86 +++++++++++++++++++++++++------------
 drivers/cpufreq/Kconfig         |  2 +-
 drivers/cpufreq/Kconfig.x86     |  2 +
 include/acpi/processor.h        | 94 +++++++++++++++++++++++++++--------------
 7 files changed, 142 insertions(+), 68 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 226d569..93d150d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -143,6 +143,7 @@ config X86
 	select ACPI_LEGACY_TABLES_LOOKUP if ACPI
 	select X86_FEATURE_NAMES if PROC_FS
 	select SRCU
+	select ACPI_CPU_FREQ_PSS if ACPI
 
 config INSTRUCTION_DECODER
 	def_bool y
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ab2cbb5..00748dc 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -166,17 +166,26 @@ config ACPI_DOCK
 	  This driver supports ACPI-controlled docking stations and removable
 	  drive bays such as the IBM Ultrabay and the Dell Module Bay.
 
+config ACPI_CPU_FREQ_PSS
+	bool
+	depends on ACPI_PROCESSOR && CPU_FREQ
+	select THERMAL
+	help
+	  This driver implements ACPI methods for controlling CPU performance
+	  using PSS methods as described in the ACPI spec. It also enables support
+	  for ACPI based performance throttling (TSS) and ACPI based thermal
+	  monitoring. It is required by several flavors of cpufreq
+	  performance-state drivers.
+
 config ACPI_PROCESSOR
 	tristate "Processor"
-	select THERMAL
 	select CPU_IDLE
 	depends on X86 || IA64
 	default y
 	help
-	  This driver installs ACPI as the idle handler for Linux and uses
-	  ACPI C2 and C3 processor states to save power on systems that
-	  support it.  It is required by several flavors of cpufreq
-	  performance-state drivers.
+	  This driver adds support for the ACPI Processor package. It is required
+	  by several flavors of cpufreq performance-state, thermal, throttling and
+	  idle drivers.
 
 	  To compile this driver as a module, choose M here:
 	  the module will be called processor.
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 8a063e2..62e32bd 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -82,9 +82,9 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
 
 # processor has its own "processor." module_param namespace
-processor-y			:= processor_driver.o processor_throttling.o
-processor-y			+= processor_idle.o processor_thermal.o
-processor-$(CONFIG_CPU_FREQ)	+= processor_perflib.o
+processor-y			:= processor_driver.o processor_idle.o
+processor-$(CONFIG_ACPI_CPU_FREQ_PSS)	+= processor_perflib.o	\
+	processor_throttling.o processor_thermal.o
 
 obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
 
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index d9f7158..16d44ad 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -163,34 +163,24 @@ static struct notifier_block __refdata acpi_cpu_notifier = {
 	    .notifier_call = acpi_cpu_soft_notify,
 };
 
-static int __acpi_processor_start(struct acpi_device *device)
+#ifdef CONFIG_ACPI_CPU_FREQ_PSS
+static int acpi_pss_perf_init(struct acpi_processor *pr,
+		struct acpi_device *device)
 {
-	struct acpi_processor *pr = acpi_driver_data(device);
-	acpi_status status;
 	int result = 0;
 
-	if (!pr)
-		return -ENODEV;
-
-	if (pr->flags.need_hotplug_init)
-		return 0;
-
-#ifdef CONFIG_CPU_FREQ
 	acpi_processor_ppc_has_changed(pr, 0);
-#endif
+
 	acpi_processor_get_throttling_info(pr);
 
 	if (pr->flags.throttling)
 		pr->flags.limit = 1;
 
-	if (!cpuidle_get_driver() || cpuidle_get_driver() == &acpi_idle_driver)
-		acpi_processor_power_init(pr);
-
 	pr->cdev = thermal_cooling_device_register("Processor", device,
 						   &processor_cooling_ops);
 	if (IS_ERR(pr->cdev)) {
 		result = PTR_ERR(pr->cdev);
-		goto err_power_exit;
+		return result;
 	}
 
 	dev_dbg(&device->dev, "registered as cooling_device%d\n",
@@ -204,6 +194,7 @@ static int __acpi_processor_start(struct acpi_device *device)
 			"Failed to create sysfs link 'thermal_cooling'\n");
 		goto err_thermal_unregister;
 	}
+
 	result = sysfs_create_link(&pr->cdev->device.kobj,
 				   &device->dev.kobj,
 				   "device");
@@ -213,17 +204,61 @@ static int __acpi_processor_start(struct acpi_device *device)
 		goto err_remove_sysfs_thermal;
 	}
 
-	status = acpi_install_notify_handler(device->handle, ACPI_DEVICE_NOTIFY,
-					     acpi_processor_notify, device);
-	if (ACPI_SUCCESS(status))
-		return 0;
-
 	sysfs_remove_link(&pr->cdev->device.kobj, "device");
  err_remove_sysfs_thermal:
 	sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
  err_thermal_unregister:
 	thermal_cooling_device_unregister(pr->cdev);
- err_power_exit:
+
+	return result;
+}
+
+static void acpi_pss_perf_exit(struct acpi_processor *pr,
+		struct acpi_device *device)
+{
+	if (pr->cdev) {
+		sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
+		sysfs_remove_link(&pr->cdev->device.kobj, "device");
+		thermal_cooling_device_unregister(pr->cdev);
+		pr->cdev = NULL;
+	}
+}
+#else
+static inline int acpi_pss_perf_init(struct acpi_processor *pr,
+		struct acpi_device *device)
+{
+	return 0;
+}
+
+static inline void acpi_pss_perf_exit(struct acpi_processor *pr,
+		struct acpi_device *device) {}
+#endif /* CONFIG_ACPI_CPU_FREQ_PSS */
+
+static int __acpi_processor_start(struct acpi_device *device)
+{
+	struct acpi_processor *pr = acpi_driver_data(device);
+	acpi_status status;
+	int result = 0;
+
+	if (!pr)
+		return -ENODEV;
+
+	if (pr->flags.need_hotplug_init)
+		return 0;
+
+	if (!cpuidle_get_driver() || cpuidle_get_driver() == &acpi_idle_driver)
+		acpi_processor_power_init(pr);
+
+	result = acpi_pss_perf_init(pr, device);
+	if (result)
+		goto err_power_exit;
+
+	status = acpi_install_notify_handler(device->handle, ACPI_DEVICE_NOTIFY,
+					     acpi_processor_notify, device);
+	if (ACPI_SUCCESS(status))
+		return 0;
+
+err_power_exit:
 	acpi_processor_power_exit(pr);
 	return result;
 }
@@ -252,15 +287,10 @@ static int acpi_processor_stop(struct device *dev)
 	pr = acpi_driver_data(device);
 	if (!pr)
 		return 0;
-
 	acpi_processor_power_exit(pr);
 
-	if (pr->cdev) {
-		sysfs_remove_link(&device->dev.kobj, "thermal_cooling");
-		sysfs_remove_link(&pr->cdev->device.kobj, "device");
-		thermal_cooling_device_unregister(pr->cdev);
-		pr->cdev = NULL;
-	}
+	acpi_pss_perf_exit(pr, device);
+
 	return 0;
 }
 
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 659879a..0aba0e6 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -223,7 +223,7 @@ endif
 if IA64
 config IA64_ACPI_CPUFREQ
 	tristate "ACPI Processor P-States driver"
-	depends on ACPI_PROCESSOR
+	depends on ACPI_PROCESSOR && ACPI_CPU_FREQ_PSS
 	help
 	This driver adds a CPUFreq driver which utilizes the ACPI
 	Processor Performance States.
diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index c59bdcb..e24388a 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -18,6 +18,7 @@ config X86_INTEL_PSTATE
 config X86_PCC_CPUFREQ
 	tristate "Processor Clocking Control interface driver"
 	depends on ACPI && ACPI_PROCESSOR
+	depends on ACPI_CPU_FREQ_PSS
 	help
 	  This driver adds support for the PCC interface.
 
@@ -32,6 +33,7 @@ config X86_PCC_CPUFREQ
 config X86_ACPI_CPUFREQ
 	tristate "ACPI Processor P-States driver"
 	depends on ACPI_PROCESSOR
+	depends on ACPI_CPU_FREQ_PSS
 	help
 	  This driver adds a CPUFreq driver which utilizes the ACPI
 	  Processor Performance States.
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 4188a4d..bedcab3 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -222,16 +222,6 @@ struct acpi_processor_errata {
 	} piix4;
 };
 
-extern int acpi_processor_preregister_performance(struct
-						  acpi_processor_performance
-						  __percpu *performance);
-
-extern int acpi_processor_register_performance(struct acpi_processor_performance
-					       *performance, unsigned int cpu);
-extern void acpi_processor_unregister_performance(struct
-						  acpi_processor_performance
-						  *performance,
-						  unsigned int cpu);
 
 /* note: this locks both the calling module and the processor module
          if a _PPC object exists, rmmod is disallowed then */
@@ -267,28 +257,52 @@ static inline int acpi_processor_ffh_cstate_probe(unsigned int cpu,
 	return -1;
 }
 static inline void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx
-						   *cstate)
-{
-	return;
-}
+						   *cstate) {}
 #endif
 
 /* in processor_perflib.c */
 
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ACPI_CPU_FREQ_PSS
+extern int acpi_processor_preregister_performance(struct
+						  acpi_processor_performance
+						  __percpu *performance);
+
+extern int acpi_processor_register_performance(struct acpi_processor_performance
+					       *performance, unsigned int cpu);
+extern void acpi_processor_unregister_performance(struct
+						  acpi_processor_performance
+						  *performance,
+						  unsigned int cpu);
 void acpi_processor_ppc_init(void);
 void acpi_processor_ppc_exit(void);
 int acpi_processor_ppc_has_changed(struct acpi_processor *pr, int event_flag);
 extern int acpi_processor_get_bios_limit(int cpu, unsigned int *limit);
 #else
-static inline void acpi_processor_ppc_init(void)
+static inline int acpi_processor_preregister_performance(struct
+		acpi_processor_performance
+		__percpu *performance)
 {
-	return;
+	return -ENODEV;
+
 }
-static inline void acpi_processor_ppc_exit(void)
+
+static inline int acpi_processor_register_performance(struct
+		acpi_processor_performance
+		*performance, unsigned int cpu)
 {
-	return;
+	return -ENODEV;
+
 }
+
+static inline void acpi_processor_unregister_performance(struct
+		acpi_processor_performance
+		*performance,
+		unsigned int cpu) {}
+
+static inline void acpi_processor_ppc_init(void) {}
+
+static inline void acpi_processor_ppc_exit(void) {}
+
 static inline int acpi_processor_ppc_has_changed(struct acpi_processor *pr,
 								int event_flag)
 {
@@ -302,12 +316,12 @@ static inline int acpi_processor_ppc_has_changed(struct acpi_processor *pr,
 	}
 	return 0;
 }
+
 static inline int acpi_processor_get_bios_limit(int cpu, unsigned int *limit)
 {
 	return -ENODEV;
 }
-
-#endif				/* CONFIG_CPU_FREQ */
+#endif	/* CONFIG_ACPI_CPU_FREQ_PSS */
 
 /* in processor_core.c */
 phys_cpuid_t acpi_get_phys_id(acpi_handle, int type, u32 acpi_id);
@@ -318,6 +332,7 @@ int acpi_get_cpuid(acpi_handle, int type, u32 acpi_id);
 void acpi_processor_set_pdc(acpi_handle handle);
 
 /* in processor_throttling.c */
+#ifdef CONFIG_ACPI_CPU_FREQ_PSS
 int acpi_processor_tstate_has_changed(struct acpi_processor *pr);
 int acpi_processor_get_throttling_info(struct acpi_processor *pr);
 extern int acpi_processor_set_throttling(struct acpi_processor *pr,
@@ -330,6 +345,29 @@ extern void acpi_processor_reevaluate_tstate(struct acpi_processor *pr,
 			unsigned long action);
 extern const struct file_operations acpi_processor_throttling_fops;
 extern void acpi_processor_throttling_init(void);
+#else
+static inline int acpi_processor_tstate_has_changed(struct acpi_processor *pr)
+{
+	return 0;
+}
+
+static inline int acpi_processor_get_throttling_info(struct acpi_processor *pr)
+{
+	return -ENODEV;
+}
+
+static inline int acpi_processor_set_throttling(struct acpi_processor *pr,
+					 int state, bool force)
+{
+	return -ENODEV;
+}
+
+static inline void acpi_processor_reevaluate_tstate(struct acpi_processor *pr,
+			unsigned long action) {}
+
+static inline void acpi_processor_throttling_init(void) {}
+#endif	/* CONFIG_ACPI_CPU_FREQ_PSS */
+
 /* in processor_idle.c */
 int acpi_processor_power_init(struct acpi_processor *pr);
 int acpi_processor_power_exit(struct acpi_processor *pr);
@@ -347,19 +385,13 @@ static inline void acpi_processor_syscore_exit(void) {}
 
 /* in processor_thermal.c */
 int acpi_processor_get_limit_info(struct acpi_processor *pr);
+#ifdef CONFIG_ACPI_CPU_FREQ_PSS
 extern const struct thermal_cooling_device_ops processor_cooling_ops;
-#ifdef CONFIG_CPU_FREQ
 void acpi_thermal_cpufreq_init(void);
 void acpi_thermal_cpufreq_exit(void);
 #else
-static inline void acpi_thermal_cpufreq_init(void)
-{
-	return;
-}
-static inline void acpi_thermal_cpufreq_exit(void)
-{
-	return;
-}
-#endif
+static inline void acpi_thermal_cpufreq_init(void) {}
+static inline void acpi_thermal_cpufreq_exit(void) {}
+#endif	/* CONFIG_ACPI_CPU_FREQ_PSS */
 
 #endif
-- 
1.9.1

[PATCH v7 3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

[Ashwin Chaugule]

This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE,
which is auto selected by architectures which support the ACPI
based C states for CPU Idle management.

The processor_idle driver in its present form contains declarations
specific to X86 and IA64. Since there are no reasonable defaults
for other architectures e.g. ARM64, the driver is selected only by
the arch/x86/Kconfig.

This helps in decoupling the ACPI processor_driver from the ACPI
processor_idle driver which is useful for the upcoming alternative
patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI).

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
---
 drivers/acpi/Kconfig     |  6 +++++-
 drivers/acpi/Makefile    |  3 ++-
 include/acpi/processor.h | 26 ++++++++++++++++++++++++--
 3 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 00748dc..8a60b6e 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -177,9 +177,13 @@ config ACPI_CPU_FREQ_PSS
 	  monitoring. It is required by several flavors of cpufreq
 	  performance-state drivers.
 
+config ACPI_PROCESSOR_IDLE
+	def_bool y
+	depends on X86 || IA64
+
 config ACPI_PROCESSOR
 	tristate "Processor"
-	select CPU_IDLE
+	select CPU_IDLE if ACPI_PROCESSOR_IDLE
 	depends on X86 || IA64
 	default y
 	help
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 62e32bd..0633af6 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -82,7 +82,8 @@ obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
 
 # processor has its own "processor." module_param namespace
-processor-y			:= processor_driver.o processor_idle.o
+processor-y			:= processor_driver.o
+processor-$(CONFIG_ACPI_PROCESSOR_IDLE)	+= processor_idle.o
 processor-$(CONFIG_ACPI_CPU_FREQ_PSS)	+= processor_perflib.o	\
 	processor_throttling.o processor_thermal.o
 
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index bedcab3..c071a92 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -369,13 +369,35 @@ static inline void acpi_processor_throttling_init(void) {}
 #endif	/* CONFIG_ACPI_CPU_FREQ_PSS */
 
 /* in processor_idle.c */
+extern struct cpuidle_driver acpi_idle_driver;
+#ifdef CONFIG_ACPI_PROCESSOR_IDLE
 int acpi_processor_power_init(struct acpi_processor *pr);
 int acpi_processor_power_exit(struct acpi_processor *pr);
 int acpi_processor_cst_has_changed(struct acpi_processor *pr);
 int acpi_processor_hotplug(struct acpi_processor *pr);
-extern struct cpuidle_driver acpi_idle_driver;
+#else
+static inline int acpi_processor_power_init(struct acpi_processor *pr)
+{
+	return -ENODEV;
+}
+
+static inline int acpi_processor_power_exit(struct acpi_processor *pr)
+{
+	return -ENODEV;
+}
+
+static inline int acpi_processor_cst_has_changed(struct acpi_processor *pr)
+{
+	return -ENODEV;
+}
+
+static inline int acpi_processor_hotplug(struct acpi_processor *pr)
+{
+	return -ENODEV;
+}
+#endif /* CONFIG_ACPI_PROCESSOR_IDLE */
 
-#ifdef CONFIG_PM_SLEEP
+#if defined(CONFIG_PM_SLEEP) & defined(CONFIG_ACPI_PROCESSOR_IDLE)
 void acpi_processor_syscore_init(void);
 void acpi_processor_syscore_exit(void);
 #else
-- 
1.9.1

[PATCH v7 4/8] ACPI: Introduce CPU performance controls using CPPC

[Ashwin Chaugule]

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 adds a shim which exports commonly used functions
to get and set CPPC specific controls for each CPU. This enables
CPUFreq drivers to gather per CPU performance data and use
with exisiting governors or even allows for customized governors
which are implemented inside CPUFreq drivers.

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Reviewed-by: Al Stone <al.stone@linaro.org>
---
 drivers/acpi/Kconfig     |  14 +
 drivers/acpi/Makefile    |   1 +
 drivers/acpi/cppc_acpi.c | 812 +++++++++++++++++++++++++++++++++++++++++++++++
 include/acpi/cppc_acpi.h | 137 ++++++++
 4 files changed, 964 insertions(+)
 create mode 100644 drivers/acpi/cppc_acpi.c
 create mode 100644 include/acpi/cppc_acpi.h

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 8a60b6e..54d73bb 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -181,6 +181,20 @@ config ACPI_PROCESSOR_IDLE
 	def_bool y
 	depends on X86 || IA64
 
+config ACPI_CPPC_LIB
+	bool
+	depends on ACPI_PROCESSOR
+	depends on !ACPI_CPU_FREQ_PSS
+	select MAILBOX
+	select PCC
+	help
+	  This file implements common functionality to parse
+	  CPPC tables as described in the ACPI 5.1+ spec. The
+	  routines implemented are meant to be used by other
+	  drivers to control CPU performance using CPPC semantics.
+	  If your platform does not support CPPC in firmware,
+	  leave this option disabled.
+
 config ACPI_PROCESSOR
 	tristate "Processor"
 	select CPU_IDLE if ACPI_PROCESSOR_IDLE
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0633af6..da520cb 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_ACPI_HED)		+= hed.o
 obj-$(CONFIG_ACPI_EC_DEBUGFS)	+= ec_sys.o
 obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
 obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
+obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
 
 # processor has its own "processor." module_param namespace
 processor-y			:= processor_driver.o
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
new file mode 100644
index 0000000..9c89767
--- /dev/null
+++ b/drivers/acpi/cppc_acpi.c
@@ -0,0 +1,812 @@
+/*
+ * CPPC (Collaborative Processor Performance Control) methods used
+ * by CPUfreq drivers.
+ *
+ * (C) Copyright 2014, 2015 Linaro Ltd.
+ * Author: Ashwin Chaugule <ashwin.chaugule@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ *
+ * CPPC describes a few methods for controlling CPU performance using
+ * information from a per CPU table called CPC. This table is described in
+ * the ACPI v5.0+ specification. The table consists of a list of
+ * registers which may be memory mapped or hardware registers and also may
+ * include some static integer values.
+ *
+ * CPU performance is on an abstract continuous scale as against a discretized
+ * P-state scale which is tied to CPU frequency only. In brief, the basic
+ * operation involves:
+ *
+ * - OS makes a CPU performance request. (Can provide min and max bounds)
+ *
+ * - Platform (such as BMC) is free to optimize request within requested bounds
+ *   depending on power/thermal budgets etc.
+ *
+ * - Platform conveys its decision back to OS
+ *
+ * The communication between OS and platform occurs through another medium
+ * called (PCC) Platform Communication Channel. This is a generic mailbox like
+ * mechanism which includes doorbell semantics to indicate register updates.
+ * See drivers/mailbox/pcc.c for details on PCC.
+ *
+ * Finer details about the PCC and CPPC spec are available in the latest
+ * ACPI 5.1 specification.
+ */
+
+#define pr_fmt(fmt)	"ACPI CPPC: " fmt
+
+#include <linux/cpufreq.h>
+#include <linux/delay.h>
+
+#include <acpi/cppc_acpi.h>
+/*
+ * Lock to provide mutually exclusive access to the PCC
+ * channel. e.g. When the remote updates the shared region
+ * with new data, the reader needs to be protected from
+ * other CPUs activity on the same channel.
+ */
+static DEFINE_SPINLOCK(pcc_lock);
+
+static DEFINE_PER_CPU(struct cpc_desc *, cpc_desc_ptr);
+
+/* This layer handles all the PCC specifics for CPPC. */
+static struct mbox_chan *pcc_channel;
+static void __iomem *pcc_comm_addr;
+static u64 comm_base_addr;
+static int pcc_subspace_idx = -1;
+static u16 pcc_cmd_delay;
+static int pcc_channel_acquired;
+
+#define NUM_RETRIES 500
+
+static int send_pcc_cmd(u16 cmd)
+{
+	int err, result = 0;
+	int retries = NUM_RETRIES;
+	struct acpi_pcct_hw_reduced *pcct_ss = pcc_channel->con_priv;
+	struct acpi_pcct_shared_memory *generic_comm_base =
+		(struct acpi_pcct_shared_memory *) pcc_comm_addr;
+	u32 cmd_latency = pcct_ss->latency;
+
+	/* Write to the shared comm region. */
+	writew(cmd, &generic_comm_base->command);
+
+	/* Flip CMD COMPLETE bit */
+	writew(0, &generic_comm_base->status);
+
+	err = mbox_send_message(pcc_channel, &cmd);
+	if (err < 0) {
+		pr_err("Err sending PCC mbox message. cmd:%d, ret:%d\n",
+				cmd, err);
+		return err;
+	}
+
+	/* Wait for a nominal time to let platform processes command. */
+	udelay(cmd_latency);
+
+	/* Retry in case the remote processor was too slow to catch up. */
+	while (retries--) {
+		result = readw_relaxed(&generic_comm_base->status)
+			& PCC_CMD_COMPLETE ? 0 : -EIO;
+		if (!result) {
+			/* Success. */
+			retries = NUM_RETRIES;
+			break;
+		}
+	}
+
+	mbox_client_txdone(pcc_channel, result);
+	return result;
+}
+
+static void cppc_chan_tx_done(struct mbox_client *cl, void *mssg, int ret)
+{
+	if (ret)
+		pr_debug("TX did not complete: CMD sent:%x, ret:%d\n",
+				*(u16 *)mssg, ret);
+	else
+		pr_debug("TX completed. CMD sent:%x, ret:%d\n",
+				*(u16 *)mssg, ret);
+}
+
+struct mbox_client cppc_mbox_cl = {
+	.tx_done = cppc_chan_tx_done,
+	.knows_txdone = true,
+};
+
+static int acpi_get_psd(struct cpc_desc *cpc_ptr, acpi_handle handle)
+{
+	int result = 0;
+	acpi_status status = AE_OK;
+	struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
+	struct acpi_buffer format = {sizeof("NNNNN"), "NNNNN"};
+	struct acpi_buffer state = {0, NULL};
+	union acpi_object  *psd = NULL;
+	struct acpi_psd_package *pdomain;
+
+	status = acpi_evaluate_object(handle, "_PSD", NULL, &buffer);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	psd = buffer.pointer;
+	if (!psd || (psd->type != ACPI_TYPE_PACKAGE)) {
+		pr_err("Invalid _PSD data\n");
+		result = -ENODATA;
+		goto end;
+	}
+
+	if (psd->package.count != 1) {
+		pr_err("Invalid _PSD data\n");
+		result = -ENODATA;
+		goto end;
+	}
+
+	pdomain = &(cpc_ptr->domain_info);
+
+	state.length = sizeof(struct acpi_psd_package);
+	state.pointer = pdomain;
+
+	status = acpi_extract_package(&(psd->package.elements[0]),
+		&format, &state);
+	if (ACPI_FAILURE(status)) {
+		pr_err("Invalid _PSD data\n");
+		result = -ENODATA;
+		goto end;
+	}
+
+	if (pdomain->num_entries != ACPI_PSD_REV0_ENTRIES) {
+		pr_err("Unknown _PSD:num_entries\n");
+		result = -ENODATA;
+		goto end;
+	}
+
+	if (pdomain->revision != ACPI_PSD_REV0_REVISION) {
+		pr_err("Unknown _PSD:revision\n");
+		result = -ENODATA;
+		goto end;
+	}
+
+	if (pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ALL &&
+	    pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ANY &&
+	    pdomain->coord_type != DOMAIN_COORD_TYPE_HW_ALL) {
+		pr_err("Invalid _PSD:coord_type\n");
+		result = -ENODATA;
+		goto end;
+	}
+end:
+	kfree(buffer.pointer);
+	return result;
+}
+
+int acpi_get_psd_map(struct cpudata **all_cpu_data)
+{
+	int count_target;
+	int retval = 0;
+	unsigned int i, j;
+	cpumask_var_t covered_cpus;
+	struct cpudata *pr, *match_pr;
+	struct acpi_psd_package *pdomain;
+	struct acpi_psd_package *match_pdomain;
+	struct cpc_desc *cpc_ptr, *match_cpc_ptr;
+
+	if (!zalloc_cpumask_var(&covered_cpus, GFP_KERNEL))
+		return -ENOMEM;
+
+	/*
+	 * Now that we have _PSD data from all CPUs, lets setup P-state
+	 * domain info.
+	 */
+	for_each_possible_cpu(i) {
+		pr = all_cpu_data[i];
+		if (!pr)
+			continue;
+
+		if (cpumask_test_cpu(i, covered_cpus))
+			continue;
+
+		cpc_ptr = per_cpu(cpc_desc_ptr, i);
+		if (!cpc_ptr)
+			continue;
+
+		pdomain = &(cpc_ptr->domain_info);
+		cpumask_set_cpu(i, pr->shared_cpu_map);
+		cpumask_set_cpu(i, covered_cpus);
+		if (pdomain->num_processors <= 1)
+			continue;
+
+		/* Validate the Domain info */
+		count_target = pdomain->num_processors;
+		if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ALL)
+			pr->shared_type = CPUFREQ_SHARED_TYPE_ALL;
+		else if (pdomain->coord_type == DOMAIN_COORD_TYPE_HW_ALL)
+			pr->shared_type = CPUFREQ_SHARED_TYPE_HW;
+		else if (pdomain->coord_type == DOMAIN_COORD_TYPE_SW_ANY)
+			pr->shared_type = CPUFREQ_SHARED_TYPE_ANY;
+
+		for_each_possible_cpu(j) {
+			if (i == j)
+				continue;
+
+			match_cpc_ptr = per_cpu(cpc_desc_ptr, j);
+			if (!match_cpc_ptr)
+				continue;
+
+			match_pdomain = &(match_cpc_ptr->domain_info);
+			if (match_pdomain->domain != pdomain->domain)
+				continue;
+
+			/* Here i and j are in the same domain */
+
+			if (match_pdomain->num_processors != count_target) {
+				retval = -EINVAL;
+				goto err_ret;
+			}
+
+			if (pdomain->coord_type != match_pdomain->coord_type) {
+				retval = -EINVAL;
+				goto err_ret;
+			}
+
+			cpumask_set_cpu(j, covered_cpus);
+			cpumask_set_cpu(j, pr->shared_cpu_map);
+		}
+
+		for_each_possible_cpu(j) {
+			if (i == j)
+				continue;
+
+			match_pr = all_cpu_data[j];
+			if (!match_pr)
+				continue;
+
+			match_cpc_ptr = per_cpu(cpc_desc_ptr, j);
+			if (!match_cpc_ptr)
+				continue;
+
+			match_pdomain = &(match_cpc_ptr->domain_info);
+			if (match_pdomain->domain != pdomain->domain)
+				continue;
+
+			match_pr->shared_type = pr->shared_type;
+			cpumask_copy(match_pr->shared_cpu_map,
+				     pr->shared_cpu_map);
+		}
+	}
+
+err_ret:
+	for_each_possible_cpu(i) {
+		pr = all_cpu_data[i];
+		if (!pr)
+			continue;
+
+		/* Assume no coordination on any error parsing domain info */
+		if (retval) {
+			cpumask_clear(pr->shared_cpu_map);
+			cpumask_set_cpu(i, pr->shared_cpu_map);
+			pr->shared_type = CPUFREQ_SHARED_TYPE_ALL;
+		}
+	}
+
+	free_cpumask_var(covered_cpus);
+	return retval;
+}
+EXPORT_SYMBOL_GPL(acpi_get_psd_map);
+
+static int register_pcc_channel(unsigned pcc_subspace_idx)
+{
+	struct acpi_pcct_subspace *cppc_ss;
+	unsigned int len;
+
+	if (pcc_subspace_idx >= 0) {
+		pcc_channel = pcc_mbox_request_channel(&cppc_mbox_cl,
+				pcc_subspace_idx);
+
+		if (IS_ERR(pcc_channel)) {
+			pr_err("No PCC communication channel found\n");
+			return -ENODEV;
+		}
+
+		/*
+		 * The PCC mailbox controller driver should
+		 * have parsed the PCCT (global table of all
+		 * PCC channels) and stored pointers to the
+		 * subspace communication region in con_priv.
+		 */
+		cppc_ss = pcc_channel->con_priv;
+
+		if (!cppc_ss) {
+			pr_err("No PCC subspace found for CPPC\n");
+			return -ENODEV;
+		}
+
+		/*
+		 * This is the shared communication region
+		 * for the OS and Platform to communicate over.
+		 */
+		comm_base_addr = cppc_ss->base_address;
+		len = cppc_ss->length;
+		pcc_cmd_delay = cppc_ss->min_turnaround_time;
+
+		pcc_comm_addr = ioremap(comm_base_addr, len);
+		if (!pcc_comm_addr) {
+			pr_err("Failed to ioremap PCC comm region mem\n");
+			return -ENOMEM;
+		}
+
+		/* Set flag so that we dont come here for each CPU. */
+		pcc_channel_acquired = 1;
+
+	} else
+		/*
+		 * For the case where registers are not defined as PCC regs.
+		 * Assuming all regs are FFH / SystemIO.
+		 */
+		pr_debug("No PCC subspace detected in any CPC entries.\n");
+
+	return 0;
+}
+
+/**
+ * acpi_cppc_processor_probe - The _CPC table is a per CPU table
+ * which a bunch of entries which may be registers or integers.
+ * An example table looks like the following.
+ *
+ *	Name(_CPC, Package()
+ *			{
+ *			17,
+ *			NumEntries
+ *			1,
+ *			// Revision
+ *			ResourceTemplate(){Register(PCC, 32, 0, 0x120, 2)},
+ *			// Highest Performance
+ *			ResourceTemplate(){Register(PCC, 32, 0, 0x124, 2)},
+ *			// Nominal Performance
+ *			ResourceTemplate(){Register(PCC, 32, 0, 0x128, 2)},
+ *			// Lowest Nonlinear Performance
+ *			ResourceTemplate(){Register(PCC, 32, 0, 0x12C, 2)},
+ *			// Lowest Performance
+ *			ResourceTemplate(){Register(PCC, 32, 0, 0x130, 2)},
+ *			// Guaranteed Performance Register
+ *			ResourceTemplate(){Register(PCC, 32, 0, 0x110, 2)},
+ *			// Desired Performance Register
+ *			ResourceTemplate(){Register(SystemMemory, 0, 0, 0, 0)},
+ *			..
+ *			..
+ *			..
+ *
+ *		}
+ * Each Register() encodes how to access that specific register.
+ * e.g. a sample PCC entry has the following encoding:
+ *
+ *	Register (
+ *		PCC,
+ *		AddressSpaceKeyword
+ *		8,
+ *		//RegisterBitWidth
+ *		8,
+ *		//RegisterBitOffset
+ *		0x30,
+ *		//RegisterAddress
+ *		9
+ *		//AccessSize (subspace ID)
+ *		0
+ *		)
+ *		}
+ *
+ *	This function walks through all the per CPU _CPC entries and extracts
+ *	the Register details.
+ *
+ *	Return: 0 for success or negative value for err.
+ */
+int acpi_cppc_processor_probe(struct acpi_processor *pr)
+{
+	struct acpi_buffer output = {ACPI_ALLOCATE_BUFFER, NULL};
+	union acpi_object *out_obj, *cpc_obj;
+	struct cpc_desc *cpc_ptr;
+	struct cpc_reg *gas_t;
+	acpi_handle handle = pr->handle;
+	unsigned int num_ent, i, cpc_rev, ret = 0;
+	acpi_status status;
+
+	/* Parse the ACPI _CPC table for this cpu. */
+	if (!acpi_has_method(handle, "_CPC")) {
+		pr_debug("_CPC table not found\n");
+		ret = -ENODEV;
+		goto out_buf_free;
+	}
+
+	status = acpi_evaluate_object(handle, "_CPC", NULL, &output);
+	if (ACPI_FAILURE(status)) {
+		ret = -ENODEV;
+		goto out_buf_free;
+	}
+
+	out_obj = (union acpi_object *) output.pointer;
+	if (out_obj->type != ACPI_TYPE_PACKAGE) {
+		ret = -ENODEV;
+		goto out_buf_free;
+	}
+
+	cpc_ptr = kzalloc(sizeof(struct cpc_desc), GFP_KERNEL);
+	if (!cpc_ptr)
+		return -ENOMEM;
+
+	/* First entry is NumEntries. */
+	cpc_obj = &out_obj->package.elements[0];
+	if (cpc_obj->type == ACPI_TYPE_INTEGER)	{
+		num_ent = cpc_obj->integer.value;
+	} else {
+		pr_debug("Unexpected entry type(%d) for NumEntries\n",
+				cpc_obj->type);
+		goto out_free;
+	}
+
+	/* Only support CPPCv2. Bail otherwise. */
+	if (num_ent != CPPC_NUM_ENT) {
+		pr_err("Firmware exports %d entries. Expected: %d\n",
+				num_ent, CPPC_NUM_ENT);
+		ret = -EINVAL;
+		goto out_free;
+	}
+
+	/* Second entry should be revision. */
+	cpc_obj = &out_obj->package.elements[1];
+	if (cpc_obj->type == ACPI_TYPE_INTEGER)	{
+		cpc_rev = cpc_obj->integer.value;
+	} else {
+		pr_debug("Unexpected entry type(%d) for Revision\n",
+				cpc_obj->type);
+		goto out_free;
+	}
+
+	if (cpc_rev != CPPC_REV) {
+		pr_err("Firmware exports revision:%d. Expected:%d\n",
+				cpc_rev, CPPC_REV);
+		goto out_free;
+	}
+
+	/* Iterate through remaining entries in _CPC */
+	for (i = 2; i < num_ent; i++) {
+		cpc_obj = &out_obj->package.elements[i];
+
+		if (cpc_obj->type == ACPI_TYPE_INTEGER)	{
+			cpc_ptr->cpc_regs[i-2].type =
+				ACPI_TYPE_INTEGER;
+			cpc_ptr->cpc_regs[i-2].cpc_entry.int_value =
+				cpc_obj->integer.value;
+		} else if (cpc_obj->type == ACPI_TYPE_BUFFER) {
+			gas_t = (struct cpc_reg *)
+				cpc_obj->buffer.pointer;
+
+			/*
+			 * The PCC Subspace index is encoded inside
+			 * the CPC table entries. The same PCC index
+			 * will be used for all the PCC entries,
+			 * so extract it only once.
+			 */
+			if (gas_t->space_id ==
+					ACPI_ADR_SPACE_PLATFORM_COMM) {
+				if (pcc_subspace_idx < 0)
+					pcc_subspace_idx =
+						gas_t->access_width;
+				else if (pcc_subspace_idx !=
+						gas_t->access_width) {
+					/*
+					 * Mismatched PCC id detected.
+					 * Firmware bug.
+					 */
+					goto out_free;
+				}
+			}
+
+			cpc_ptr->cpc_regs[i-2].type =
+				ACPI_TYPE_BUFFER;
+			cpc_ptr->cpc_regs[i-2].cpc_entry.reg =
+				(struct cpc_reg) {
+					.space_id = gas_t->space_id,
+					.length	= gas_t->length,
+					.bit_width = gas_t->bit_width,
+					.bit_offset = gas_t->bit_offset,
+					.address = gas_t->address,
+					.access_width =
+						gas_t->access_width,
+				};
+		} else {
+			pr_debug("Error in entry:%d in CPC table.\n", i);
+			ret = -EINVAL;
+			goto out_free;
+		}
+	}
+
+	/* Plug it into this CPUs CPC descriptor. */
+	per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr;
+
+	/* Parse PSD data for this CPU */
+	ret = acpi_get_psd(cpc_ptr, handle);
+	if (ret)
+		goto out_free;
+
+	/* Register PCC channel once for all CPUs. */
+	if (!pcc_channel_acquired) {
+		ret = register_pcc_channel(pcc_subspace_idx);
+		if (ret)
+			goto out_free;
+	}
+
+	/* Everything looks okay */
+	pr_info("Successfully parsed CPC struct for CPU: %d\n", pr->id);
+
+	kfree(output.pointer);
+	return 0;
+
+out_free:
+	cpc_ptr = per_cpu(cpc_desc_ptr, pr->id);
+	kfree(cpc_ptr);
+
+out_buf_free:
+	kfree(output.pointer);
+	return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(acpi_cppc_processor_probe);
+
+static u64 cpc_trans(struct cpc_register_resource *reg, int cmd, u64 write_val,
+		bool is_pcc)
+{
+	u64 addr;
+	u64 read_val = 0;
+
+	/* PCC communication addr space begins at byte offset 0x8. */
+	addr = is_pcc ? (u64)pcc_comm_addr + 0x8 + reg->cpc_entry.reg.address :
+		reg->cpc_entry.reg.address;
+
+	if (reg->type == ACPI_TYPE_BUFFER) {
+		switch (reg->cpc_entry.reg.bit_width) {
+		case 8:
+			if (cmd == CMD_READ)
+				read_val = readb((void *) (addr));
+			else if (cmd == CMD_WRITE)
+				writeb(write_val, (void *)(addr));
+			else
+				pr_debug("Unsupported cmd type: %d\n", cmd);
+			break;
+		case 16:
+			if (cmd == CMD_READ)
+				read_val = readw((void *) (addr));
+			else if (cmd == CMD_WRITE)
+				writew(write_val, (void *)(addr));
+			else
+				pr_debug("Unsupported cmd type: %d\n", cmd);
+			break;
+		case 32:
+			if (cmd == CMD_READ)
+				read_val = readl((void *) (addr));
+			else if (cmd == CMD_WRITE)
+				writel(write_val, (void *)(addr));
+			else
+				pr_debug("Unsupported cmd type: %d\n", cmd);
+			break;
+		case 64:
+			if (cmd == CMD_READ)
+				read_val = readq((void *) (addr));
+			else if (cmd == CMD_WRITE)
+				writeq(write_val, (void *)(addr));
+			else
+				pr_debug("Unsupported cmd type: %d\n", cmd);
+			break;
+		default:
+			pr_debug("Unsupported bit width for CPC cmd:%d\n",
+					cmd);
+			break;
+		}
+	} else if (reg->type == ACPI_TYPE_INTEGER) {
+		if (cmd == CMD_READ)
+			read_val = reg->cpc_entry.int_value;
+		else if (cmd == CMD_WRITE)
+			reg->cpc_entry.int_value = write_val;
+		else
+			pr_debug("Unsupported cmd type: %d\n", cmd);
+	} else
+		pr_debug("Unsupported CPC entry type:%d\n", reg->type);
+
+	return read_val;
+}
+
+/**
+ * cppc_get_perf_caps - Get a CPUs performance capabilities.
+ * @cpunum: CPU from which to get capabilities info.
+ * @perf_caps: ptr to cppc_perf_caps. See cppc_acpi.h
+ *
+ * Return - 0 for success with perf_caps populated else
+ *	-ERRNO.
+ */
+int cppc_get_perf_caps(int cpunum, struct cppc_perf_caps *perf_caps)
+{
+	struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpunum);
+	struct cpc_register_resource *highest_reg, *lowest_reg, *ref_perf,
+				     *nom_perf;
+	u64 min, max, ref, nom;
+	bool is_pcc = false;
+	int ret;
+
+	if (!cpc_desc) {
+		pr_debug("No CPC descriptor for CPU:%d\n", cpunum);
+		return -ENODEV;
+	}
+
+	highest_reg = &cpc_desc->cpc_regs[HIGHEST_PERF];
+	lowest_reg = &cpc_desc->cpc_regs[LOWEST_PERF];
+	ref_perf = &cpc_desc->cpc_regs[REFERENCE_PERF];
+	nom_perf = &cpc_desc->cpc_regs[NOMINAL_PERF];
+
+	spin_lock(&pcc_lock);
+
+	/* Are any of the regs PCC ?*/
+	if ((highest_reg->cpc_entry.reg.space_id ==
+				ACPI_ADR_SPACE_PLATFORM_COMM) ||
+			(lowest_reg->cpc_entry.reg.space_id ==
+			 ACPI_ADR_SPACE_PLATFORM_COMM) ||
+			(ref_perf->cpc_entry.reg.space_id ==
+			 ACPI_ADR_SPACE_PLATFORM_COMM) ||
+			(nom_perf->cpc_entry.reg.space_id ==
+			 ACPI_ADR_SPACE_PLATFORM_COMM))
+		is_pcc = true;
+
+	if (is_pcc) {
+		/*
+		 * Min time OS should wait before sending
+		 * next command.
+		 */
+		udelay(pcc_cmd_delay);
+		/* Ring doorbell */
+		ret = send_pcc_cmd(CMD_READ);
+		if (ret) {
+			spin_unlock(&pcc_lock);
+			return -EIO;
+		}
+	}
+
+	max = cpc_trans(highest_reg, CMD_READ, 0, is_pcc);
+	perf_caps->highest_perf = max;
+
+	min = cpc_trans(lowest_reg, CMD_READ, 0, is_pcc);
+	perf_caps->lowest_perf = min;
+
+	ref = cpc_trans(ref_perf, CMD_READ, 0, is_pcc);
+	perf_caps->reference_perf = ref;
+
+	nom = cpc_trans(nom_perf, CMD_READ, 0, is_pcc);
+	perf_caps->nominal_perf = nom;
+
+	if (!ref)
+		perf_caps->reference_perf = perf_caps->nominal_perf;
+
+	spin_unlock(&pcc_lock);
+
+	if (!perf_caps->highest_perf ||
+			!perf_caps->lowest_perf ||
+			!perf_caps->reference_perf ||
+			!perf_caps->nominal_perf) {
+		return -EINVAL;
+	}
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cppc_get_perf_caps);
+
+/**
+ * cppc_get_perf_ctrs - Read a CPUs performance feedback counters.
+ * @cpunum: CPU from which to read counters.
+ * @perf_fb_ctrs: ptr to cppc_perf_fb_ctrs. See cppc_acpi.h
+ *
+ * Return - 0 for success with perf_fb_ctrs populated else
+ *	-ERRNO.
+ */
+int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
+{
+	struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpunum);
+	struct cpc_register_resource *delivered_reg, *reference_reg;
+	u64 delivered, reference;
+	bool is_pcc = false;
+	int ret;
+
+	if (!cpc_desc) {
+		pr_debug("No CPC descriptor for CPU:%d\n", cpunum);
+		return -ENODEV;
+	}
+
+	delivered_reg = &cpc_desc->cpc_regs[DELIVERED_CTR];
+	reference_reg = &cpc_desc->cpc_regs[REFERENCE_CTR];
+
+	spin_lock(&pcc_lock);
+
+	/* Are any of the regs PCC ?*/
+	if ((delivered_reg->cpc_entry.reg.space_id ==
+				ACPI_ADR_SPACE_PLATFORM_COMM) ||
+			(reference_reg->cpc_entry.reg.space_id ==
+			 ACPI_ADR_SPACE_PLATFORM_COMM))
+		is_pcc = true;
+
+	if (is_pcc) {
+		/*
+		 * Min time OS should wait before sending
+		 * next command.
+		 */
+		udelay(pcc_cmd_delay);
+		/* Ring doorbell */
+		ret = send_pcc_cmd(CMD_READ);
+		if (ret) {
+			spin_unlock(&pcc_lock);
+			return -EIO;
+		}
+	}
+
+	delivered = cpc_trans(delivered_reg, CMD_READ, 0, is_pcc);
+	reference = cpc_trans(reference_reg, CMD_READ, 0, is_pcc);
+
+	spin_unlock(&pcc_lock);
+
+	if (!delivered || !reference)
+		return -EINVAL;
+
+	perf_fb_ctrs->delivered = delivered;
+	perf_fb_ctrs->reference = reference;
+
+	perf_fb_ctrs->delivered -= perf_fb_ctrs->prev_delivered;
+	perf_fb_ctrs->reference -= perf_fb_ctrs->prev_reference;
+
+	perf_fb_ctrs->prev_delivered = delivered;
+	perf_fb_ctrs->prev_reference = reference;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs);
+
+/**
+ * cppc_set_perf - Set a CPUs performance controls.
+ * @cpu: CPU for which to set performance controls.
+ * @perf_ctrls: ptr to cppc_perf_ctrls. See cppc_acpi.h
+ *
+ * Return: 0 for success, -ERRNO otherwise.
+ */
+int cppc_set_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls)
+{
+	struct cpc_desc *cpc_desc = per_cpu(cpc_desc_ptr, cpu);
+	struct cpc_register_resource *desired_reg;
+	int ret = 0;
+	bool is_pcc = false;
+
+	if (!cpc_desc) {
+		pr_debug("No CPC descriptor for CPU:%d\n", cpu);
+		return -ENODEV;
+	}
+
+	desired_reg = &cpc_desc->cpc_regs[DESIRED_PERF];
+
+	spin_lock(&pcc_lock);
+
+	/* Is this a PCC reg ?*/
+	if (desired_reg->cpc_entry.reg.space_id ==
+			ACPI_ADR_SPACE_PLATFORM_COMM)
+		is_pcc = true;
+
+	cpc_trans(desired_reg, CMD_WRITE,
+			perf_ctrls->desired_perf, is_pcc);
+
+	if (is_pcc) {
+		/*
+		 * Min time OS should wait before sending
+		 * next command.
+		 */
+		udelay(pcc_cmd_delay);
+		/* Ring doorbell */
+		ret = send_pcc_cmd(CMD_READ);
+	}
+
+	spin_unlock(&pcc_lock);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(cppc_set_perf);
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
new file mode 100644
index 0000000..b97d2b6
--- /dev/null
+++ b/include/acpi/cppc_acpi.h
@@ -0,0 +1,137 @@
+/*
+ * CPPC (Collaborative Processor Performance Control) methods used
+ * by CPUfreq drivers.
+ *
+ * (C) Copyright 2014, 2015 Linaro Ltd.
+ * Author: Ashwin Chaugule <ashwin.chaugule@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#ifndef _CPPC_ACPI_H
+#define _CPPC_ACPI_H
+
+#include <linux/acpi.h>
+#include <linux/mailbox_controller.h>
+#include <linux/mailbox_client.h>
+#include <linux/types.h>
+
+#include <acpi/processor.h>
+
+/* Only support CPPCv2 for now. */
+#define CPPC_NUM_ENT	21
+#define CPPC_REV	2
+
+#define PCC_CMD_COMPLETE 1
+#define MAX_CPC_REG_ENT 19
+
+/* CPPC specific PCC commands. */
+#define	CMD_READ 0
+#define	CMD_WRITE 1
+
+/* Each register has the folowing format. */
+struct cpc_reg {
+	u8 descriptor;
+	u16 length;
+	u8 space_id;
+	u8 bit_width;
+	u8 bit_offset;
+	u8 access_width;
+	u64 __iomem address;
+} __packed;
+
+/*
+ * Each entry in the CPC table is either
+ * of type ACPI_TYPE_BUFFER or
+ * ACPI_TYPE_INTEGER.
+ */
+struct cpc_register_resource {
+	acpi_object_type type;
+	union {
+		struct cpc_reg reg;
+		u64 int_value;
+	} cpc_entry;
+};
+
+/* Container to hold the CPC details for each CPU */
+struct cpc_desc {
+	int num_entries;
+	int version;
+	struct cpc_register_resource cpc_regs[MAX_CPC_REG_ENT];
+	struct acpi_psd_package domain_info;
+};
+
+/* These are indexes into the per-cpu cpc_regs[]. Order is important. */
+enum cppc_regs {
+	HIGHEST_PERF,
+	NOMINAL_PERF,
+	LOW_NON_LINEAR_PERF,
+	LOWEST_PERF,
+	GUARANTEED_PERF,
+	DESIRED_PERF,
+	MIN_PERF,
+	MAX_PERF,
+	PERF_REDUC_TOLERANCE,
+	TIME_WINDOW,
+	CTR_WRAP_TIME,
+	REFERENCE_CTR,
+	DELIVERED_CTR,
+	PERF_LIMITED,
+	ENABLE,
+	AUTO_SEL_ENABLE,
+	AUTO_ACT_WINDOW,
+	ENERGY_PERF,
+	REFERENCE_PERF,
+};
+
+/*
+ * Categorization of registers as described
+ * in the ACPI v.5.1 spec.
+ * XXX: Only filling up ones which are used by governors
+ * today.
+ */
+struct cppc_perf_caps {
+	u32 highest_perf;
+	u32 nominal_perf;
+	u32 reference_perf;
+	u32 lowest_perf;
+};
+
+struct cppc_perf_ctrls {
+	u32 max_perf;
+	u32 min_perf;
+	u32 desired_perf;
+};
+
+struct cppc_perf_fb_ctrs {
+	u64 reference;
+	u64 prev_reference;
+	u64 delivered;
+	u64 prev_delivered;
+};
+
+/* Per CPU container for runtime CPPC management. */
+struct cpudata {
+	int cpu;
+	struct cppc_perf_caps perf_caps;
+	struct cppc_perf_ctrls perf_ctrls;
+	struct cppc_perf_fb_ctrs perf_fb_ctrs;
+	struct cpufreq_policy *cur_policy;
+	unsigned int shared_type;
+	cpumask_var_t shared_cpu_map;
+};
+
+extern int cppc_get_perf_ctrs(int cpu, struct cppc_perf_fb_ctrs *perf_fb_ctrs);
+extern int cppc_set_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls);
+extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps);
+extern int acpi_get_psd_map(struct cpudata **);
+
+/* Methods to interact with the PCC mailbox controller. */
+extern struct mbox_chan *
+	pcc_mbox_request_channel(struct mbox_client *, unsigned int);
+extern int mbox_send_message(struct mbox_chan *chan, void *mssg);
+
+#endif /* _CPPC_ACPI_H*/
-- 
1.9.1

[PATCH v7 5/8] CPPC: Add a CPUFreq driver for use with CPPC

[Ashwin Chaugule]

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 <ashwin.chaugule@linaro.org>
Reviewed-by: Al Stone <al.stone@linaro.org>
---
 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.
+
+	  If in doubt, say N.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index cdce92a..ef3779b 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -79,6 +79,8 @@ obj-$(CONFIG_ARM_SA1110_CPUFREQ)	+= sa1110-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA_CPUFREQ)		+= tegra-cpufreq.o
 obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ)	+= vexpress-spc-cpufreq.o
+obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
+
 
 ##################################################################################
 # PowerPC platform drivers
diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
new file mode 100644
index 0000000..b5af4c8
--- /dev/null
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -0,0 +1,197 @@
+/*
+ * CPPC (Collaborative Processor Performance Control) driver for
+ * interfacing with the CPUfreq layer and governors. See
+ * cppc_acpi.c for CPPC specific methods.
+ *
+ * (C) Copyright 2014 Linaro Ltd.
+ * Author: Ashwin Chaugule <ashwin.chaugule@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#define pr_fmt(fmt)	"CPPC Cpufreq:"	fmt
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/vmalloc.h>
+
+#include <acpi/cppc_acpi.h>
+
+static struct cpudata **all_cpu_data;
+
+static int cppc_cpufreq_set_target(struct cpufreq_policy *policy,
+		unsigned int target_freq,
+		unsigned int relation)
+{
+	struct cpudata *cpu;
+	struct cpufreq_freqs freqs;
+	int ret;
+
+	cpu = all_cpu_data[policy->cpu];
+
+	cpu->perf_ctrls.desired_perf = target_freq;
+	freqs.old = policy->cur;
+	freqs.new = target_freq;
+
+	cpufreq_freq_transition_begin(policy, &freqs);
+	ret = cppc_set_perf(cpu->cpu, &cpu->perf_ctrls);
+	cpufreq_freq_transition_end(policy, &freqs, ret != 0);
+
+	if (ret) {
+		pr_debug("Failed to set target on CPU:%d. ret:%d\n",
+				cpu->cpu, ret);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static unsigned int cppc_cpufreq_get_perf(unsigned int cpu_num)
+{
+	struct cpudata *cpu;
+	int32_t delivered_perf = 1;
+	int ret;
+
+	cpu = all_cpu_data[cpu_num];
+	if (!cpu)
+		return 0;
+
+	ret = cppc_get_perf_ctrs(cpu_num, &cpu->perf_fb_ctrs);
+
+	if (ret) {
+		pr_err("Err reading CPU%d, perf counters. ret:%d\n",
+				cpu->cpu, ret);
+		return -ENODEV;
+	}
+	delivered_perf = cpu->perf_caps.reference_perf *
+		cpu->perf_fb_ctrs.delivered;
+	delivered_perf /= cpu->perf_fb_ctrs.reference;
+	pr_debug("delivered_perf: %d\n", delivered_perf);
+	pr_debug("reference_perf: %d\n",
+			cpu->perf_caps.reference_perf);
+	pr_debug("delivered, reference deltas: %lld, %lld\n",
+			cpu->perf_fb_ctrs.delivered,
+			cpu->perf_fb_ctrs.reference);
+
+	return delivered_perf;
+}
+
+static int cppc_verify_policy(struct cpufreq_policy *policy)
+{
+	cpufreq_verify_within_cpu_limits(policy);
+	return 0;
+}
+
+static void cppc_cpufreq_stop_cpu(struct cpufreq_policy *policy)
+{
+	int cpu_num = policy->cpu;
+	struct cpudata *cpu = all_cpu_data[cpu_num];
+	int ret;
+
+	pr_info("CPU %d exiting\n", cpu_num);
+
+	cpu->perf_ctrls.desired_perf = cpu->perf_caps.lowest_perf;
+
+	ret = cppc_set_perf(cpu_num, &cpu->perf_ctrls);
+	if (ret)
+		pr_err("Err setting perf value:%d on CPU:%d. ret:%d\n",
+				cpu->perf_caps.lowest_perf, cpu_num, ret);
+}
+
+static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+	struct cpudata *cpu;
+	int ret;
+
+	cpu = all_cpu_data[policy->cpu];
+
+	cpu->cpu = policy->cpu;
+	ret = cppc_get_perf_caps(policy->cpu, &cpu->perf_caps);
+
+	if (ret) {
+		pr_err("Err reading CPU%d, perf capabilities. ret:%d\n",
+				cpu->cpu, ret);
+		return -ENODEV;
+	}
+
+	policy->min = cpu->perf_caps.lowest_perf;
+	policy->max = cpu->perf_caps.highest_perf;
+	/* cpuinfo and default policy values */
+	policy->cpuinfo.min_freq = cpu->perf_caps.lowest_perf;
+	policy->cpuinfo.max_freq = cpu->perf_caps.highest_perf;
+
+	if (policy->shared_type == CPUFREQ_SHARED_TYPE_ALL ||
+	    policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
+		cpumask_copy(policy->cpus, cpu->shared_cpu_map);
+
+	cpumask_set_cpu(policy->cpu, policy->cpus);
+	cpu->cur_policy = policy;
+
+	pr_info("Initialized on cpu:%d\n", cpu->cpu);
+	return 0;
+}
+
+static struct cpufreq_driver cppc_cpufreq_driver = {
+	.flags = CPUFREQ_CONST_LOOPS,
+	.verify = cppc_verify_policy,
+	.target = cppc_cpufreq_set_target,
+	.get = cppc_cpufreq_get_perf,
+	.init = cppc_cpufreq_cpu_init,
+	.stop_cpu = cppc_cpufreq_stop_cpu,
+	.name = "cppc_cpufreq",
+};
+
+static int __init cppc_cpufreq_init(void)
+{
+	int i, rc = 0;
+	struct cpudata *cpu;
+
+	if (acpi_disabled)
+		return -ENODEV;
+
+	all_cpu_data = vzalloc(sizeof(void *) * num_possible_cpus());
+	if (!all_cpu_data)
+		return -ENOMEM;
+
+	for_each_possible_cpu(i) {
+		all_cpu_data[i] = kzalloc(sizeof(struct cpudata), GFP_KERNEL);
+		if (!all_cpu_data[i])
+			goto out;
+
+		cpu = all_cpu_data[i];
+		if (!zalloc_cpumask_var(&cpu->shared_cpu_map,
+					GFP_KERNEL)) {
+			pr_debug("No memory for shared_cpus cpumask\n");
+			goto out;
+		}
+	}
+
+	rc = acpi_get_psd_map(all_cpu_data);
+	if (rc) {
+		pr_err("Error parsing PSD data\n");
+		goto out;
+	}
+
+	rc = cpufreq_register_driver(&cppc_cpufreq_driver);
+	if (rc)
+		goto out;
+
+	pr_info("Registration completed\n");
+	return rc;
+
+out:
+	for_each_possible_cpu(i)
+		if (all_cpu_data[i])
+			kfree(all_cpu_data[i]);
+
+	vfree(all_cpu_data);
+	return -ENODEV;
+}
+
+late_initcall(cppc_cpufreq_init);
-- 
1.9.1

[PATCH v7 6/8] ACPI: Add weak routines for ACPI CPU Hotplug

[Ashwin Chaugule]

Add weak functions for architectures which do not support
hot-adding and removing CPUs which aren't detected at
bootup. (e.g. via MADT).

This helps preserve the Kconfig dependency from:

commit cbfc1bae55bb ("[ACPI] ACPI_HOTPLUG_CPU Kconfig dependency
update")

    prevent:

    HOTPLUG_CPU=y
    ACPI_PROCESSOR=y
    ACPI_HOTPLUG_CPU=n

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
---
 drivers/acpi/acpi_processor.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 58f335c..1fbf252 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -164,6 +164,24 @@ static int acpi_processor_errata(void)
    -------------------------------------------------------------------------- */
 
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
+int __weak acpi_map_cpu(acpi_handle handle,
+		phys_cpuid_t physid, int *pcpu)
+{
+	return -ENODEV;
+}
+
+int __weak acpi_unmap_cpu(int cpu)
+{
+	return -ENODEV;
+}
+
+int __weak arch_register_cpu(int cpu)
+{
+	return -ENODEV;
+}
+
+void __weak arch_unregister_cpu(int cpu) {}
+
 static int acpi_processor_hotadd_init(struct acpi_processor *pr)
 {
 	unsigned long long sta;
-- 
1.9.1

[PATCH v7 7/8] CPPC: Probe for CPPC tables for each ACPI Processor object

[Ashwin Chaugule]

For each detected ACPI Processor object (ACPI0007), search its
device handle for CPPC specific tables (i.e. _CPC) and extract
CPU specific performance capabilities.

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Reviewed-by: Al Stone <al.stone@linaro.org>
---
 arch/arm64/Kconfig              | 1 +
 drivers/acpi/Kconfig            | 2 +-
 drivers/acpi/processor_driver.c | 4 ++++
 include/acpi/processor.h        | 9 +++++++++
 4 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7796af4..feff114 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -83,6 +83,7 @@ config ARM64
 	select SPARSE_IRQ
 	select SYSCTL_EXCEPTION_TRACE
 	select HAVE_CONTEXT_TRACKING
+	select ACPI_CPPC_LIB if ACPI
 	help
 	  ARM 64-bit (AArch64) Linux support.
 
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 54d73bb..097c02a 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -198,7 +198,7 @@ config ACPI_CPPC_LIB
 config ACPI_PROCESSOR
 	tristate "Processor"
 	select CPU_IDLE if ACPI_PROCESSOR_IDLE
-	depends on X86 || IA64
+	depends on X86 || IA64 || ARM64
 	default y
 	help
 	  This driver adds support for the ACPI Processor package. It is required
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 16d44ad..ac3dd51 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -246,6 +246,10 @@ static int __acpi_processor_start(struct acpi_device *device)
 	if (pr->flags.need_hotplug_init)
 		return 0;
 
+	result = acpi_cppc_processor_probe(pr);
+	if (result)
+		return -ENODEV;
+
 	if (!cpuidle_get_driver() || cpuidle_get_driver() == &acpi_idle_driver)
 		acpi_processor_power_init(pr);
 
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index c071a92..6e53b5e 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -328,6 +328,15 @@ phys_cpuid_t acpi_get_phys_id(acpi_handle, int type, u32 acpi_id);
 int acpi_map_cpuid(phys_cpuid_t phys_id, u32 acpi_id);
 int acpi_get_cpuid(acpi_handle, int type, u32 acpi_id);
 
+#ifdef CONFIG_ACPI_CPPC_LIB
+extern int acpi_cppc_processor_probe(struct acpi_processor *pr);
+#else
+static inline int acpi_cppc_processor_probe(struct acpi_processor *pr)
+{
+	return 0;
+}
+#endif	/* CONFIG_ACPI_CPPC_LIB */
+
 /* in processor_pdc.c */
 void acpi_processor_set_pdc(acpi_handle handle);
 
-- 
1.9.1

[PATCH v7 8/8] PCC: Enable PCC only when needed

[Ashwin Chaugule]

CPPC is the first client to make use of the PCC Mailbox channel. So
enable it only when CPPC is also enabled.

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Reviewed-by: Al Stone <al.stone@linaro.org>
---
 drivers/mailbox/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 84b0a2d..f2c30cc 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -45,7 +45,7 @@ config OMAP_MBOX_KFIFO_SIZE
 
 config PCC
 	bool "Platform Communication Channel Driver"
-	depends on ACPI
+	depends on ACPI && ACPI_CPPC_LIB
 	help
 	  ACPI 5.0+ spec defines a generic mode of communication
 	  between the OS and a platform such as the BMC. This medium
-- 
1.9.1

Re: [PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Rafael J. Wysocki]

On Thursday, July 09, 2015 02:04:18 PM Ashwin Chaugule wrote:
> The ACPI processor driver is currently tied too closely
> to the ACPI P-states (PSS) and other related constructs
> for controlling CPU performance.
> 
> The newer ACPI specification (v5.1 onwards) introduces
> alternative methods to PSS. These new mechanisms are
> described within each ACPI Processor object and so they
> need to be scanned whenever a new Processor object is detected.
> This patch introduces a new Kconfig symbol to allow for
> finer configurability among the two options for controlling
> performance states. There is no change in functionality and
> the option is auto-selected by the architecture Kconfig files.
> 
> The following patchwork introduces CPPC: A newer method of
> controlling CPU performance. The OS is not expected to support
> CPPC and PSS at runtime. So the kconfig option lets us make
> these two mutually exclusive at compile time.
> 
> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> ---
>  arch/x86/Kconfig                |  1 +
>  drivers/acpi/Kconfig            | 19 ++++++---
>  drivers/acpi/Makefile           |  6 +--
>  drivers/acpi/processor_driver.c | 86 +++++++++++++++++++++++++------------
>  drivers/cpufreq/Kconfig         |  2 +-
>  drivers/cpufreq/Kconfig.x86     |  2 +
>  include/acpi/processor.h        | 94 +++++++++++++++++++++++++++--------------
>  7 files changed, 142 insertions(+), 68 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 226d569..93d150d 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -143,6 +143,7 @@ config X86
>  	select ACPI_LEGACY_TABLES_LOOKUP if ACPI
>  	select X86_FEATURE_NAMES if PROC_FS
>  	select SRCU
> +	select ACPI_CPU_FREQ_PSS if ACPI
>  
>  config INSTRUCTION_DECODER
>  	def_bool y
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index ab2cbb5..00748dc 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -166,17 +166,26 @@ config ACPI_DOCK
>  	  This driver supports ACPI-controlled docking stations and removable
>  	  drive bays such as the IBM Ultrabay and the Dell Module Bay.
>  
> +config ACPI_CPU_FREQ_PSS
> +	bool
> +	depends on ACPI_PROCESSOR && CPU_FREQ
> +	select THERMAL
> +	help
> +	  This driver implements ACPI methods for controlling CPU performance
> +	  using PSS methods as described in the ACPI spec. It also enables support
> +	  for ACPI based performance throttling (TSS) and ACPI based thermal
> +	  monitoring. It is required by several flavors of cpufreq
> +	  performance-state drivers.

So are you not agreeing with what I've said for a few times already or are you
just not listening?

This option should *not* be user-selectable.  So please drop the help part
and make it look like ACPI_SLEEP, for example.

Thanks,
Rafael

Re: [PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Rafael J. Wysocki]

On Saturday, July 18, 2015 02:01:40 AM Rafael J. Wysocki wrote:
> On Thursday, July 09, 2015 02:04:18 PM Ashwin Chaugule wrote:
> > The ACPI processor driver is currently tied too closely
> > to the ACPI P-states (PSS) and other related constructs
> > for controlling CPU performance.
> > 
> > The newer ACPI specification (v5.1 onwards) introduces
> > alternative methods to PSS. These new mechanisms are
> > described within each ACPI Processor object and so they
> > need to be scanned whenever a new Processor object is detected.
> > This patch introduces a new Kconfig symbol to allow for
> > finer configurability among the two options for controlling
> > performance states. There is no change in functionality and
> > the option is auto-selected by the architecture Kconfig files.
> > 
> > The following patchwork introduces CPPC: A newer method of
> > controlling CPU performance. The OS is not expected to support
> > CPPC and PSS at runtime. So the kconfig option lets us make
> > these two mutually exclusive at compile time.
> > 
> > Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> > ---
> >  arch/x86/Kconfig                |  1 +
> >  drivers/acpi/Kconfig            | 19 ++++++---
> >  drivers/acpi/Makefile           |  6 +--
> >  drivers/acpi/processor_driver.c | 86 +++++++++++++++++++++++++------------
> >  drivers/cpufreq/Kconfig         |  2 +-
> >  drivers/cpufreq/Kconfig.x86     |  2 +
> >  include/acpi/processor.h        | 94 +++++++++++++++++++++++++++--------------
> >  7 files changed, 142 insertions(+), 68 deletions(-)
> > 
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 226d569..93d150d 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -143,6 +143,7 @@ config X86
> >  	select ACPI_LEGACY_TABLES_LOOKUP if ACPI
> >  	select X86_FEATURE_NAMES if PROC_FS
> >  	select SRCU
> > +	select ACPI_CPU_FREQ_PSS if ACPI

Also, does ia64 not use _PSS-based cpufreq?

Thanks,
Rafael

Re: [PATCH v7 1/8] PCC: Initialize PCC Mailbox earlier at boot

[Sudeep Holla]

On 09/07/15 19:04, Ashwin Chaugule wrote:
> This change initializes the PCC Mailbox earlier than
> the ACPI processor driver. This enables drivers introduced
> in follow up patches (e.g. CPPC) to be probed via the ACPI
> processor driver interface. The CPPC probe requires the PCC
> channel to be initialized for it to query each CPUs performance
> capabilities.
>
> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> Reviewed-by: Al Stone <al.stone@linaro.org>
> ---
>   drivers/mailbox/pcc.c | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 7e91d68..fcda63e 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -352,4 +352,10 @@ static int __init pcc_init(void)
>
>   	return 0;
>   }
> -device_initcall(pcc_init);
> +
> +/*
> + * Make pcc init postcore so that users of this mailbox
> + * such as the ACPI Processor driver have it available
> + * at their init.
> + */
> +postcore_initcall(pcc_init);
>

I assumed you have explored other options like deferred probe and
finally resorted to this as they are not feasible ? Because setting up
these kind of dependency are prone to create issues later on.

Regards,
Sudeep

Re: [PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Sudeep Holla]

On 09/07/15 19:04, Ashwin Chaugule wrote:
> The ACPI processor driver is currently tied too closely
> to the ACPI P-states (PSS) and other related constructs
> for controlling CPU performance.
>
> The newer ACPI specification (v5.1 onwards) introduces
> alternative methods to PSS. These new mechanisms are
> described within each ACPI Processor object and so they
> need to be scanned whenever a new Processor object is detected.
> This patch introduces a new Kconfig symbol to allow for
> finer configurability among the two options for controlling
> performance states. There is no change in functionality and
> the option is auto-selected by the architecture Kconfig files.
>
> The following patchwork introduces CPPC: A newer method of
> controlling CPU performance. The OS is not expected to support
> CPPC and PSS at runtime. So the kconfig option lets us make
> these two mutually exclusive at compile time.
>
> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> ---
>   arch/x86/Kconfig                |  1 +
>   drivers/acpi/Kconfig            | 19 ++++++---
>   drivers/acpi/Makefile           |  6 +--
>   drivers/acpi/processor_driver.c | 86 +++++++++++++++++++++++++------------
>   drivers/cpufreq/Kconfig         |  2 +-
>   drivers/cpufreq/Kconfig.x86     |  2 +
>   include/acpi/processor.h        | 94 +++++++++++++++++++++++++++--------------
>   7 files changed, 142 insertions(+), 68 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 226d569..93d150d 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -143,6 +143,7 @@ config X86
>          select ACPI_LEGACY_TABLES_LOOKUP if ACPI
>          select X86_FEATURE_NAMES if PROC_FS
>          select SRCU
> +       select ACPI_CPU_FREQ_PSS if ACPI
>
>   config INSTRUCTION_DECODER
>          def_bool y
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index ab2cbb5..00748dc 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -166,17 +166,26 @@ config ACPI_DOCK
>            This driver supports ACPI-controlled docking stations and removable
>            drive bays such as the IBM Ultrabay and the Dell Module Bay.
>
> +config ACPI_CPU_FREQ_PSS
> +       bool
> +       depends on ACPI_PROCESSOR && CPU_FREQ
> +       select THERMAL
> +       help
> +         This driver implements ACPI methods for controlling CPU performance
> +         using PSS methods as described in the ACPI spec. It also enables support
> +         for ACPI based performance throttling (TSS) and ACPI based thermal
> +         monitoring. It is required by several flavors of cpufreq
> +         performance-state drivers.
> +

Though I agree CPUFreq and the thermal control are related, having _PSS
in config name shouldn't match well IMO. You can have more generic name.

You are selecting one config while depending on the other, any
particular reason ?

I don't like adding these, but I leave it to Rafael.

Regards,
Sudeep

Re: [PATCH v7 3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

[Sudeep Holla]

On 09/07/15 19:04, Ashwin Chaugule wrote:
> This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE,
> which is auto selected by architectures which support the ACPI
> based C states for CPU Idle management.
>
> The processor_idle driver in its present form contains declarations
> specific to X86 and IA64. Since there are no reasonable defaults
> for other architectures e.g. ARM64, the driver is selected only by
> the arch/x86/Kconfig.
>
> This helps in decoupling the ACPI processor_driver from the ACPI
> processor_idle driver which is useful for the upcoming alternative
> patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI).
>
> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> ---
>   drivers/acpi/Kconfig     |  6 +++++-
>   drivers/acpi/Makefile    |  3 ++-
>   include/acpi/processor.h | 26 ++++++++++++++++++++++++--
>   3 files changed, 31 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 00748dc..8a60b6e 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -177,9 +177,13 @@ config ACPI_CPU_FREQ_PSS
>   	  monitoring. It is required by several flavors of cpufreq
>   	  performance-state drivers.
>
> +config ACPI_PROCESSOR_IDLE
> +	def_bool y
> +	depends on X86 || IA64
> +

In general, you need to split this series so that initially few patches
deal with all the existing Kconfig fix-ups and then introduce
PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
support.

Regards,
Sudeep

Re: [PATCH v7 5/8] CPPC: Add a CPUFreq driver for use with CPPC

[Sudeep Holla]

On 09/07/15 19:04, Ashwin Chaugule wrote:
> 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 <ashwin.chaugule@linaro.org>
> Reviewed-by: Al Stone <al.stone@linaro.org>
> ---
>   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.

Regards,
Sudeep

Re: [PATCH v7 7/8] CPPC: Probe for CPPC tables for each ACPI Processor object

[Sudeep Holla]

On 09/07/15 19:04, Ashwin Chaugule wrote:
> For each detected ACPI Processor object (ACPI0007), search its
> device handle for CPPC specific tables (i.e. _CPC) and extract
> CPU specific performance capabilities.
>
> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> Reviewed-by: Al Stone <al.stone@linaro.org>
> ---
>   arch/arm64/Kconfig              | 1 +
>   drivers/acpi/Kconfig            | 2 +-
>   drivers/acpi/processor_driver.c | 4 ++++
>   include/acpi/processor.h        | 9 +++++++++
>   4 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7796af4..feff114 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -83,6 +83,7 @@ config ARM64
>   	select SPARSE_IRQ
>   	select SYSCTL_EXCEPTION_TRACE
>   	select HAVE_CONTEXT_TRACKING
> +	select ACPI_CPPC_LIB if ACPI

This could be separate patch. It's doesn't match with $subject
and usually better to keep arm64 specific changes separate.

>   	help
>   	  ARM 64-bit (AArch64) Linux support.
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 54d73bb..097c02a 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -198,7 +198,7 @@ config ACPI_CPPC_LIB
>   config ACPI_PROCESSOR
>   	tristate "Processor"
>   	select CPU_IDLE if ACPI_PROCESSOR_IDLE
> -	depends on X86 || IA64
> +	depends on X86 || IA64 || ARM64

Ditto

Regards,
Sudeep

Re: [PATCH v7 8/8] PCC: Enable PCC only when needed

[Sudeep Holla]

On 09/07/15 19:04, Ashwin Chaugule wrote:
> CPPC is the first client to make use of the PCC Mailbox channel. So
> enable it only when CPPC is also enabled.
>
This sounds like a reverse dependency to me. So if there's some client
unrelated to CPPC using PCC, CPPC_LIB needs to be selected to enable PCC ?

Regards,
Sudeep

Re: [PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Rafael J. Wysocki]

On Monday, July 20, 2015 03:20:46 PM Sudeep Holla wrote:
> 
> On 09/07/15 19:04, Ashwin Chaugule wrote:
> > The ACPI processor driver is currently tied too closely
> > to the ACPI P-states (PSS) and other related constructs
> > for controlling CPU performance.
> >
> > The newer ACPI specification (v5.1 onwards) introduces
> > alternative methods to PSS. These new mechanisms are
> > described within each ACPI Processor object and so they
> > need to be scanned whenever a new Processor object is detected.
> > This patch introduces a new Kconfig symbol to allow for
> > finer configurability among the two options for controlling
> > performance states. There is no change in functionality and
> > the option is auto-selected by the architecture Kconfig files.
> >
> > The following patchwork introduces CPPC: A newer method of
> > controlling CPU performance. The OS is not expected to support
> > CPPC and PSS at runtime. So the kconfig option lets us make
> > these two mutually exclusive at compile time.
> >
> > Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> > ---
> >   arch/x86/Kconfig                |  1 +
> >   drivers/acpi/Kconfig            | 19 ++++++---
> >   drivers/acpi/Makefile           |  6 +--
> >   drivers/acpi/processor_driver.c | 86 +++++++++++++++++++++++++------------
> >   drivers/cpufreq/Kconfig         |  2 +-
> >   drivers/cpufreq/Kconfig.x86     |  2 +
> >   include/acpi/processor.h        | 94 +++++++++++++++++++++++++++--------------
> >   7 files changed, 142 insertions(+), 68 deletions(-)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 226d569..93d150d 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -143,6 +143,7 @@ config X86
> >          select ACPI_LEGACY_TABLES_LOOKUP if ACPI
> >          select X86_FEATURE_NAMES if PROC_FS
> >          select SRCU
> > +       select ACPI_CPU_FREQ_PSS if ACPI
> >
> >   config INSTRUCTION_DECODER
> >          def_bool y
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index ab2cbb5..00748dc 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -166,17 +166,26 @@ config ACPI_DOCK
> >            This driver supports ACPI-controlled docking stations and removable
> >            drive bays such as the IBM Ultrabay and the Dell Module Bay.
> >
> > +config ACPI_CPU_FREQ_PSS
> > +       bool
> > +       depends on ACPI_PROCESSOR && CPU_FREQ
> > +       select THERMAL
> > +       help
> > +         This driver implements ACPI methods for controlling CPU performance
> > +         using PSS methods as described in the ACPI spec. It also enables support
> > +         for ACPI based performance throttling (TSS) and ACPI based thermal
> > +         monitoring. It is required by several flavors of cpufreq
> > +         performance-state drivers.
> > +
> 
> Though I agree CPUFreq and the thermal control are related, having _PSS
> in config name shouldn't match well IMO. You can have more generic name.
> 
> You are selecting one config while depending on the other, any
> particular reason ?
> 
> I don't like adding these, but I leave it to Rafael.

My opinion is analogous. :-)

I *guess* the idea was to avoid selecting ACPI_CPU_FREQ_PSS withouth
ACPI_PROCESSOR so we don't build unnecessary code.  That's a good point,
but I would also like to keep they way ACPI_PROCESSOR works on x86 and
ia64 without adding new user-selectable Kconfig options.

So, what about this:

 config ACPI_PROCESSOR
 	tristate "Processor"
 	select THERMAL
 	select CPU_IDLE
-	depends on X86 || IA64
+	select ACPI_CPU_FREQ_PSS if X86 || IA64
 	default y
 	help
 	  This driver installs ACPI as the idle handler for Linux and uses

and define ACPI_CPU_FREQ_PSS in analogy with ACPI_CCA_REQUIRED for example?


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH v7 8/8] PCC: Enable PCC only when needed

[Rafael J. Wysocki]

On Monday, July 20, 2015 03:22:37 PM Sudeep Holla wrote:
> 
> On 09/07/15 19:04, Ashwin Chaugule wrote:
> > CPPC is the first client to make use of the PCC Mailbox channel. So
> > enable it only when CPPC is also enabled.
> >
> This sounds like a reverse dependency to me. So if there's some client
> unrelated to CPPC using PCC, CPPC_LIB needs to be selected to enable PCC ?

No.  The other client will need to select PCC too.

I requested that change, because I'm slightly bothered by the fact that we
build code used by no one by default.

Thanks,
Rafael

Re: [PATCH v7 5/8] CPPC: Add a CPUFreq driver for use with CPPC

[Rafael J. Wysocki]

On Monday, July 20, 2015 03:22:09 PM Sudeep Holla wrote:
> 
> On 09/07/15 19:04, Ashwin Chaugule wrote:
> > 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 <ashwin.chaugule@linaro.org>
> > Reviewed-by: Al Stone <al.stone@linaro.org>
> > ---
> >   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?

Thanks,
Rafael

Re: [PATCH v7 5/8] CPPC: Add a CPUFreq driver for use with CPPC

[Sudeep Holla]

On 20/07/15 23:07, Rafael J. Wysocki wrote:
> On Monday, July 20, 2015 03:22:09 PM Sudeep Holla wrote:
>>
>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>> 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 <ashwin.chaugule@linaro.org>
>>> Reviewed-by: Al Stone <al.stone@linaro.org>
>>> ---
>>>    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

Re: [PATCH v7 8/8] PCC: Enable PCC only when needed

[Sudeep Holla]

On 20/07/15 23:04, Rafael J. Wysocki wrote:
> On Monday, July 20, 2015 03:22:37 PM Sudeep Holla wrote:
>>
>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>> CPPC is the first client to make use of the PCC Mailbox channel. So
>>> enable it only when CPPC is also enabled.
>>>
>> This sounds like a reverse dependency to me. So if there's some client
>> unrelated to CPPC using PCC, CPPC_LIB needs to be selected to enable PCC ?
>
> No.  The other client will need to select PCC too.

Yes the PCC users/clients selecting PCC is fine and that's already
done(i.e. ACPI_CPPC_LIB selects PCC). I still don't understand the need
for this change, also how will other clients possibly select PCC which
now depends on CPPC_LIB ? e.g. if we have

config ACPI_XYZ_LIB
	select PCC

config ACPI_XYZ
	select ACPI_XYZ_LIB

Won't this shout warning: (ACPI_XYZ_LIB && ACPI_CPPC_LIB) selects PCC
which has unmet direct dependencies (MAILBOX && ACPI && ACPI_CPPC_LIB)
if ACPI_CPPC_LIB is not selected ?

OK, for now we enable ACPI_CPPC_LIB on ARM64 and not on x86. When x86
has a PCC client how will that select PCC without ACPI_CPPC_LIB. Sorry
if I am missing to understand something.

>
> I requested that change, because I'm slightly bothered by the fact that we
> build code used by no one by default.
>

I understand, but will keeping them default off should suffice ? No ?

Regards,
Sudeep

Re: [PATCH v7 5/8] CPPC: Add a CPUFreq driver for use with CPPC

[Rafael J. Wysocki]

Hi Sudeep,

On Tue, Jul 21, 2015 at 10:52 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 20/07/15 23:07, Rafael J. Wysocki wrote:
>>
>> On Monday, July 20, 2015 03:22:09 PM Sudeep Holla wrote:
>>>
>>>
>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>
>>>> 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 <ashwin.chaugule@linaro.org>
>>>> Reviewed-by: Al Stone <al.stone@linaro.org>
>>>>
>>>> ---
>>>>    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.

Problem is, there are no plans to support CPPC on x86 in Linux I'm
aware of and so we should not use it even if it is exposed by the
firmware (Windows may be using it, though).

I'm also not aware of plans to support _PSS on ARM.

So, even though on the spec level they are arch-independent, the way
we use those interfaces in the kernel isn't.

Thanks,
Rafael

Re: [PATCH v7 8/8] PCC: Enable PCC only when needed

[Rafael J. Wysocki]

Hi Sudeep,

On Tue, Jul 21, 2015 at 11:23 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 20/07/15 23:04, Rafael J. Wysocki wrote:
>>
>> On Monday, July 20, 2015 03:22:37 PM Sudeep Holla wrote:
>>>
>>>
>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>
>>>> CPPC is the first client to make use of the PCC Mailbox channel. So
>>>> enable it only when CPPC is also enabled.
>>>>
>>> This sounds like a reverse dependency to me. So if there's some client
>>> unrelated to CPPC using PCC, CPPC_LIB needs to be selected to enable PCC
>>> ?
>>
>>
>> No.  The other client will need to select PCC too.
>
>
> Yes the PCC users/clients selecting PCC is fine and that's already
> done(i.e. ACPI_CPPC_LIB selects PCC). I still don't understand the need
> for this change, also how will other clients possibly select PCC which
> now depends on CPPC_LIB ? e.g. if we have
>
> config ACPI_XYZ_LIB
>         select PCC
>
> config ACPI_XYZ
>         select ACPI_XYZ_LIB
>
> Won't this shout warning: (ACPI_XYZ_LIB && ACPI_CPPC_LIB) selects PCC
> which has unmet direct dependencies (MAILBOX && ACPI && ACPI_CPPC_LIB)
> if ACPI_CPPC_LIB is not selected ?

That depends on the "depends on" clauses used.  Selecting itself
doesn't cause any dependencies to appear.

> OK, for now we enable ACPI_CPPC_LIB on ARM64 and not on x86. When x86
> has a PCC client how will that select PCC without ACPI_CPPC_LIB. Sorry
> if I am missing to understand something.

Presumably, the new feature will have a Kconfig option associated with
it and it will do "select PCC" too.

>>
>> I requested that change, because I'm slightly bothered by the fact that we
>> build code used by no one by default.
>>
>
> I understand, but will keeping them default off should suffice ? No ?

Yes, it should.  But is it the case now?

Thanks,
Rafael

Re: [PATCH v7 8/8] PCC: Enable PCC only when needed

[Sudeep Holla]

Hi Rafael,

On 21/07/15 15:34, Rafael J. Wysocki wrote:
> Hi Sudeep,
>
> On Tue, Jul 21, 2015 at 11:23 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 20/07/15 23:04, Rafael J. Wysocki wrote:
>>>
>>> On Monday, July 20, 2015 03:22:37 PM Sudeep Holla wrote:
>>>>
>>>>
>>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>>
>>>>> CPPC is the first client to make use of the PCC Mailbox channel. So
>>>>> enable it only when CPPC is also enabled.
>>>>>
>>>> This sounds like a reverse dependency to me. So if there's some client
>>>> unrelated to CPPC using PCC, CPPC_LIB needs to be selected to enable PCC
>>>> ?
>>>
>>>
>>> No.  The other client will need to select PCC too.
>>
>>
>> Yes the PCC users/clients selecting PCC is fine and that's already
>> done(i.e. ACPI_CPPC_LIB selects PCC). I still don't understand the need
>> for this change, also how will other clients possibly select PCC which
>> now depends on CPPC_LIB ? e.g. if we have
>>
>> config ACPI_XYZ_LIB
>>          select PCC
>>
>> config ACPI_XYZ
>>          select ACPI_XYZ_LIB
>>
>> Won't this shout warning: (ACPI_XYZ_LIB && ACPI_CPPC_LIB) selects PCC
>> which has unmet direct dependencies (MAILBOX && ACPI && ACPI_CPPC_LIB)
>> if ACPI_CPPC_LIB is not selected ?
>
> That depends on the "depends on" clauses used.  Selecting itself
> doesn't cause any dependencies to appear.
>

Agreed and I am absolutely fine with that. But if you look at this 
patch, it does

config PCC
	bool "Platform Communication Channel Driver"
	depends on ACPI && ACPI_CPPC_LIB

I am fine with ACPI_CPPC_LIB selecting PCC which is already done in
earlier patch. I am against making PCC depend on ACPI_CPPC_LIB.

Lets assume it's fine to do that. Now if another feature XYZ as in my
example say on x86 selects PCC then you will *get warnings* as we will
not able to select PCC without selecting ACPI_CPPC_LIB after this patch
and x86 will never select ACPI_CPPC_LIB. I did test something like my
XYZ example and it did trigger the warning as I suspected.

I am sorry either I am missing to understand again or unable to express
the problem here :(

>> OK, for now we enable ACPI_CPPC_LIB on ARM64 and not on x86. When x86
>> has a PCC client how will that select PCC without ACPI_CPPC_LIB. Sorry
>> if I am missing to understand something.
>
> Presumably, the new feature will have a Kconfig option associated with
> it and it will do "select PCC" too.
>

As I say I am fine with that and no arguments there.

Regards,
Sudeep

Re: [PATCH v7 5/8] CPPC: Add a CPUFreq driver for use with CPPC

[Sudeep Holla]

Hi Rafael,

On 21/07/15 15:27, Rafael J. Wysocki wrote:
> Hi Sudeep,
>
> On Tue, Jul 21, 2015 at 10:52 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 20/07/15 23:07, Rafael J. Wysocki wrote:
>>>
>>> On Monday, July 20, 2015 03:22:09 PM Sudeep Holla wrote:
>>>>
>>>>
>>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>>
>>>>> 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 <ashwin.chaugule@linaro.org>
>>>>> Reviewed-by: Al Stone <al.stone@linaro.org>
>>>>>
>>>>> ---
>>>>>     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.
>
> Problem is, there are no plans to support CPPC on x86 in Linux I'm
> aware of and so we should not use it even if it is exposed by the
> firmware (Windows may be using it, though).
>

Ah that makes sense.

> I'm also not aware of plans to support _PSS on ARM.

Agreed, but you never know what ARM vendors can do :)

>
> So, even though on the spec level they are arch-independent, the way
> we use those interfaces in the kernel isn't.
>

Understood.

Regards,
Sudeep

Re: [PATCH v7 8/8] PCC: Enable PCC only when needed

[Rafael J. Wysocki]

On Tuesday, July 21, 2015 04:28:43 PM Sudeep Holla wrote:
> Hi Rafael,
> 
> On 21/07/15 15:34, Rafael J. Wysocki wrote:
> > Hi Sudeep,
> >
> > On Tue, Jul 21, 2015 at 11:23 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >>
> >>
> >> On 20/07/15 23:04, Rafael J. Wysocki wrote:
> >>>
> >>> On Monday, July 20, 2015 03:22:37 PM Sudeep Holla wrote:
> >>>>
> >>>>
> >>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
> >>>>>
> >>>>> CPPC is the first client to make use of the PCC Mailbox channel. So
> >>>>> enable it only when CPPC is also enabled.
> >>>>>
> >>>> This sounds like a reverse dependency to me. So if there's some client
> >>>> unrelated to CPPC using PCC, CPPC_LIB needs to be selected to enable PCC
> >>>> ?
> >>>
> >>>
> >>> No.  The other client will need to select PCC too.
> >>
> >>
> >> Yes the PCC users/clients selecting PCC is fine and that's already
> >> done(i.e. ACPI_CPPC_LIB selects PCC). I still don't understand the need
> >> for this change, also how will other clients possibly select PCC which
> >> now depends on CPPC_LIB ? e.g. if we have
> >>
> >> config ACPI_XYZ_LIB
> >>          select PCC
> >>
> >> config ACPI_XYZ
> >>          select ACPI_XYZ_LIB
> >>
> >> Won't this shout warning: (ACPI_XYZ_LIB && ACPI_CPPC_LIB) selects PCC
> >> which has unmet direct dependencies (MAILBOX && ACPI && ACPI_CPPC_LIB)
> >> if ACPI_CPPC_LIB is not selected ?
> >
> > That depends on the "depends on" clauses used.  Selecting itself
> > doesn't cause any dependencies to appear.
> >
> 
> Agreed and I am absolutely fine with that. But if you look at this 
> patch, it does
> 
> config PCC
> 	bool "Platform Communication Channel Driver"
> 	depends on ACPI && ACPI_CPPC_LIB

My bad, I've evidently overlooked that.

If PPC is selected from ACPI_CPPC_LIB, the "depends on" above is
obviously not needed.

> I am fine with ACPI_CPPC_LIB selecting PCC which is already done in
> earlier patch. I am against making PCC depend on ACPI_CPPC_LIB.

OK, makes sense.  Sorry for the misunderstanding.

Thanks,
Rafael

Re: [PATCH v7 8/8] PCC: Enable PCC only when needed

[Sudeep Holla]

On 22/07/15 02:28, Rafael J. Wysocki wrote:
> On Tuesday, July 21, 2015 04:28:43 PM Sudeep Holla wrote:
>> Hi Rafael,
>>
>> On 21/07/15 15:34, Rafael J. Wysocki wrote:
>>> Hi Sudeep,
>>>
>>> On Tue, Jul 21, 2015 at 11:23 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>
>>>>
>>>> On 20/07/15 23:04, Rafael J. Wysocki wrote:

[..]

>>>>>
>>>>>
>>>>> No.  The other client will need to select PCC too.
>>>>
>>>>
>>>> Yes the PCC users/clients selecting PCC is fine and that's already
>>>> done(i.e. ACPI_CPPC_LIB selects PCC). I still don't understand the need
>>>> for this change, also how will other clients possibly select PCC which
>>>> now depends on CPPC_LIB ? e.g. if we have
>>>>
>>>> config ACPI_XYZ_LIB
>>>>           select PCC
>>>>
>>>> config ACPI_XYZ
>>>>           select ACPI_XYZ_LIB
>>>>
>>>> Won't this shout warning: (ACPI_XYZ_LIB && ACPI_CPPC_LIB) selects PCC
>>>> which has unmet direct dependencies (MAILBOX && ACPI && ACPI_CPPC_LIB)
>>>> if ACPI_CPPC_LIB is not selected ?
>>>
>>> That depends on the "depends on" clauses used.  Selecting itself
>>> doesn't cause any dependencies to appear.
>>>
>>
>> Agreed and I am absolutely fine with that. But if you look at this
>> patch, it does
>>
>> config PCC
>> 	bool "Platform Communication Channel Driver"
>> 	depends on ACPI && ACPI_CPPC_LIB
>
> My bad, I've evidently overlooked that.
>
> If PPC is selected from ACPI_CPPC_LIB, the "depends on" above is
> obviously not needed.
>

Thanks for the confirmation.

>> I am fine with ACPI_CPPC_LIB selecting PCC which is already done in
>> earlier patch. I am against making PCC depend on ACPI_CPPC_LIB.
>
> OK, makes sense.  Sorry for the misunderstanding.
>

It's okay, I just wanted to make sure that I am not missing to
understand some kind of dependency.

Regards,
Sudeep

Re: [PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Ashwin Chaugule]

On 17 July 2015 at 20:01, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Thursday, July 09, 2015 02:04:18 PM Ashwin Chaugule wrote:
>> The ACPI processor driver is currently tied too closely
>> to the ACPI P-states (PSS) and other related constructs
>> for controlling CPU performance.
>>
>> The newer ACPI specification (v5.1 onwards) introduces
>> alternative methods to PSS. These new mechanisms are
>> described within each ACPI Processor object and so they
>> need to be scanned whenever a new Processor object is detected.
>> This patch introduces a new Kconfig symbol to allow for
>> finer configurability among the two options for controlling
>> performance states. There is no change in functionality and
>> the option is auto-selected by the architecture Kconfig files.
>>
>> The following patchwork introduces CPPC: A newer method of
>> controlling CPU performance. The OS is not expected to support
>> CPPC and PSS at runtime. So the kconfig option lets us make
>> these two mutually exclusive at compile time.
>>
>> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> ---
>>  arch/x86/Kconfig                |  1 +
>>  drivers/acpi/Kconfig            | 19 ++++++---
>>  drivers/acpi/Makefile           |  6 +--
>>  drivers/acpi/processor_driver.c | 86 +++++++++++++++++++++++++------------
>>  drivers/cpufreq/Kconfig         |  2 +-
>>  drivers/cpufreq/Kconfig.x86     |  2 +
>>  include/acpi/processor.h        | 94 +++++++++++++++++++++++++++--------------
>>  7 files changed, 142 insertions(+), 68 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 226d569..93d150d 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -143,6 +143,7 @@ config X86
>>       select ACPI_LEGACY_TABLES_LOOKUP if ACPI
>>       select X86_FEATURE_NAMES if PROC_FS
>>       select SRCU
>> +     select ACPI_CPU_FREQ_PSS if ACPI
>>
>>  config INSTRUCTION_DECODER
>>       def_bool y
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index ab2cbb5..00748dc 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -166,17 +166,26 @@ config ACPI_DOCK
>>         This driver supports ACPI-controlled docking stations and removable
>>         drive bays such as the IBM Ultrabay and the Dell Module Bay.
>>
>> +config ACPI_CPU_FREQ_PSS
>> +     bool
>> +     depends on ACPI_PROCESSOR && CPU_FREQ
>> +     select THERMAL
>> +     help
>> +       This driver implements ACPI methods for controlling CPU performance
>> +       using PSS methods as described in the ACPI spec. It also enables support
>> +       for ACPI based performance throttling (TSS) and ACPI based thermal
>> +       monitoring. It is required by several flavors of cpufreq
>> +       performance-state drivers.
>
> So are you not agreeing with what I've said for a few times already or are you
> just not listening?
>
> This option should *not* be user-selectable.  So please drop the help part
> and make it look like ACPI_SLEEP, for example.

Fine. I followed some other examples in the kernel. As long as there
is no text after the 'bool', it doesn't show up as a user configurable
option in the menuconfig. Having some help text even in such cases
seemed helpful to me.

Thanks,
Ashwin.

Re: [PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Ashwin Chaugule]

On 17 July 2015 at 20:03, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Saturday, July 18, 2015 02:01:40 AM Rafael J. Wysocki wrote:
>> On Thursday, July 09, 2015 02:04:18 PM Ashwin Chaugule wrote:
>> > The ACPI processor driver is currently tied too closely
>> > to the ACPI P-states (PSS) and other related constructs
>> > for controlling CPU performance.
>> >
>> > The newer ACPI specification (v5.1 onwards) introduces
>> > alternative methods to PSS. These new mechanisms are
>> > described within each ACPI Processor object and so they
>> > need to be scanned whenever a new Processor object is detected.
>> > This patch introduces a new Kconfig symbol to allow for
>> > finer configurability among the two options for controlling
>> > performance states. There is no change in functionality and
>> > the option is auto-selected by the architecture Kconfig files.
>> >
>> > The following patchwork introduces CPPC: A newer method of
>> > controlling CPU performance. The OS is not expected to support
>> > CPPC and PSS at runtime. So the kconfig option lets us make
>> > these two mutually exclusive at compile time.
>> >
>> > Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> > ---
>> >  arch/x86/Kconfig                |  1 +
>> >  drivers/acpi/Kconfig            | 19 ++++++---
>> >  drivers/acpi/Makefile           |  6 +--
>> >  drivers/acpi/processor_driver.c | 86 +++++++++++++++++++++++++------------
>> >  drivers/cpufreq/Kconfig         |  2 +-
>> >  drivers/cpufreq/Kconfig.x86     |  2 +
>> >  include/acpi/processor.h        | 94 +++++++++++++++++++++++++++--------------
>> >  7 files changed, 142 insertions(+), 68 deletions(-)
>> >
>> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> > index 226d569..93d150d 100644
>> > --- a/arch/x86/Kconfig
>> > +++ b/arch/x86/Kconfig
>> > @@ -143,6 +143,7 @@ config X86
>> >     select ACPI_LEGACY_TABLES_LOOKUP if ACPI
>> >     select X86_FEATURE_NAMES if PROC_FS
>> >     select SRCU
>> > +   select ACPI_CPU_FREQ_PSS if ACPI
>
> Also, does ia64 not use _PSS-based cpufreq?

True. Will add to the IA64 Kconfig.

Thanks,
Ashwin.

Re: [PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Ashwin Chaugule]

On 20 July 2015 at 10:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>
>> The ACPI processor driver is currently tied too closely
>> to the ACPI P-states (PSS) and other related constructs
>> for controlling CPU performance.
>>
>> The newer ACPI specification (v5.1 onwards) introduces
>> alternative methods to PSS. These new mechanisms are
>> described within each ACPI Processor object and so they
>> need to be scanned whenever a new Processor object is detected.
>> This patch introduces a new Kconfig symbol to allow for
>> finer configurability among the two options for controlling
>> performance states. There is no change in functionality and
>> the option is auto-selected by the architecture Kconfig files.
>>
>> The following patchwork introduces CPPC: A newer method of
>> controlling CPU performance. The OS is not expected to support
>> CPPC and PSS at runtime. So the kconfig option lets us make
>> these two mutually exclusive at compile time.
>>
>> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> ---
>>   arch/x86/Kconfig                |  1 +
>>   drivers/acpi/Kconfig            | 19 ++++++---
>>   drivers/acpi/Makefile           |  6 +--
>>   drivers/acpi/processor_driver.c | 86
>> +++++++++++++++++++++++++------------
>>   drivers/cpufreq/Kconfig         |  2 +-
>>   drivers/cpufreq/Kconfig.x86     |  2 +
>>   include/acpi/processor.h        | 94
>> +++++++++++++++++++++++++++--------------
>>   7 files changed, 142 insertions(+), 68 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 226d569..93d150d 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -143,6 +143,7 @@ config X86
>>          select ACPI_LEGACY_TABLES_LOOKUP if ACPI
>>          select X86_FEATURE_NAMES if PROC_FS
>>          select SRCU
>> +       select ACPI_CPU_FREQ_PSS if ACPI
>>
>>   config INSTRUCTION_DECODER
>>          def_bool y
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index ab2cbb5..00748dc 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -166,17 +166,26 @@ config ACPI_DOCK
>>            This driver supports ACPI-controlled docking stations and
>> removable
>>            drive bays such as the IBM Ultrabay and the Dell Module Bay.
>>
>> +config ACPI_CPU_FREQ_PSS
>> +       bool
>> +       depends on ACPI_PROCESSOR && CPU_FREQ
>> +       select THERMAL
>> +       help
>> +         This driver implements ACPI methods for controlling CPU
>> performance
>> +         using PSS methods as described in the ACPI spec. It also enables
>> support
>> +         for ACPI based performance throttling (TSS) and ACPI based
>> thermal
>> +         monitoring. It is required by several flavors of cpufreq
>> +         performance-state drivers.
>> +
>
>
> Though I agree CPUFreq and the thermal control are related, having _PSS
> in config name shouldn't match well IMO. You can have more generic name.

Do you have any suggestions?

>
> You are selecting one config while depending on the other, any
> particular reason ?
>

What is the problem? Sorry, I didn't follow.

Regards,
Ashwin.

Re: [PATCH v7 8/8] PCC: Enable PCC only when needed

[Ashwin Chaugule]

On 21 July 2015 at 21:28, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, July 21, 2015 04:28:43 PM Sudeep Holla wrote:
>> Hi Rafael,
>>
>> On 21/07/15 15:34, Rafael J. Wysocki wrote:
>> > Hi Sudeep,
>> >
>> > On Tue, Jul 21, 2015 at 11:23 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> >>
>> >>
>> >> On 20/07/15 23:04, Rafael J. Wysocki wrote:
>> >>>
>> >>> On Monday, July 20, 2015 03:22:37 PM Sudeep Holla wrote:
>> >>>>
>> >>>>
>> >>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>> >>>>>
>> >>>>> CPPC is the first client to make use of the PCC Mailbox channel. So
>> >>>>> enable it only when CPPC is also enabled.
>> >>>>>
>> >>>> This sounds like a reverse dependency to me. So if there's some client
>> >>>> unrelated to CPPC using PCC, CPPC_LIB needs to be selected to enable PCC
>> >>>> ?
>> >>>
>> >>>
>> >>> No.  The other client will need to select PCC too.
>> >>
>> >>
>> >> Yes the PCC users/clients selecting PCC is fine and that's already
>> >> done(i.e. ACPI_CPPC_LIB selects PCC). I still don't understand the need
>> >> for this change, also how will other clients possibly select PCC which
>> >> now depends on CPPC_LIB ? e.g. if we have
>> >>
>> >> config ACPI_XYZ_LIB
>> >>          select PCC
>> >>
>> >> config ACPI_XYZ
>> >>          select ACPI_XYZ_LIB
>> >>
>> >> Won't this shout warning: (ACPI_XYZ_LIB && ACPI_CPPC_LIB) selects PCC
>> >> which has unmet direct dependencies (MAILBOX && ACPI && ACPI_CPPC_LIB)
>> >> if ACPI_CPPC_LIB is not selected ?
>> >
>> > That depends on the "depends on" clauses used.  Selecting itself
>> > doesn't cause any dependencies to appear.
>> >
>>
>> Agreed and I am absolutely fine with that. But if you look at this
>> patch, it does
>>
>> config PCC
>>       bool "Platform Communication Channel Driver"
>>       depends on ACPI && ACPI_CPPC_LIB
>
> My bad, I've evidently overlooked that.
>
> If PPC is selected from ACPI_CPPC_LIB, the "depends on" above is
> obviously not needed.

Thanks Sudeep.
So I'll take this dependency out and default PCC to 'n'. Think that
should work for all cases. Agree?

Thanks,
Ashwin.

Re: [PATCH v7 1/8] PCC: Initialize PCC Mailbox earlier at boot

[Ashwin Chaugule]

On 20 July 2015 at 10:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>
>> This change initializes the PCC Mailbox earlier than
>> the ACPI processor driver. This enables drivers introduced
>> in follow up patches (e.g. CPPC) to be probed via the ACPI
>> processor driver interface. The CPPC probe requires the PCC
>> channel to be initialized for it to query each CPUs performance
>> capabilities.
>>
>> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> Reviewed-by: Al Stone <al.stone@linaro.org>
>> ---
>>   drivers/mailbox/pcc.c | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>> index 7e91d68..fcda63e 100644
>> --- a/drivers/mailbox/pcc.c
>> +++ b/drivers/mailbox/pcc.c
>> @@ -352,4 +352,10 @@ static int __init pcc_init(void)
>>
>>         return 0;
>>   }
>> -device_initcall(pcc_init);
>> +
>> +/*
>> + * Make pcc init postcore so that users of this mailbox
>> + * such as the ACPI Processor driver have it available
>> + * at their init.
>> + */
>> +postcore_initcall(pcc_init);
>>
>
> I assumed you have explored other options like deferred probe and
> finally resorted to this as they are not feasible ?

Yes, and this is the only one that works as expected. :)

> Because setting up
> these kind of dependency are prone to create issues later on.
>
> Regards,
> Sudeep

Re: [PATCH v7 3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

[Ashwin Chaugule]

On 20 July 2015 at 10:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>
>> This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE,
>> which is auto selected by architectures which support the ACPI
>> based C states for CPU Idle management.
>>
>> The processor_idle driver in its present form contains declarations
>> specific to X86 and IA64. Since there are no reasonable defaults
>> for other architectures e.g. ARM64, the driver is selected only by
>> the arch/x86/Kconfig.
>>
>> This helps in decoupling the ACPI processor_driver from the ACPI
>> processor_idle driver which is useful for the upcoming alternative
>> patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI).
>>
>> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> ---
>>   drivers/acpi/Kconfig     |  6 +++++-
>>   drivers/acpi/Makefile    |  3 ++-
>>   include/acpi/processor.h | 26 ++++++++++++++++++++++++--
>>   3 files changed, 31 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 00748dc..8a60b6e 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -177,9 +177,13 @@ config ACPI_CPU_FREQ_PSS
>>           monitoring. It is required by several flavors of cpufreq
>>           performance-state drivers.
>>
>> +config ACPI_PROCESSOR_IDLE
>> +       def_bool y
>> +       depends on X86 || IA64
>> +
>
>
> In general, you need to split this series so that initially few patches
> deal with all the existing Kconfig fix-ups and then introduce
> PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
> support.

Hm. I tried to maintain bisectability and make it easier for you to
rebase LPI patchwork too. Let me see if I can revisit now that I'm
back from vacation. :)

>
> Regards,
> Sudeep

Re: [PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Ashwin Chaugule]

On 20 July 2015 at 17:59, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Monday, July 20, 2015 03:20:46 PM Sudeep Holla wrote:
>>
>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>> > The ACPI processor driver is currently tied too closely
>> > to the ACPI P-states (PSS) and other related constructs
>> > for controlling CPU performance.
>> >
>> > The newer ACPI specification (v5.1 onwards) introduces
>> > alternative methods to PSS. These new mechanisms are
>> > described within each ACPI Processor object and so they
>> > need to be scanned whenever a new Processor object is detected.
>> > This patch introduces a new Kconfig symbol to allow for
>> > finer configurability among the two options for controlling
>> > performance states. There is no change in functionality and
>> > the option is auto-selected by the architecture Kconfig files.
>> >
>> > The following patchwork introduces CPPC: A newer method of
>> > controlling CPU performance. The OS is not expected to support
>> > CPPC and PSS at runtime. So the kconfig option lets us make
>> > these two mutually exclusive at compile time.
>> >
>> > Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> > ---
>> >   arch/x86/Kconfig                |  1 +
>> >   drivers/acpi/Kconfig            | 19 ++++++---
>> >   drivers/acpi/Makefile           |  6 +--
>> >   drivers/acpi/processor_driver.c | 86 +++++++++++++++++++++++++------------
>> >   drivers/cpufreq/Kconfig         |  2 +-
>> >   drivers/cpufreq/Kconfig.x86     |  2 +
>> >   include/acpi/processor.h        | 94 +++++++++++++++++++++++++++--------------
>> >   7 files changed, 142 insertions(+), 68 deletions(-)
>> >
>> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> > index 226d569..93d150d 100644
>> > --- a/arch/x86/Kconfig
>> > +++ b/arch/x86/Kconfig
>> > @@ -143,6 +143,7 @@ config X86
>> >          select ACPI_LEGACY_TABLES_LOOKUP if ACPI
>> >          select X86_FEATURE_NAMES if PROC_FS
>> >          select SRCU
>> > +       select ACPI_CPU_FREQ_PSS if ACPI
>> >
>> >   config INSTRUCTION_DECODER
>> >          def_bool y
>> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> > index ab2cbb5..00748dc 100644
>> > --- a/drivers/acpi/Kconfig
>> > +++ b/drivers/acpi/Kconfig
>> > @@ -166,17 +166,26 @@ config ACPI_DOCK
>> >            This driver supports ACPI-controlled docking stations and removable
>> >            drive bays such as the IBM Ultrabay and the Dell Module Bay.
>> >
>> > +config ACPI_CPU_FREQ_PSS
>> > +       bool
>> > +       depends on ACPI_PROCESSOR && CPU_FREQ
>> > +       select THERMAL
>> > +       help
>> > +         This driver implements ACPI methods for controlling CPU performance
>> > +         using PSS methods as described in the ACPI spec. It also enables support
>> > +         for ACPI based performance throttling (TSS) and ACPI based thermal
>> > +         monitoring. It is required by several flavors of cpufreq
>> > +         performance-state drivers.
>> > +
>>
>> Though I agree CPUFreq and the thermal control are related, having _PSS
>> in config name shouldn't match well IMO. You can have more generic name.
>>
>> You are selecting one config while depending on the other, any
>> particular reason ?
>>
>> I don't like adding these, but I leave it to Rafael.
>
> My opinion is analogous. :-)

I dont like bloating Kconfigs either, but its slim pickings in this case.

>
> I *guess* the idea was to avoid selecting ACPI_CPU_FREQ_PSS withouth
> ACPI_PROCESSOR so we don't build unnecessary code.  That's a good point,
> but I would also like to keep they way ACPI_PROCESSOR works on x86 and
> ia64 without adding new user-selectable Kconfig options.
>
> So, what about this:
>
>  config ACPI_PROCESSOR
>         tristate "Processor"
>         select THERMAL
>         select CPU_IDLE
> -       depends on X86 || IA64
> +       select ACPI_CPU_FREQ_PSS if X86 || IA64
>         default y
>         help
>           This driver installs ACPI as the idle handler for Linux and uses
>
> and define ACPI_CPU_FREQ_PSS in analogy with ACPI_CCA_REQUIRED for example?

Seems better. I'll respin this series with the feedback so far.


Thanks,
Ashwin.

Re: [PATCH v7 2/8] ACPI: Split out ACPI PSS from ACPI Processor driver

[Sudeep Holla]

On 03/08/15 18:29, Ashwin Chaugule wrote:
> On 20 July 2015 at 10:20, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>
>>> The ACPI processor driver is currently tied too closely
>>> to the ACPI P-states (PSS) and other related constructs
>>> for controlling CPU performance.
>>>
>>> The newer ACPI specification (v5.1 onwards) introduces
>>> alternative methods to PSS. These new mechanisms are
>>> described within each ACPI Processor object and so they
>>> need to be scanned whenever a new Processor object is detected.
>>> This patch introduces a new Kconfig symbol to allow for
>>> finer configurability among the two options for controlling
>>> performance states. There is no change in functionality and
>>> the option is auto-selected by the architecture Kconfig files.
>>>
>>> The following patchwork introduces CPPC: A newer method of
>>> controlling CPU performance. The OS is not expected to support
>>> CPPC and PSS at runtime. So the kconfig option lets us make
>>> these two mutually exclusive at compile time.
>>>
>>> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>>> ---
>>>    arch/x86/Kconfig                |  1 +
>>>    drivers/acpi/Kconfig            | 19 ++++++---
>>>    drivers/acpi/Makefile           |  6 +--
>>>    drivers/acpi/processor_driver.c | 86
>>> +++++++++++++++++++++++++------------
>>>    drivers/cpufreq/Kconfig         |  2 +-
>>>    drivers/cpufreq/Kconfig.x86     |  2 +
>>>    include/acpi/processor.h        | 94
>>> +++++++++++++++++++++++++++--------------
>>>    7 files changed, 142 insertions(+), 68 deletions(-)
>>>
>>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>>> index 226d569..93d150d 100644
>>> --- a/arch/x86/Kconfig
>>> +++ b/arch/x86/Kconfig
>>> @@ -143,6 +143,7 @@ config X86
>>>           select ACPI_LEGACY_TABLES_LOOKUP if ACPI
>>>           select X86_FEATURE_NAMES if PROC_FS
>>>           select SRCU
>>> +       select ACPI_CPU_FREQ_PSS if ACPI
>>>
>>>    config INSTRUCTION_DECODER
>>>           def_bool y
>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>> index ab2cbb5..00748dc 100644
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -166,17 +166,26 @@ config ACPI_DOCK
>>>             This driver supports ACPI-controlled docking stations and
>>> removable
>>>             drive bays such as the IBM Ultrabay and the Dell Module Bay.
>>>
>>> +config ACPI_CPU_FREQ_PSS
>>> +       bool
>>> +       depends on ACPI_PROCESSOR && CPU_FREQ
>>> +       select THERMAL
>>> +       help
>>> +         This driver implements ACPI methods for controlling CPU
>>> performance
>>> +         using PSS methods as described in the ACPI spec. It also enables
>>> support
>>> +         for ACPI based performance throttling (TSS) and ACPI based
>>> thermal
>>> +         monitoring. It is required by several flavors of cpufreq
>>> +         performance-state drivers.
>>> +
>>
>>
>> Though I agree CPUFreq and the thermal control are related, having _PSS
>> in config name shouldn't match well IMO. You can have more generic name.
>
> Do you have any suggestions?
>

No, so I am fine with ACPI_CPU_FREQ_PSS for now, we can change later if
required as along as it's not user-selectable I suppose.

>>
>> You are selecting one config while depending on the other, any
>> particular reason ?
>>
>
> What is the problem? Sorry, I didn't follow.
>

Just follow what Rafael said, he explained it better than me, I was bit
vague here but implied same thing.

Regards,
Sudeep

Re: [PATCH v7 3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

[Sudeep Holla]

On 03/08/15 18:40, Ashwin Chaugule wrote:
> On 20 July 2015 at 10:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>
>>> This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE,
>>> which is auto selected by architectures which support the ACPI
>>> based C states for CPU Idle management.
>>>
>>> The processor_idle driver in its present form contains declarations
>>> specific to X86 and IA64. Since there are no reasonable defaults
>>> for other architectures e.g. ARM64, the driver is selected only by
>>> the arch/x86/Kconfig.
>>>
>>> This helps in decoupling the ACPI processor_driver from the ACPI
>>> processor_idle driver which is useful for the upcoming alternative
>>> patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI).
>>>
>>> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>>> ---
>>>    drivers/acpi/Kconfig     |  6 +++++-
>>>    drivers/acpi/Makefile    |  3 ++-
>>>    include/acpi/processor.h | 26 ++++++++++++++++++++++++--
>>>    3 files changed, 31 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>> index 00748dc..8a60b6e 100644
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -177,9 +177,13 @@ config ACPI_CPU_FREQ_PSS
>>>            monitoring. It is required by several flavors of cpufreq
>>>            performance-state drivers.
>>>
>>> +config ACPI_PROCESSOR_IDLE
>>> +       def_bool y
>>> +       depends on X86 || IA64
>>> +
>>
>>
>> In general, you need to split this series so that initially few patches
>> deal with all the existing Kconfig fix-ups and then introduce
>> PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
>> support.
>
> Hm. I tried to maintain bisectability and make it easier for you to
> rebase LPI patchwork too. Let me see if I can revisit now that I'm
> back from vacation. :)
>

How about you just drop any idle related changes so that I will handle
that to keep it simple.

Regards,
Sudeep

Re: [PATCH v7 8/8] PCC: Enable PCC only when needed

[Sudeep Holla]

On 03/08/15 18:35, Ashwin Chaugule wrote:
> On 21 July 2015 at 21:28, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> On Tuesday, July 21, 2015 04:28:43 PM Sudeep Holla wrote:
>>> Hi Rafael,
>>>

[...]

>>>
>>> Agreed and I am absolutely fine with that. But if you look at this
>>> patch, it does
>>>
>>> config PCC
>>>        bool "Platform Communication Channel Driver"
>>>        depends on ACPI && ACPI_CPPC_LIB
>>
>> My bad, I've evidently overlooked that.
>>
>> If PPC is selected from ACPI_CPPC_LIB, the "depends on" above is
>> obviously not needed.
>
> Thanks Sudeep.
> So I'll take this dependency out and default PCC to 'n'. Think that
> should work for all cases. Agree?
>

Yes

Regards,
Sudeep

Re: [PATCH v7 3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

[Ashwin Chaugule]

On 4 August 2015 at 10:51, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 03/08/15 18:40, Ashwin Chaugule wrote:
>>
>> On 20 July 2015 at 10:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>
>>>
>>> In general, you need to split this series so that initially few patches
>>> deal with all the existing Kconfig fix-ups and then introduce
>>> PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
>>> support.
>>
>>
>> Hm. I tried to maintain bisectability and make it easier for you to
>> rebase LPI patchwork too. Let me see if I can revisit now that I'm
>> back from vacation. :)
>>
>
> How about you just drop any idle related changes so that I will handle
> that to keep it simple.

Unfortunately I can't skip idle changes completely since it is tightly
coupled with the acpi_processor driver as well.

Regards,
Ashwin.

Re: [PATCH v7 4/8] ACPI: Introduce CPU performance controls using CPPC

[Sudeep Holla]

Hi Ashwin,

On 09/07/15 19:04, 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 adds a shim which exports commonly used functions
> to get and set CPPC specific controls for each CPU. This enables
> CPUFreq drivers to gather per CPU performance data and use
> with exisiting governors or even allows for customized governors
> which are implemented inside CPUFreq drivers.
>
> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> Reviewed-by: Al Stone <al.stone@linaro.org>
> ---
>   drivers/acpi/Kconfig     |  14 +
>   drivers/acpi/Makefile    |   1 +
>   drivers/acpi/cppc_acpi.c | 812 +++++++++++++++++++++++++++++++++++++++++++++++
>   include/acpi/cppc_acpi.h | 137 ++++++++
>   4 files changed, 964 insertions(+)
>   create mode 100644 drivers/acpi/cppc_acpi.c
>   create mode 100644 include/acpi/cppc_acpi.h
>

[..]

> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> new file mode 100644
> index 0000000..9c89767
> --- /dev/null
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -0,0 +1,812 @@
> +/*
> + * CPPC (Collaborative Processor Performance Control) methods used
> + * by CPUfreq drivers.
> + *
> + * (C) Copyright 2014, 2015 Linaro Ltd.
> + * Author: Ashwin Chaugule <ashwin.chaugule@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2
> + * of the License.
> + *
> + * CPPC describes a few methods for controlling CPU performance using
> + * information from a per CPU table called CPC. This table is described in
> + * the ACPI v5.0+ specification. The table consists of a list of
> + * registers which may be memory mapped or hardware registers and also may
> + * include some static integer values.
> + *
> + * CPU performance is on an abstract continuous scale as against a discretized
> + * P-state scale which is tied to CPU frequency only. In brief, the basic
> + * operation involves:
> + *
> + * - OS makes a CPU performance request. (Can provide min and max bounds)
> + *
> + * - Platform (such as BMC) is free to optimize request within requested bounds
> + *   depending on power/thermal budgets etc.
> + *
> + * - Platform conveys its decision back to OS
> + *
> + * The communication between OS and platform occurs through another medium
> + * called (PCC) Platform Communication Channel. This is a generic mailbox like
> + * mechanism which includes doorbell semantics to indicate register updates.
> + * See drivers/mailbox/pcc.c for details on PCC.
> + *
> + * Finer details about the PCC and CPPC spec are available in the latest
> + * ACPI 5.1 specification.
> + */
> +
> +#define pr_fmt(fmt)    "ACPI CPPC: " fmt
> +
> +#include <linux/cpufreq.h>
> +#include <linux/delay.h>
> +
> +#include <acpi/cppc_acpi.h>
> +/*
> + * Lock to provide mutually exclusive access to the PCC
> + * channel. e.g. When the remote updates the shared region
> + * with new data, the reader needs to be protected from
> + * other CPUs activity on the same channel.
> + */
> +static DEFINE_SPINLOCK(pcc_lock);
> +
> +static DEFINE_PER_CPU(struct cpc_desc *, cpc_desc_ptr);
> +
> +/* This layer handles all the PCC specifics for CPPC. */
> +static struct mbox_chan *pcc_channel;
> +static void __iomem *pcc_comm_addr;
> +static u64 comm_base_addr;
> +static int pcc_subspace_idx = -1;
> +static u16 pcc_cmd_delay;
> +static int pcc_channel_acquired;
> +
> +#define NUM_RETRIES 500
> +
> +static int send_pcc_cmd(u16 cmd)
> +{
> +       int err, result = 0;
> +       int retries = NUM_RETRIES;
> +       struct acpi_pcct_hw_reduced *pcct_ss = pcc_channel->con_priv;
> +       struct acpi_pcct_shared_memory *generic_comm_base =
> +               (struct acpi_pcct_shared_memory *) pcc_comm_addr;
> +       u32 cmd_latency = pcct_ss->latency;
> +
> +       /* Write to the shared comm region. */
> +       writew(cmd, &generic_comm_base->command);
> +
> +       /* Flip CMD COMPLETE bit */
> +       writew(0, &generic_comm_base->status);
> +
> +       err = mbox_send_message(pcc_channel, &cmd);
> +       if (err < 0) {
> +               pr_err("Err sending PCC mbox message. cmd:%d, ret:%d\n",
> +                               cmd, err);
> +               return err;
> +       }
> +
> +       /* Wait for a nominal time to let platform processes command. */
> +       udelay(cmd_latency);

I don't think above delay belongs here. It should be part of PCC driver.
I need to go through PCC again, initially I objected that some part of
client code was in PCC driver which seems to be fixed now with commit
33350e6b1833 ("Mailbox: Restructure and simplify PCC mailbox code").

But now I think the controller code is getting into the client side.
Ideally you shouldn't access anything related to PCC controller here.

As I started looking at PCC, I found few issue there. I will post them
separately for discussion.

Regards,
Sudeep

Re: [PATCH v7 3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

[Sudeep Holla]

On 04/08/15 15:58, Ashwin Chaugule wrote:
> On 4 August 2015 at 10:51, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 03/08/15 18:40, Ashwin Chaugule wrote:
>>>
>>> On 20 July 2015 at 10:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>>
>>>>
>>>> In general, you need to split this series so that initially few patches
>>>> deal with all the existing Kconfig fix-ups and then introduce
>>>> PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
>>>> support.
>>>
>>>
>>> Hm. I tried to maintain bisectability and make it easier for you to
>>> rebase LPI patchwork too. Let me see if I can revisit now that I'm
>>> back from vacation. :)
>>>
>>
>> How about you just drop any idle related changes so that I will handle
>> that to keep it simple.
>
> Unfortunately I can't skip idle changes completely since it is tightly
> coupled with the acpi_processor driver as well.
>

True, but only for ARM64 where we haven't enabled ACPI_PROCESSOR yet in
mainline. So from that perspective, it should not cause any issue for
keeping changes bisectable on x86/ia64. You can keep these idle changes
locally for your testing. Trying to get everything at once will
definitely be problematic IMO.

Regards,
Sudeep

Re: [PATCH v7 4/8] ACPI: Introduce CPU performance controls using CPPC

[Ashwin Chaugule]

On 4 August 2015 at 11:06, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Hi Ashwin,
>
> On 09/07/15 19:04, 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 adds a shim which exports commonly used functions
>> to get and set CPPC specific controls for each CPU. This enables
>> CPUFreq drivers to gather per CPU performance data and use
>> with exisiting governors or even allows for customized governors
>> which are implemented inside CPUFreq drivers.
>>
>> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> Reviewed-by: Al Stone <al.stone@linaro.org>
>> ---
>>   drivers/acpi/Kconfig     |  14 +
>>   drivers/acpi/Makefile    |   1 +
>>   drivers/acpi/cppc_acpi.c | 812
>> +++++++++++++++++++++++++++++++++++++++++++++++
>>   include/acpi/cppc_acpi.h | 137 ++++++++
>>   4 files changed, 964 insertions(+)
>>   create mode 100644 drivers/acpi/cppc_acpi.c
>>   create mode 100644 include/acpi/cppc_acpi.h
>>
>
> [..]
>
>
>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
>> new file mode 100644
>> index 0000000..9c89767
>> --- /dev/null
>> +++ b/drivers/acpi/cppc_acpi.c
>> @@ -0,0 +1,812 @@
>> +/*
>> + * CPPC (Collaborative Processor Performance Control) methods used
>> + * by CPUfreq drivers.
>> + *
>> + * (C) Copyright 2014, 2015 Linaro Ltd.
>> + * Author: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; version 2
>> + * of the License.
>> + *
>> + * CPPC describes a few methods for controlling CPU performance using
>> + * information from a per CPU table called CPC. This table is described
>> in
>> + * the ACPI v5.0+ specification. The table consists of a list of
>> + * registers which may be memory mapped or hardware registers and also
>> may
>> + * include some static integer values.
>> + *
>> + * CPU performance is on an abstract continuous scale as against a
>> discretized
>> + * P-state scale which is tied to CPU frequency only. In brief, the basic
>> + * operation involves:
>> + *
>> + * - OS makes a CPU performance request. (Can provide min and max bounds)
>> + *
>> + * - Platform (such as BMC) is free to optimize request within requested
>> bounds
>> + *   depending on power/thermal budgets etc.
>> + *
>> + * - Platform conveys its decision back to OS
>> + *
>> + * The communication between OS and platform occurs through another
>> medium
>> + * called (PCC) Platform Communication Channel. This is a generic mailbox
>> like
>> + * mechanism which includes doorbell semantics to indicate register
>> updates.
>> + * See drivers/mailbox/pcc.c for details on PCC.
>> + *
>> + * Finer details about the PCC and CPPC spec are available in the latest
>> + * ACPI 5.1 specification.
>> + */
>> +
>> +#define pr_fmt(fmt)    "ACPI CPPC: " fmt
>> +
>> +#include <linux/cpufreq.h>
>> +#include <linux/delay.h>
>> +
>> +#include <acpi/cppc_acpi.h>
>> +/*
>> + * Lock to provide mutually exclusive access to the PCC
>> + * channel. e.g. When the remote updates the shared region
>> + * with new data, the reader needs to be protected from
>> + * other CPUs activity on the same channel.
>> + */
>> +static DEFINE_SPINLOCK(pcc_lock);
>> +
>> +static DEFINE_PER_CPU(struct cpc_desc *, cpc_desc_ptr);
>> +
>> +/* This layer handles all the PCC specifics for CPPC. */
>> +static struct mbox_chan *pcc_channel;
>> +static void __iomem *pcc_comm_addr;
>> +static u64 comm_base_addr;
>> +static int pcc_subspace_idx = -1;
>> +static u16 pcc_cmd_delay;
>> +static int pcc_channel_acquired;
>> +
>> +#define NUM_RETRIES 500
>> +
>> +static int send_pcc_cmd(u16 cmd)
>> +{
>> +       int err, result = 0;
>> +       int retries = NUM_RETRIES;
>> +       struct acpi_pcct_hw_reduced *pcct_ss = pcc_channel->con_priv;
>> +       struct acpi_pcct_shared_memory *generic_comm_base =
>> +               (struct acpi_pcct_shared_memory *) pcc_comm_addr;
>> +       u32 cmd_latency = pcct_ss->latency;
>> +
>> +       /* Write to the shared comm region. */
>> +       writew(cmd, &generic_comm_base->command);
>> +
>> +       /* Flip CMD COMPLETE bit */
>> +       writew(0, &generic_comm_base->status);
>> +
>> +       err = mbox_send_message(pcc_channel, &cmd);
>> +       if (err < 0) {
>> +               pr_err("Err sending PCC mbox message. cmd:%d, ret:%d\n",
>> +                               cmd, err);
>> +               return err;
>> +       }
>> +
>> +       /* Wait for a nominal time to let platform processes command. */
>> +       udelay(cmd_latency);
>
>
> I don't think above delay belongs here. It should be part of PCC driver.

This delay is PCC subspace specific, so I think it belongs to a client
(subspace).

> I need to go through PCC again, initially I objected that some part of
> client code was in PCC driver which seems to be fixed now with commit
> 33350e6b1833 ("Mailbox: Restructure and simplify PCC mailbox code").
>
> But now I think the controller code is getting into the client side.
> Ideally you shouldn't access anything related to PCC controller here.

I think its fair to address all PCC details specific to the client in
the client side code. Moreover this makes it much cleaner to handle
multiple users of one subspace. e.g. multiple CPUs trying to
concurrently access the CPPC subspace.

>
> As I started looking at PCC, I found few issue there. I will post them
> separately for discussion.

Ok.

Regards,
Ashwin.

Re: [PATCH v7 3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

[Ashwin Chaugule]

On 4 August 2015 at 11:18, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 04/08/15 15:58, Ashwin Chaugule wrote:
>>
>> On 4 August 2015 at 10:51, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>
>>> On 03/08/15 18:40, Ashwin Chaugule wrote:
>>>>
>>>>
>>>> On 20 July 2015 at 10:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>>
>>>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>>>
>>>>>>
>>>>>
>>>>> In general, you need to split this series so that initially few patches
>>>>> deal with all the existing Kconfig fix-ups and then introduce
>>>>> PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
>>>>> support.
>>>>
>>>>
>>>>
>>>> Hm. I tried to maintain bisectability and make it easier for you to
>>>> rebase LPI patchwork too. Let me see if I can revisit now that I'm
>>>> back from vacation. :)
>>>>
>>>
>>> How about you just drop any idle related changes so that I will handle
>>> that to keep it simple.
>>
>>
>> Unfortunately I can't skip idle changes completely since it is tightly
>> coupled with the acpi_processor driver as well.
>>
>
> True, but only for ARM64 where we haven't enabled ACPI_PROCESSOR yet in
> mainline. So from that perspective, it should not cause any issue for
> keeping changes bisectable on x86/ia64. You can keep these idle changes
> locally for your testing. Trying to get everything at once will
> definitely be problematic IMO.

Bisectability aside, without the idle changes to decouple it from
ACPI_PROCESSOR, the CPPC code will be non-functional. CPPC code has
been around for review publicly for almost a year and we need it to be
mainlined soon. So, given that we've converged on a solution for new
Kconfigs for Idle and PSS and that they're separate patches, why not
let it progress forwards as part of this series?

Thanks,
Ashwin.

Re: [PATCH v7 4/8] ACPI: Introduce CPU performance controls using CPPC

[Sudeep Holla]

On 04/08/15 16:38, Ashwin Chaugule wrote:
> On 4 August 2015 at 11:06, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Hi Ashwin,
>>
>> On 09/07/15 19:04, 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 adds a shim which exports commonly used functions
>>> to get and set CPPC specific controls for each CPU. This enables
>>> CPUFreq drivers to gather per CPU performance data and use
>>> with exisiting governors or even allows for customized governors
>>> which are implemented inside CPUFreq drivers.
>>>
>>> Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>>> Reviewed-by: Al Stone <al.stone@linaro.org>
>>> ---
>>>    drivers/acpi/Kconfig     |  14 +
>>>    drivers/acpi/Makefile    |   1 +
>>>    drivers/acpi/cppc_acpi.c | 812
>>> +++++++++++++++++++++++++++++++++++++++++++++++
>>>    include/acpi/cppc_acpi.h | 137 ++++++++
>>>    4 files changed, 964 insertions(+)
>>>    create mode 100644 drivers/acpi/cppc_acpi.c
>>>    create mode 100644 include/acpi/cppc_acpi.h
>>>
>>
>> [..]
>>
>>
>>> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
>>> new file mode 100644
>>> index 0000000..9c89767
>>> --- /dev/null
>>> +++ b/drivers/acpi/cppc_acpi.c
>>> @@ -0,0 +1,812 @@
>>> +/*
>>> + * CPPC (Collaborative Processor Performance Control) methods used
>>> + * by CPUfreq drivers.
>>> + *
>>> + * (C) Copyright 2014, 2015 Linaro Ltd.
>>> + * Author: Ashwin Chaugule <ashwin.chaugule@linaro.org>
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License
>>> + * as published by the Free Software Foundation; version 2
>>> + * of the License.
>>> + *
>>> + * CPPC describes a few methods for controlling CPU performance using
>>> + * information from a per CPU table called CPC. This table is described
>>> in
>>> + * the ACPI v5.0+ specification. The table consists of a list of
>>> + * registers which may be memory mapped or hardware registers and also
>>> may
>>> + * include some static integer values.
>>> + *
>>> + * CPU performance is on an abstract continuous scale as against a
>>> discretized
>>> + * P-state scale which is tied to CPU frequency only. In brief, the basic
>>> + * operation involves:
>>> + *
>>> + * - OS makes a CPU performance request. (Can provide min and max bounds)
>>> + *
>>> + * - Platform (such as BMC) is free to optimize request within requested
>>> bounds
>>> + *   depending on power/thermal budgets etc.
>>> + *
>>> + * - Platform conveys its decision back to OS
>>> + *
>>> + * The communication between OS and platform occurs through another
>>> medium
>>> + * called (PCC) Platform Communication Channel. This is a generic mailbox
>>> like
>>> + * mechanism which includes doorbell semantics to indicate register
>>> updates.
>>> + * See drivers/mailbox/pcc.c for details on PCC.
>>> + *
>>> + * Finer details about the PCC and CPPC spec are available in the latest
>>> + * ACPI 5.1 specification.
>>> + */
>>> +
>>> +#define pr_fmt(fmt)    "ACPI CPPC: " fmt
>>> +
>>> +#include <linux/cpufreq.h>
>>> +#include <linux/delay.h>
>>> +
>>> +#include <acpi/cppc_acpi.h>
>>> +/*
>>> + * Lock to provide mutually exclusive access to the PCC
>>> + * channel. e.g. When the remote updates the shared region
>>> + * with new data, the reader needs to be protected from
>>> + * other CPUs activity on the same channel.
>>> + */
>>> +static DEFINE_SPINLOCK(pcc_lock);
>>> +
>>> +static DEFINE_PER_CPU(struct cpc_desc *, cpc_desc_ptr);
>>> +
>>> +/* This layer handles all the PCC specifics for CPPC. */
>>> +static struct mbox_chan *pcc_channel;
>>> +static void __iomem *pcc_comm_addr;
>>> +static u64 comm_base_addr;
>>> +static int pcc_subspace_idx = -1;
>>> +static u16 pcc_cmd_delay;
>>> +static int pcc_channel_acquired;
>>> +
>>> +#define NUM_RETRIES 500
>>> +
>>> +static int send_pcc_cmd(u16 cmd)
>>> +{
>>> +       int err, result = 0;
>>> +       int retries = NUM_RETRIES;
>>> +       struct acpi_pcct_hw_reduced *pcct_ss = pcc_channel->con_priv;
>>> +       struct acpi_pcct_shared_memory *generic_comm_base =
>>> +               (struct acpi_pcct_shared_memory *) pcc_comm_addr;
>>> +       u32 cmd_latency = pcct_ss->latency;
>>> +
>>> +       /* Write to the shared comm region. */
>>> +       writew(cmd, &generic_comm_base->command);
>>> +
>>> +       /* Flip CMD COMPLETE bit */
>>> +       writew(0, &generic_comm_base->status);
>>> +
>>> +       err = mbox_send_message(pcc_channel, &cmd);
>>> +       if (err < 0) {
>>> +               pr_err("Err sending PCC mbox message. cmd:%d, ret:%d\n",
>>> +                               cmd, err);
>>> +               return err;
>>> +       }
>>> +
>>> +       /* Wait for a nominal time to let platform processes command. */
>>> +       udelay(cmd_latency);
>>
>>
>> I don't think above delay belongs here. It should be part of PCC driver.
>
> This delay is PCC subspace specific, so I think it belongs to a client
> (subspace).
>

Sorry I overlooked at the spec, every channel specify these field so its
fine. I had previously misunderstood as there's only one table for each
controller rather than channel which is wrong. Sorry for the noise.

>> I need to go through PCC again, initially I objected that some part of
>> client code was in PCC driver which seems to be fixed now with commit
>> 33350e6b1833 ("Mailbox: Restructure and simplify PCC mailbox code").
>>
>> But now I think the controller code is getting into the client side.
>> Ideally you shouldn't access anything related to PCC controller here.
>
> I think its fair to address all PCC details specific to the client in
> the client side code. Moreover this makes it much cleaner to handle
> multiple users of one subspace. e.g. multiple CPUs trying to
> concurrently access the CPPC subspace.
>

Agreed, that's exactly what I wanted to say but I clearly interpreted
the tables incorrectly.

Regards,
Sudeep

Re: [PATCH v7 3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

[Sudeep Holla]

On 04/08/15 16:44, Ashwin Chaugule wrote:
> On 4 August 2015 at 11:18, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 04/08/15 15:58, Ashwin Chaugule wrote:
>>>
>>> On 4 August 2015 at 10:51, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>
>>>> On 03/08/15 18:40, Ashwin Chaugule wrote:
>>>>>
>>>>>
>>>>> On 20 July 2015 at 10:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>>>
>>>>>> On 09/07/15 19:04, Ashwin Chaugule wrote:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> In general, you need to split this series so that initially few patches
>>>>>> deal with all the existing Kconfig fix-ups and then introduce
>>>>>> PCC/PSS/CPPC related stuffs. That would help me rebase and test _LPI
>>>>>> support.
>>>>>
>>>>>
>>>>>
>>>>> Hm. I tried to maintain bisectability and make it easier for you to
>>>>> rebase LPI patchwork too. Let me see if I can revisit now that I'm
>>>>> back from vacation. :)
>>>>>
>>>>
>>>> How about you just drop any idle related changes so that I will handle
>>>> that to keep it simple.
>>>
>>>
>>> Unfortunately I can't skip idle changes completely since it is tightly
>>> coupled with the acpi_processor driver as well.
>>>
>>
>> True, but only for ARM64 where we haven't enabled ACPI_PROCESSOR yet in
>> mainline. So from that perspective, it should not cause any issue for
>> keeping changes bisectable on x86/ia64. You can keep these idle changes
>> locally for your testing. Trying to get everything at once will
>> definitely be problematic IMO.
>
> Bisectability aside, without the idle changes to decouple it from
> ACPI_PROCESSOR, the CPPC code will be non-functional. CPPC code has
> been around for review publicly for almost a year and we need it to be
> mainlined soon. So, given that we've converged on a solution for new
> Kconfigs for Idle and PSS and that they're separate patches, why not
> let it progress forwards as part of this series?
>

Sorry, I didn't mean to block this series in anyway. I was just thinking
on how to post the preparatory changes to introduce _LPI. I prefer to
base it on mainline rather than this patch series and hence I made that
request.

Regards,
Sudeep

Re: [PATCH v7 3/8] ACPI: Decouple ACPI idle and ACPI processor drivers

[Ashwin Chaugule]

Hi Sudeep,

On 4 August 2015 at 13:00, Sudeep Holla <sudeep.holla@arm.com> wrote:

> On 04/08/15 16:44, Ashwin Chaugule wrote:
>> On 4 August 2015 at 11:18, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> Bisectability aside, without the idle changes to decouple it from
>> ACPI_PROCESSOR, the CPPC code will be non-functional. CPPC code has
>> been around for review publicly for almost a year and we need it to be
>> mainlined soon. So, given that we've converged on a solution for new
>> Kconfigs for Idle and PSS and that they're separate patches, why not
>> let it progress forwards as part of this series?
>>
> Sorry, I didn't mean to block this series in anyway. I was just thinking
> on how to post the preparatory changes to introduce _LPI. I prefer to
> base it on mainline rather than this patch series and hence I made that
> request.
>

Can you please try rebasing with Patch 2,3,6 and 9 of the V8 series?
Those should get you going for your LPI work.

Thanks,
Ashwin.