WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [PATCH][2/2] pvops-dom0: Resolve the xen acpi processor depe

To: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@xxxxxxxxxx>
Subject: [Xen-devel] [PATCH][2/2] pvops-dom0: Resolve the xen acpi processor dependency
From: "Yu, Ke" <ke.yu@xxxxxxxxx>
Date: Wed, 25 Nov 2009 19:56:59 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "'xen-devel@xxxxxxxxxxxxxxxxxxx'" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 25 Nov 2009 03:58:05 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcptxmSqmyJ+VdN1TnuXcqItP+xEhQ==
Thread-topic: [PATCH][2/2] pvops-dom0: Resolve the xen acpi processor dependency
Resolve the dependencey between acpi processor 
driver(driver/acpi/processor_core.c) and xen acpi processor 
driver(driver/xen/acpi_processor.c), so that the compile can pass when 
CONFIG_ACPI_PROCESSOR=m

From: Yu Ke <ke.yu@xxxxxxxxx>

Signed-off-by: Yu Ke <ke.yu@xxxxxxxxx>
---

 drivers/acpi/processor_core.c    |    2 -
 drivers/acpi/processor_perflib.c |  110 ++++++++++++++++++++++++++++++++-
 drivers/xen/acpi_processor.c     |  127 ++------------------------------------
 include/acpi/processor.h         |   10 ++-
 include/xen/acpi.h               |    5 -
 5 files changed, 123 insertions(+), 131 deletions(-)


diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 6a35118..b75098d 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -1394,7 +1394,7 @@ static int __cpuinit xen_acpi_processor_start(struct 
acpi_device *device)
 
        xen_acpi_processor_power_init(pr, device);
 
-       result = processor_cntl_xen_prepare(pr);
+       result = xen_acpi_processor_get_performance(pr);
        if (result)
                goto end;
 
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index f17e740..84db5c8 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -347,7 +347,7 @@ static int acpi_processor_get_performance_states(struct 
acpi_processor *pr)
        return result;
 }
 
