From: Parag Warudkar <kernel-stuff@comcast.net>
To: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: john stultz <johnstul@us.ibm.com>,
Nishanth Aravamudan <nacc@us.ibm.com>, Andi Kleen <ak@suse.de>,
lkml <linux-kernel@vger.kernel.org>,
Tim Schmielau <tim@physik3.uni-rostock.de>,
George Anzinger <george@mvista.com>,
albert@users.sourceforge.net,
Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>,
Christoph Lameter <clameter@sgi.com>,
David Mosberger <davidm@hpl.hp.com>,
Andrew Morton <akpm@osdl.org>,
paulus@samba.org, schwidefsky@de.ibm.com,
keith maanthey <kmannth@us.ibm.com>,
Chris McDermott <lcm@us.ibm.com>, Max Asbock <masbock@us.ibm.com>,
mahuja@us.ibm.com, Darren Hart <darren@dvhart.com>,
"Darrick J. Wong" <djwong@us.ibm.com>,
Anton Blanchard <anton@samba.org>,
donf@us.ibm.com, mpm@selenic.com, benh@kernel.crashing.org
Subject: Re: [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1)
Date: Sun, 5 Jun 2005 23:04:34 -0400 [thread overview]
Message-ID: <200506052304.35298.kernel-stuff@comcast.net> (raw)
In-Reply-To: <20050605170511.GC12338@dominikbrodowski.de>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On Sunday 05 June 2005 13:05, Dominik Brodowski wrote:
> IIRC (from the comment above) several chipsets suffer from this
> inconsistency, namely the widely used PIIX4(E) and ICH(4 only? or also
> other ICH-ones?). Therefore, we'd need at least some sort of boot-time
> check to decide which method to use... and based on the method, we can
> adjust the priority maybe?
To begin with, will the simple proof-of-concept patch like below work? (It
tests the chipset read in the same do{}while loop - if the loop executes only
once, it considers the chipset good - in which case it executes the faster
read_pmtmr_fast function.) Or does it need wider testing under different
circumstances to conclude that chipset is good?
I tested the patch under Virtual PC which emulates a PIIX4 chipset. Test
passes there, meaning the do {}while loop executes only once.
Parag
[-- Attachment #2: timer_pm.c.patch --]
[-- Type: text/x-diff, Size: 3564 bytes --]
--- linux-2.6-orig/arch/i386/kernel/timers/timer_pm.c 2005-03-02 02:37:48.000000000 -0500
+++ linux-2.6.12-rc5/arch/i386/kernel/timers/timer_pm.c 2005-06-05 23:01:15.000000000 -0400
@@ -35,6 +35,10 @@
* in arch/i386/acpi/boot.c */
u32 pmtmr_ioport = 0;
+struct pmtmr_rd_func {
+ u32 (*read_pmtmr) (void);
+}pmtmr_rd_func;
+
/* value of the Power timer at last timer interrupt */
static u32 offset_tick;
@@ -45,6 +49,11 @@
#define ACPI_PM_MASK 0xFFFFFF /* limit it to 24 bits */
+static inline u32 read_pmtmr_fast(void)
+{
+ return inl(pmtmr_ioport);
+}
+
/*helper function to safely read acpi pm timesource*/
static inline u32 read_pmtmr(void)
{
@@ -76,14 +85,14 @@
unsigned long count, delta;
mach_prepare_counter();
- value1 = read_pmtmr();
+ value1 = pmtmr_rd_func.read_pmtmr();
mach_countup(&count);
- value2 = read_pmtmr();
+ value2 = pmtmr_rd_func.read_pmtmr();
delta = (value2 - value1) & ACPI_PM_MASK;
/* Check that the PMTMR delta is within 5% of what we expect */
- if (delta < (PMTMR_EXPECTED_RATE * 19) / 20 ||
- delta > (PMTMR_EXPECTED_RATE * 21) / 20) {
+ if (delta < (PMTMR_EXPECTED_RATE * 18) / 20 ||
+ delta > (PMTMR_EXPECTED_RATE * 22) / 20) {
printk(KERN_INFO "PM-Timer running at invalid rate: %lu%% of normal - aborting.\n", 100UL * delta / PMTMR_EXPECTED_RATE);
return -1;
}
@@ -95,9 +104,16 @@
static int init_pmtmr(char* override)
{
u32 value1, value2;
- unsigned int i;
+ u32 v1=0,v2=0,v3=0;
+ unsigned int i, loop_cnt=0;
- if (override[0] && strncmp(override,"pmtmr",5))
+ /* Use slower but probably more correct read function by
+ * default. This is overriden with a fast one if it is
+ * suitable to do so below.
+ */
+ pmtmr_rd_func.read_pmtmr = read_pmtmr;
+
+ if (override[0] && strncmp(override,"pmtmr",5))
return -ENODEV;
if (!pmtmr_ioport)
@@ -106,9 +122,32 @@
/* we use the TSC for delay_pmtmr, so make sure it exists */
if (!cpu_has_tsc)
return -ENODEV;
+ /* It has been reported that because of various broken
+ * chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
+ * source is not latched, so you must read it multiple
+ * times to insure a safe value is read.
+ */
+ do {
+ v1 = inl(pmtmr_ioport);
+ v2 = inl(pmtmr_ioport);
+ v3 = inl(pmtmr_ioport);
+ loop_cnt++;
+ } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
+ || (v3 > v1 && v3 < v2));
+
+ if(loop_cnt == 1) {
+ /*We have a good chipset*/
+ printk(KERN_INFO "PM Timer: Chipset passes port read test\n");
+ pmtmr_rd_func.read_pmtmr = read_pmtmr_fast;
+ }
+
+ else {
+ printk(KERN_INFO "PM Timer: Chipset fails port read test:");
+ printk(KERN_INFO "Working around it.");
+ }
/* "verify" this timing source */
- value1 = read_pmtmr();
+ value1 = pmtmr_rd_func.read_pmtmr();
for (i = 0; i < 10000; i++) {
value2 = read_pmtmr();
if (value2 == value1)
@@ -156,7 +195,7 @@
write_seqlock(&monotonic_lock);
- offset_tick = read_pmtmr();
+ offset_tick = pmtmr_rd_func.read_pmtmr();
/* calculate tick interval */
delta = (offset_tick - last_offset) & ACPI_PM_MASK;
@@ -202,7 +241,7 @@
} while (read_seqretry(&monotonic_lock, seq));
/* Read the pmtmr */
- this_offset = read_pmtmr();
+ this_offset = pmtmr_rd_func.read_pmtmr();
/* convert to nanoseconds */
ret = (this_offset - last_offset) & ACPI_PM_MASK;
@@ -232,7 +271,7 @@
u32 now, offset, delta = 0;
offset = offset_tick;
- now = read_pmtmr();
+ now = pmtmr_rd_func.read_pmtmr();
delta = (now - offset)&ACPI_PM_MASK;
return (unsigned long) offset_delay + cyc2us(delta);
next prev parent reply other threads:[~2005-06-06 3:09 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-02 18:27 [PATCH 3/4] new timeofday x86-64 arch specific changes (v. B1) Parag Warudkar
2005-06-02 18:39 ` Nishanth Aravamudan
2005-06-02 23:05 ` Parag Warudkar
2005-06-02 23:20 ` john stultz
2005-06-02 23:33 ` Parag Warudkar
2005-06-02 23:50 ` Parag Warudkar
2005-06-03 7:05 ` Ulrich Windl
2005-06-03 15:24 ` john stultz
2005-06-05 17:05 ` Dominik Brodowski
2005-06-06 3:04 ` Parag Warudkar [this message]
2005-06-06 3:14 ` Dominik Brodowski
2005-06-10 0:48 ` George Anzinger
2005-06-06 9:21 ` Andi Kleen
2005-06-06 9:24 ` Dominik Brodowski
2005-06-06 9:30 ` Andi Kleen
2005-06-06 13:32 ` Vojtech Pavlik
2005-06-06 22:53 ` john stultz
2005-06-03 16:30 ` Andi Kleen
2005-06-03 18:27 ` john stultz
2005-06-03 19:02 ` Christoph Lameter
2005-06-03 19:21 ` john stultz
2005-06-05 11:27 ` Andi Kleen
2005-06-06 22:51 ` john stultz
2005-06-04 18:40 ` Parag Warudkar
2005-06-05 11:28 ` Andi Kleen
2005-06-05 14:15 ` Parag Warudkar
2005-06-05 20:51 ` Lee Revell
2005-06-05 21:41 ` Parag Warudkar
2005-06-05 22:13 ` Lee Revell
2005-06-06 9:29 ` Andi Kleen
2005-06-06 11:46 ` Parag Warudkar
2005-06-08 13:51 ` Andi Kleen
2005-06-09 1:47 ` Lee Revell
2005-06-09 2:12 ` john stultz
2005-06-09 2:42 ` Parag Warudkar
2005-06-09 14:17 ` Andi Kleen
2005-06-03 13:32 ` Parag Warudkar
2005-06-02 18:40 ` john stultz
-- strict thread matches above, loose matches on Subject: below --
2005-06-02 18:51 Parag Warudkar
2005-06-01 23:09 [PATCH 1/4] new timeofday core subsystem " john stultz
2005-06-01 23:12 ` [PATCH 2/4] new timeofday i386 arch specific changes " john stultz
2005-06-01 23:13 ` [PATCH 3/4] new timeofday x86-64 " john stultz
2005-06-02 0:37 ` Parag Warudkar
2005-06-02 17:34 ` john stultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200506052304.35298.kernel-stuff@comcast.net \
--to=kernel-stuff@comcast.net \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=albert@users.sourceforge.net \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=clameter@sgi.com \
--cc=darren@dvhart.com \
--cc=davidm@hpl.hp.com \
--cc=djwong@us.ibm.com \
--cc=donf@us.ibm.com \
--cc=george@mvista.com \
--cc=johnstul@us.ibm.com \
--cc=kmannth@us.ibm.com \
--cc=lcm@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=mahuja@us.ibm.com \
--cc=masbock@us.ibm.com \
--cc=mpm@selenic.com \
--cc=nacc@us.ibm.com \
--cc=paulus@samba.org \
--cc=schwidefsky@de.ibm.com \
--cc=tim@physik3.uni-rostock.de \
--cc=ulrich.windl@rz.uni-regensburg.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox