Liu, Jinsong
2011-Dec-22 10:09 UTC
[PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
From ca403566e922dde51e8809d7489337be4a55adfc Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 15:59:02 +0800
Subject: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
This patch update Xen Cx notify.
Current Cx notify has 2 potential trigger points w/ some logically redundant.
We remove the Cx notify point which is outside __xen_acpi_processor_add,
merging its logic to the Cx notify point inside __xen_acpi_processor_add.
This would more clean, as what native Cx did.
This patch also add Xen PPC handle when cpu hotadd.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
drivers/acpi/processor_xen.c | 103 +++++++++++++++++++++++-------------------
1 files changed, 57 insertions(+), 46 deletions(-)
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 3af1f73..083e2b1 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -283,6 +283,59 @@ static int xen_acpi_processor_get_info(struct acpi_device
*device)
return 0;
}
+static int xen_acpi_processor_get_platform_limit(struct acpi_processor *pr)
+{
+ acpi_status status = 0;
+ unsigned long long ppc = 0;
+
+ if (!pr)
+ return -EINVAL;
+
+ /*
+ * _PPC indicates the maximum state currently supported by the platform
+ * (e.g. 0 = states 0..n; 1 = states 1..n; etc.
+ */
+ status = acpi_evaluate_integer(pr->handle, "_PPC", NULL,
&ppc);
+
+ if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
+ ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PPC"));
+ return -ENODEV;
+ }
+
+ pr->performance_platform_limit = (int)ppc;
+
+ return 0;
+}
+
+static int xen_acpi_processor_ppc_has_changed(struct acpi_processor *pr)
+{
+ int ret;
+
+ ret = xen_acpi_processor_get_platform_limit(pr);
+
+ if (ret < 0)
+ return ret;
+ else
+ return processor_cntl_xen_notify(pr,
+ PROCESSOR_PM_CHANGE, PM_TYPE_PERF);
+}
+
+static void __cpuinit xen_acpi_processor_power_init(struct acpi_processor *pr,
+ struct acpi_device *device)
+{
+ if (likely(!pr->flags.power_setup_done)) {
+ /* reset idle boot option which we don''t care */
+ boot_option_idle_override = IDLE_NO_OVERRIDE;
+ acpi_processor_power_init(pr, device);
+ /* set to IDLE_HALT for trapping into Xen */
+ boot_option_idle_override = IDLE_HALT;
+
+ if (pr->flags.power)
+ processor_cntl_xen_notify(pr,
+ PROCESSOR_PM_INIT, PM_TYPE_IDLE);
+ }
+}
+
static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
{
struct acpi_processor *pr = NULL;
@@ -339,14 +392,12 @@ static int __cpuinit __xen_acpi_processor_add(struct
acpi_device *device)
}
#ifdef CONFIG_CPU_FREQ
- acpi_processor_ppc_has_changed(pr, 0);
+ xen_acpi_processor_ppc_has_changed(pr);
#endif
acpi_processor_get_throttling_info(pr);
acpi_processor_get_limit_info(pr);
-
- if (cpuidle_get_driver() == &acpi_idle_driver)
- acpi_processor_power_init(pr, device);
+ xen_acpi_processor_power_init(pr, device);
pr->cdev = thermal_cooling_device_register("Processor", device,
&processor_cooling_ops);
@@ -400,48 +451,8 @@ static int __cpuinit xen_acpi_processor_add(struct
acpi_device *device)
if (!pr)
return -EINVAL;
- if (pr->id == -1) {
- int device_declaration;
- int apic_id = -1;
-
- if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
- device_declaration = 0;
- else
- device_declaration = 1;
-
- apic_id = acpi_get_cpuid(pr->handle,
- device_declaration, pr->acpi_id);
- if (apic_id == -1) {
- /* Processor is not present in MADT table */
- return 0;
- }
-
- /*
- * It''s possible to have pr->id as ''-1'' even
when it''s actually
- * present in MADT table, e.g. due to limiting dom0 max vcpus
- * less than physical present number. In such case we still want
- * to parse ACPI processor object information, so mimic the
- * pr->id to CPU-0. This should be safe because we only care
- * about raw ACPI information, which only relies on pr->acpi_id.
- * For other information relying on pr->id and gathered through
- * SMP function call, it''s safe to let them run on CPU-0 since
- * underlying Xen will collect them. Only a valid pr->id can
- * make later invocations forward progress.
- */
- pr->id = 0;
- }
-
- if (likely(!pr->flags.power_setup_done)) {
- /* reset idle boot option which we don''t care */
- boot_option_idle_override = IDLE_NO_OVERRIDE;
- acpi_processor_power_init(pr, device);
- /* set to IDLE_HALT for trapping into Xen */
- boot_option_idle_override = IDLE_HALT;
-
- if (pr->flags.power)
- processor_cntl_xen_notify(pr,
- PROCESSOR_PM_INIT, PM_TYPE_IDLE);
- }
+ if (pr->id == -1)
+ return 0;
#ifdef CONFIG_CPU_FREQ
if (likely(!pr->performance))
--
1.6.5.6
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Liu, Jinsong
2011-Dec-23 10:30 UTC
[PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
From ca403566e922dde51e8809d7489337be4a55adfc Mon Sep 17 00:00:00 2001
From: Liu Jinsong <jinsong.liu@intel.com>
Date: Wed, 14 Dec 2011 15:59:02 +0800
Subject: [PATCH 09/10] xen/acpi: Change Cx notify and add PPC handle
This patch update Xen Cx notify.
Current Cx notify has 2 potential trigger points w/ some logically redundant.
We remove the Cx notify point which is outside __xen_acpi_processor_add,
merging its logic to the Cx notify point inside __xen_acpi_processor_add.
This would more clean, as what native Cx did.
This patch also add Xen PPC handle when cpu hotadd.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
---
drivers/acpi/processor_xen.c | 103 +++++++++++++++++++++++-------------------
1 files changed, 57 insertions(+), 46 deletions(-)
diff --git a/drivers/acpi/processor_xen.c b/drivers/acpi/processor_xen.c
index 3af1f73..083e2b1 100644
--- a/drivers/acpi/processor_xen.c
+++ b/drivers/acpi/processor_xen.c
@@ -283,6 +283,59 @@ static int xen_acpi_processor_get_info(struct acpi_device
*device)
return 0;
}
+static int xen_acpi_processor_get_platform_limit(struct acpi_processor *pr)
+{
+ acpi_status status = 0;
+ unsigned long long ppc = 0;
+
+ if (!pr)
+ return -EINVAL;
+
+ /*
+ * _PPC indicates the maximum state currently supported by the platform
+ * (e.g. 0 = states 0..n; 1 = states 1..n; etc.
+ */
+ status = acpi_evaluate_integer(pr->handle, "_PPC", NULL,
&ppc);
+
+ if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
+ ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PPC"));
+ return -ENODEV;
+ }
+
+ pr->performance_platform_limit = (int)ppc;
+
+ return 0;
+}
+
+static int xen_acpi_processor_ppc_has_changed(struct acpi_processor *pr)
+{
+ int ret;
+
+ ret = xen_acpi_processor_get_platform_limit(pr);
+
+ if (ret < 0)
+ return ret;
+ else
+ return processor_cntl_xen_notify(pr,
+ PROCESSOR_PM_CHANGE, PM_TYPE_PERF);
+}
+
+static void __cpuinit xen_acpi_processor_power_init(struct acpi_processor *pr,
+ struct acpi_device *device)
+{
+ if (likely(!pr->flags.power_setup_done)) {
+ /* reset idle boot option which we don''t care */
+ boot_option_idle_override = IDLE_NO_OVERRIDE;
+ acpi_processor_power_init(pr, device);
+ /* set to IDLE_HALT for trapping into Xen */
+ boot_option_idle_override = IDLE_HALT;
+
+ if (pr->flags.power)
+ processor_cntl_xen_notify(pr,
+ PROCESSOR_PM_INIT, PM_TYPE_IDLE);
+ }
+}
+
static int __cpuinit __xen_acpi_processor_add(struct acpi_device *device)
{
struct acpi_processor *pr = NULL;
@@ -339,14 +392,12 @@ static int __cpuinit __xen_acpi_processor_add(struct
acpi_device *device)
}
#ifdef CONFIG_CPU_FREQ
- acpi_processor_ppc_has_changed(pr, 0);
+ xen_acpi_processor_ppc_has_changed(pr);
#endif
acpi_processor_get_throttling_info(pr);
acpi_processor_get_limit_info(pr);
-
- if (cpuidle_get_driver() == &acpi_idle_driver)
- acpi_processor_power_init(pr, device);
+ xen_acpi_processor_power_init(pr, device);
pr->cdev = thermal_cooling_device_register("Processor", device,
&processor_cooling_ops);
@@ -400,48 +451,8 @@ static int __cpuinit xen_acpi_processor_add(struct
acpi_device *device)
if (!pr)
return -EINVAL;
- if (pr->id == -1) {
- int device_declaration;
- int apic_id = -1;
-
- if (!strcmp(acpi_device_hid(device), ACPI_PROCESSOR_OBJECT_HID))
- device_declaration = 0;
- else
- device_declaration = 1;
-
- apic_id = acpi_get_cpuid(pr->handle,
- device_declaration, pr->acpi_id);
- if (apic_id == -1) {
- /* Processor is not present in MADT table */
- return 0;
- }
-
- /*
- * It''s possible to have pr->id as ''-1'' even
when it''s actually
- * present in MADT table, e.g. due to limiting dom0 max vcpus
- * less than physical present number. In such case we still want
- * to parse ACPI processor object information, so mimic the
- * pr->id to CPU-0. This should be safe because we only care
- * about raw ACPI information, which only relies on pr->acpi_id.
- * For other information relying on pr->id and gathered through
- * SMP function call, it''s safe to let them run on CPU-0 since
- * underlying Xen will collect them. Only a valid pr->id can
- * make later invocations forward progress.
- */
- pr->id = 0;
- }
-
- if (likely(!pr->flags.power_setup_done)) {
- /* reset idle boot option which we don''t care */
- boot_option_idle_override = IDLE_NO_OVERRIDE;
- acpi_processor_power_init(pr, device);
- /* set to IDLE_HALT for trapping into Xen */
- boot_option_idle_override = IDLE_HALT;
-
- if (pr->flags.power)
- processor_cntl_xen_notify(pr,
- PROCESSOR_PM_INIT, PM_TYPE_IDLE);
- }
+ if (pr->id == -1)
+ return 0;
#ifdef CONFIG_CPU_FREQ
if (likely(!pr->performance))
--
1.6.5.6