[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <tip-d48fc63f6f3f485ed5aa9cf019d8e8e3a7d10263@git.kernel.org>
Date: Wed, 11 Apr 2012 15:15:51 -0700
From: tip-bot for Thomas Gleixner <tglx@...utronix.de>
To: linux-tip-commits@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, arjanvandeven@...il.com,
hpa@...or.com, mingo@...nel.org, johnstul@...ibm.com,
arjan@...radead.org, mfwitten@...il.com, lenb@...nel.org,
tglx@...utronix.de
Subject: [tip:timers/urgent] Revert "clocksource:
Load the ACPI PM clocksource asynchronously"
Commit-ID: d48fc63f6f3f485ed5aa9cf019d8e8e3a7d10263
Gitweb: http://git.kernel.org/tip/d48fc63f6f3f485ed5aa9cf019d8e8e3a7d10263
Author: Thomas Gleixner <tglx@...utronix.de>
AuthorDate: Wed, 11 Apr 2012 23:49:16 +0200
Committer: Thomas Gleixner <tglx@...utronix.de>
CommitDate: Thu, 12 Apr 2012 00:05:05 +0200
Revert "clocksource: Load the ACPI PM clocksource asynchronously"
This reverts commit b519508298e0292e1771eecf14aaf67755adc39d.
The reason for this revert is that making the frequency verification
preemptible and interruptible is not working reliably. Michaels
machine failed to use PM-timer with the message:
PM-Timer running at invalid rate: 113% of normal - aborting.
That's not a surprise as the frequency verification does rely on
interrupts being disabled. With a async scheduled thread there is no
guarantee to achieve the same result. Also some driver might fiddle
with the CTC channel 2 during the verification period, which makes the
result even more random and unpredictable.
This can be solved by using the same mechanism as we use in the
deferred TSC validation code, but that only will work if we verified a
working HPET _BEFORE_ trying to do the PM-Timer lazy validation.
So for now reverting is the safe option.
Bisected-by: Michael Witten <mfwitten@...il.com>
Cc: Arjan van de Ven <arjanvandeven@...il.com>
Cc: Arjan van de Ven <arjan@...radead.org>
Cc: John Stultz <johnstul@...ibm.com>
Cc: Len Brown <lenb@...nel.org>
LKML-Reference: <alpine.LFD.2.02.1204112303270.2542@...os>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
---
drivers/clocksource/acpi_pm.c | 24 ++++++++----------------
1 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index 82e8820..6b5cf02 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -23,7 +23,6 @@
#include <linux/init.h>
#include <linux/pci.h>
#include <linux/delay.h>
-#include <linux/async.h>
#include <asm/io.h>
/*
@@ -180,15 +179,17 @@ static int verify_pmtmr_rate(void)
/* Number of reads we try to get two different values */
#define ACPI_PM_READ_CHECKS 10000
-static void __init acpi_pm_clocksource_async(void *unused, async_cookie_t cookie)
+static int __init init_acpi_pm_clocksource(void)
{
cycle_t value1, value2;
unsigned int i, j = 0;
+ if (!pmtmr_ioport)
+ return -ENODEV;
/* "verify" this timing source: */
for (j = 0; j < ACPI_PM_MONOTONICITY_CHECKS; j++) {
- usleep_range(100 * j, 100 * j + 100);
+ udelay(100 * j);
value1 = clocksource_acpi_pm.read(&clocksource_acpi_pm);
for (i = 0; i < ACPI_PM_READ_CHECKS; i++) {
value2 = clocksource_acpi_pm.read(&clocksource_acpi_pm);
@@ -202,34 +203,25 @@ static void __init acpi_pm_clocksource_async(void *unused, async_cookie_t cookie
" 0x%#llx, 0x%#llx - aborting.\n",
value1, value2);
pmtmr_ioport = 0;
- return;
+ return -EINVAL;
}
if (i == ACPI_PM_READ_CHECKS) {
printk(KERN_INFO "PM-Timer failed consistency check "
" (0x%#llx) - aborting.\n", value1);
pmtmr_ioport = 0;
- return;
+ return -ENODEV;
}
}
if (verify_pmtmr_rate() != 0){
pmtmr_ioport = 0;
- return;
+ return -ENODEV;
}
- clocksource_register_hz(&clocksource_acpi_pm,
+ return clocksource_register_hz(&clocksource_acpi_pm,
PMTMR_TICKS_PER_SEC);
}
-static int __init init_acpi_pm_clocksource(void)
-{
- if (!pmtmr_ioport)
- return -ENODEV;
-
- async_schedule(acpi_pm_clocksource_async, NULL);
- return 0;
-}
-
/* We use fs_initcall because we want the PCI fixups to have run
* but we still need to load before device_initcall
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists