On 26 May 2015 at 17:22, Pandruvada, Srinivas srinivas.pandruvada@intel.com wrote:
On Mon, 2015-05-25 at 17:50 -0400, Ashwin Chaugule wrote:
The ACPI processor driver is currently tied too closely to the ACPI C-states (CST), P-states (PSS) and other related constructs for controlling CPU idle and CPU performance.
The newer ACPI specification (v5.1 onwards) introduces alternative methods to CST and 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 two new Kconfig symbols to allow for finer configurability among the various options for controlling CPU idle and performance states. There is no change in functionality and these options are defaulted to enabled to maintain previous behaviour.
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
drivers/acpi/Kconfig | 41 +++++++++++---- drivers/acpi/Makefile | 7 +-- drivers/acpi/processor_driver.c | 85 ++++++++++++++++++++----------- drivers/cpufreq/Kconfig | 2 +- drivers/cpufreq/Kconfig.x86 | 2 + include/acpi/processor.h | 109 ++++++++++++++++++++++++++++++++++------ 6 files changed, 187 insertions(+), 59 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index ab2cbb5..d98d304 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -163,23 +163,42 @@ config ACPI_FAN config ACPI_DOCK bool "Dock" help
This driver supports ACPI-controlled docking stations and removabledrive bays such as the IBM Ultrabay and the Dell Module Bay.
This driver supports ACPI-controlled docking stations and removabledrive bays such as the IBM Ultrabay and the Dell Module Bay.To be consistent align help text to letter "l" of help.
Ok.
Also checkpatch errors in this file.
Arg. I ran checkpatch first, then made more mods and forgot to run it again. Will make sure its done before sending out the final version.
-static int __acpi_processor_start(struct acpi_device *device) +#ifdef CONFIG_ACPI_PSS +static int acpi_pss_init(struct acpi_processor *pr, struct acpi_device *device) {
This name sounds to me that it it initializing something to do with _PSS only. But this function does more than that. Like handling ppc change and also thermal cdev register. Can we have some better name?
True. I couldn't really come up with anything better. From the way this thing was structured originally, everything seems linked to PSS one way or another. (including CSS based idle).
How about acpi_legacy_perf_init() ?
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);When CPPC is present, you don't need support for _PTC, _TSS and _TPC?
Nope.
----8<---- 8.4.7.1.10 Relationship to other ACPI-defined Objects and Notifications If _CPC is present, its use supersedes the use of the following existing ACPI objects: • The P_BLK P_CNT register • _PTC • _TSS • _TPC • _TSD • _TDL • _PCT • _PSS • _PPC • _PDL • Notify 0x80 on the processor device • Notify 0x82 on the processor device The _PSD object may be used to specify domain dependencies between processors. On a system with heterogeneous processors, all processors within a single domain must have the same performance capabilities.
----8<----
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; }Don't you need this thermal_ call for when controlling via CPPC? I think you should move to common start function.
I'd prefer to keep thermal stuff outside of CPPC for now. Everyone I've discussed with in the ARM64 server space plans to handle thermal independently on a remote processor. If that changes, then we'll come back to this. Anyway, as it is today, the thermal stuff in ACPI depends on TSS, which will need changes for CPPC.
I feel that all the old function did was relevant to CPPC support also. except PPC change. So you may just need to add call to acpi_cppc_processor_probe() for CPPC support.
I hope the above explains this.
Thanks, Ashwin.