-int acpi_processor_get_performance_info(struct acpi_processor *pr)
+static int acpi_processor_get_performance_info(struct acpi_processor *pr)
 {
        int result = 0;
        acpi_status status = AE_OK;
@@ -449,7 +449,7 @@ int acpi_processor_notify_smm(struct module *calling_module)
 
 EXPORT_SYMBOL(acpi_processor_notify_smm);
 
-int acpi_processor_get_psd(struct acpi_processor       *pr)
+static int acpi_processor_get_psd(struct acpi_processor        *pr)
 {
        int result = 0;
        acpi_status status = AE_OK;
@@ -730,3 +730,109 @@ acpi_processor_unregister_performance(struct 
acpi_processor_performance
 }
 
 EXPORT_SYMBOL(acpi_processor_unregister_performance);
+
+/* Xen specific interface */
+
+static int xen_processor_notify_smm(void)
+{
+       acpi_status status;
+       static int is_done;
+
+       /* only need successfully notify BIOS once */
+       /* avoid double notification which may lead to unexpected result */
+       if (is_done)
+               return 0;
+
+       /* Can't write pstate_cnt to smi_cmd if either value is zero */
+       if ((!acpi_gbl_FADT.smi_command) || (!acpi_gbl_FADT.pstate_control)) {
+               ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No SMI port or pstate_cnt\n"));
+               return 0;
+       }
+
+       ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+               "Writing pstate_cnt [0x%x] to smi_cmd [0x%x]\n",
+               acpi_gbl_FADT.pstate_control, acpi_gbl_FADT.smi_command));
+
+       status = acpi_os_write_port(acpi_gbl_FADT.smi_command,
+                                   (u32) acpi_gbl_FADT.pstate_control, 8);
+       if (ACPI_FAILURE(status))
+               return status;
+
+       is_done = 1;
+
+       return 0;
+}
+
+/*
+ * Existing ACPI module does parse performance states at some point,
+ * when acpi-cpufreq driver is loaded which however is something
+ * we'd like to disable to avoid confliction with xen PM
+ * logic. So we have to collect raw performance information here
+ * when ACPI processor object is found and started.
+ */
+int xen_acpi_processor_get_performance(struct acpi_processor *pr)
+{
+       int ret;
+       struct acpi_processor_performance *perf;
+       struct acpi_psd_package *pdomain;
+
+       if (pr->performance)
+               return -EBUSY;
+
+       perf = kzalloc(sizeof(struct acpi_processor_performance), GFP_KERNEL);
+       if (!perf)
+               return -ENOMEM;
+
+       pr->performance = perf;
+       /* Get basic performance state information */
+       ret = acpi_processor_get_performance_info(pr);
+       if (ret < 0)
+               goto err_out;
+
+       /*
+        * Well, here we need retrieve performance dependency information
+        * from _PSD object. The reason why existing interface is not used
+        * is due to the reason that existing interface sticks to Linux cpu
+        * id to construct some bitmap, however we want to split ACPI
+        * processor objects from Linux cpu id logic. For example, even
+        * when Linux is configured as UP, we still want to parse all ACPI
+        * processor objects to xen. In this case, it's preferred
+        * to use ACPI ID instead.
+        */
+       pdomain = &pr->performance->domain_info;
+       pdomain->num_processors = 0;
+       ret = acpi_processor_get_psd(pr);
+       if (ret < 0) {
+               /*
+                * _PSD is optional - assume no coordination if absent (or
+                * broken), matching native kernels' behavior.
+                */
+               pdomain->num_entries = ACPI_PSD_REV0_ENTRIES;
+               pdomain->revision = ACPI_PSD_REV0_REVISION;
+               pdomain->domain = pr->acpi_id;
+               pdomain->coord_type = DOMAIN_COORD_TYPE_SW_ALL;
+               pdomain->num_processors = 1;
+       }
+
+       /* Some sanity check */
+       if ((pdomain->revision != ACPI_PSD_REV0_REVISION) ||
+           (pdomain->num_entries != ACPI_PSD_REV0_ENTRIES) ||
+           ((pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ALL) &&
+            (pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ANY) &&
+            (pdomain->coord_type != DOMAIN_COORD_TYPE_HW_ALL))) {
+               ret = -EINVAL;
+               goto err_out;
+       }
+
+       /* Last step is to notify BIOS that xen exists */
+       xen_processor_notify_smm();
+
+       processor_cntl_xen_notify(pr, PROCESSOR_PM_INIT, PM_TYPE_PERF);
+
+       return 0;
+err_out:
+       pr->performance = NULL;
+       kfree(perf);
+       return ret;
+}
+EXPORT_SYMBOL(xen_acpi_processor_get_performance);
diff --git a/drivers/xen/acpi_processor.c b/drivers/xen/acpi_processor.c
index 6a4e8e4..7348949 100644
--- a/drivers/xen/acpi_processor.c
+++ b/drivers/xen/acpi_processor.c
@@ -36,7 +36,6 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
 
-static int processor_cntl_xen_get_performance(struct acpi_processor *pr);
 static int xen_hotplug_notifier(struct acpi_processor *pr, int event);
 
 static struct processor_cntl_xen_ops xen_ops = {
@@ -68,56 +67,31 @@ int processor_cntl_xen_power_cache(int cpu, int cx,
 
        return 0;
 }
+EXPORT_SYMBOL(processor_cntl_xen_power_cache);
 
 int processor_cntl_xen(void)
 {
        return 1;
 }
+EXPORT_SYMBOL(processor_cntl_xen);
 
 int processor_cntl_xen_pm(void)
 {
        return (xen_ops.pm_ops[PM_TYPE_IDLE] != NULL);
 }
+EXPORT_SYMBOL(processor_cntl_xen_pm);
 
 int processor_cntl_xen_pmperf(void)
 {
        return  (xen_ops.pm_ops[PM_TYPE_PERF] != NULL);
 }
+EXPORT_SYMBOL(processor_cntl_xen_pmperf);
 
 int processor_cntl_xen_pmthr(void)
 {
        return (xen_ops.pm_ops[PM_TYPE_THR] != NULL);
 }
-
-static int processor_notify_smm(void)
-{
-       acpi_status status;
-       static int is_done;
-
-       /* only need successfully notify BIOS once */
-       /* avoid double notification which may lead to unexpected result */
-       if (is_done)
-               return 0;
-
-       /* Can't write pstate_cnt to smi_cmd if either value is zero */
-       if ((!acpi_gbl_FADT.smi_command) || (!acpi_gbl_FADT.pstate_control)) {
-               ACPI_DEBUG_PRINT((ACPI_DB_INFO, "No SMI port or pstate_cnt\n"));
-               return 0;
-       }
-
-       ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-               "Writing pstate_cnt [0x%x] to smi_cmd [0x%x]\n",
-               acpi_gbl_FADT.pstate_control, acpi_gbl_FADT.smi_command));
-
-       status = acpi_os_write_port(acpi_gbl_FADT.smi_command,
-                                   (u32) acpi_gbl_FADT.pstate_control, 8);
-       if (ACPI_FAILURE(status))
-               return status;
-
-       is_done = 1;
-
-       return 0;
-}
+EXPORT_SYMBOL(processor_cntl_xen_pmthr);
 
 int processor_cntl_xen_notify(struct acpi_processor *pr, int event, int type)
 {
@@ -143,96 +117,7 @@ int processor_cntl_xen_notify(struct acpi_processor *pr, 
int event, int type)
 
        return ret;
 }
-
-/*
- * This is called from ACPI processor init, and targeted to hold
- * some tricky housekeeping jobs to satisfy xen.
- * For example, we may put dependency parse stub here for idle
- * and performance state. Those information may be not available
- * if splitting from dom0 control logic like cpufreq driver.
- */
-int processor_cntl_xen_prepare(struct acpi_processor *pr)
-{
-
-       /* Initialize performance states */
-       if (processor_cntl_xen_pmperf())
-               processor_cntl_xen_get_performance(pr);
-
-       return 0;
-}
-
-/*
- * Existing ACPI module does parse performance states at some point,
- * when acpi-cpufreq driver is loaded which however is something
- * we'd like to disable to avoid confliction with xen PM
- * logic. So we have to collect raw performance information here
- * when ACPI processor object is found and started.
- */
-static int processor_cntl_xen_get_performance(struct acpi_processor *pr)
-{
-       int ret;
-       struct acpi_processor_performance *perf;
-       struct acpi_psd_package *pdomain;
-
-       if (pr->performance)
-               return -EBUSY;
-
-       perf = kzalloc(sizeof(struct acpi_processor_performance), GFP_KERNEL);
-       if (!perf)
-               return -ENOMEM;
-
-       pr->performance = perf;
-       /* Get basic performance state information */
-       ret = acpi_processor_get_performance_info(pr);
-       if (ret < 0)
-               goto err_out;
-
-       /*
-        * Well, here we need retrieve performance dependency information
-        * from _PSD object. The reason why existing interface is not used
-        * is due to the reason that existing interface sticks to Linux cpu
-        * id to construct some bitmap, however we want to split ACPI
-        * processor objects from Linux cpu id logic. For example, even
-        * when Linux is configured as UP, we still want to parse all ACPI
-        * processor objects to xen. In this case, it's preferred
-        * to use ACPI ID instead.
-        */
-       pdomain = &pr->performance->domain_info;
-       pdomain->num_processors = 0;
-       ret = acpi_processor_get_psd(pr);
-       if (ret < 0) {
-               /*
-                * _PSD is optional - assume no coordination if absent (or
-                * broken), matching native kernels' behavior.
-                */
-               pdomain->num_entries = ACPI_PSD_REV0_ENTRIES;
-               pdomain->revision = ACPI_PSD_REV0_REVISION;
-               pdomain->domain = pr->acpi_id;
-               pdomain->coord_type = DOMAIN_COORD_TYPE_SW_ALL;
-               pdomain->num_processors = 1;
-       }
-
-       /* Some sanity check */
-       if ((pdomain->revision != ACPI_PSD_REV0_REVISION) ||
-           (pdomain->num_entries != ACPI_PSD_REV0_ENTRIES) ||
-           ((pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ALL) &&
-            (pdomain->coord_type != DOMAIN_COORD_TYPE_SW_ANY) &&
-            (pdomain->coord_type != DOMAIN_COORD_TYPE_HW_ALL))) {
-               ret = -EINVAL;
-               goto err_out;
-       }
-
-       /* Last step is to notify BIOS that xen exists */
-       processor_notify_smm();
-
-       processor_cntl_xen_notify(pr, PROCESSOR_PM_INIT, PM_TYPE_PERF);
-
-       return 0;
-err_out:
-       pr->performance = NULL;
-       kfree(perf);
-       return ret;
-}
+EXPORT_SYMBOL(processor_cntl_xen_notify);
 
 static inline void xen_convert_pct_reg(struct xen_pct_register *xpct,
        struct acpi_pct_register *apct)
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index c806ecf..a92b946 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -296,9 +296,8 @@ static inline void acpi_processor_ffh_cstate_enter(struct 
acpi_processor_cx
 void acpi_processor_ppc_init(void);
 void acpi_processor_ppc_exit(void);
 int acpi_processor_ppc_has_changed(struct acpi_processor *pr);
-int acpi_processor_get_performance_info(struct acpi_processor *pr);
-int acpi_processor_get_psd(struct acpi_processor *pr);
 int xen_acpi_processor_ppc_has_changed(struct acpi_processor *pr);
+int xen_acpi_processor_get_performance(struct acpi_processor *pr);
 #else
 static inline void acpi_processor_ppc_init(void)
 {
@@ -324,6 +323,13 @@ static inline int 
xen_acpi_processor_ppc_has_changed(struct acpi_processor *pr)
 {
        return acpi_processor_ppc_has_changed(pr);
 }
+static inline int xen_acpi_processor_get_performance(struct acpi_processor *pr)
+{
+       printk(KERN_WARNING
+                       "Warning: xen_acpi_processor_get_performance not 
supported\n"
+                       "Consider compiling CPUfreq support into your 
kernel.\n");
+       return 0;
+}
 #endif                         /* CONFIG_CPU_FREQ */
 
 /* in processor_throttling.c */
diff --git a/include/xen/acpi.h b/include/xen/acpi.h
index 3d73163..3d7ea40 100644
--- a/include/xen/acpi.h
+++ b/include/xen/acpi.h
@@ -54,7 +54,6 @@ extern int processor_cntl_xen(void);
 extern int processor_cntl_xen_pm(void);
 extern int processor_cntl_xen_pmperf(void);
 extern int processor_cntl_xen_pmthr(void);
-extern int processor_cntl_xen_prepare(struct acpi_processor *pr);
 extern int processor_cntl_xen_notify(struct acpi_processor *pr,
                        int event, int type);
 extern int processor_cntl_xen_power_cache(int cpu, int cx,
@@ -70,10 +69,6 @@ static inline int processor_cntl_xen_notify(struct 
acpi_processor *pr,
 {
        return 0;
 }
-static inline int processor_cntl_xen_prepare(struct acpi_processor *pr)
-{
-       return 0;
-}
 static inline int processor_cntl_xen_power_cache(int cpu, int cx,
                struct acpi_power_register *reg)
 {

Best Regards
Ke


Attachment: resolve-dependency.patch
Description: resolve-dependency.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH][2/2] pvops-dom0: Resolve the xen acpi processor dependency, Yu, Ke <=