From: Richard Henderson <rth@twiddle.net>
To: linux-kernel@vger.kernel.org
Cc: ink@jurassic.park.msu.ru, mattst88@gmail.com,
linux-alpha@vger.kernel.org
Subject: [RFC PATCH 08/10] alpha: Always enable the rpcc clocksource for single processor
Date: Tue, 16 Jul 2013 10:34:16 -0700 [thread overview]
Message-ID: <1373996058-13399-9-git-send-email-rth@twiddle.net> (raw)
In-Reply-To: <1373996058-13399-1-git-send-email-rth@twiddle.net>
Don't depend on SMP, just check the number of processors online.
This allows a single distribution kernel to use the clocksource
when run on a single processor machine.
Signed-off-by: Richard Henderson <rth@twiddle.net>
---
arch/alpha/kernel/time.c | 58 +++++++++++++++++++++++-------------------------
1 file changed, 28 insertions(+), 30 deletions(-)
diff --git a/arch/alpha/kernel/time.c b/arch/alpha/kernel/time.c
index dbd56ec..cadb82b 100644
--- a/arch/alpha/kernel/time.c
+++ b/arch/alpha/kernel/time.c
@@ -186,6 +186,31 @@ common_init_rtc(void)
init_rtc_irq();
}
+\f
+/*
+ * The RPCC as a clocksource primitive.
+ *
+ * While we have free-running timecounters running on all CPUs, and we make
+ * a half-hearted attempt in init_rtc_rpcc_info to sync the timecounter
+ * with the wall clock, that initialization isn't kept up-to-date across
+ * different time counters in SMP mode. Therefore we can only use this
+ * method when there's only one CPU enabled.
+ */
+
+static cycle_t read_rpcc(struct clocksource *cs)
+{
+ return rpcc();
+}
+
+static struct clocksource clocksource_rpcc = {
+ .name = "rpcc",
+ .rating = 300,
+ .read = read_rpcc,
+ .mask = CLOCKSOURCE_MASK(32),
+ .flags = CLOCK_SOURCE_IS_CONTINUOUS
+};
+
+\f
/* Validate a computed cycle counter result against the known bounds for
the given processor core. There's too much brokenness in the way of
timing hardware for any one method to work everywhere. :-(
@@ -296,33 +321,6 @@ rpcc_after_update_in_progress(void)
return rpcc();
}
-#ifndef CONFIG_SMP
-/* Until and unless we figure out how to get cpu cycle counters
- in sync and keep them there, we can't use the rpcc. */
-static cycle_t read_rpcc(struct clocksource *cs)
-{
- cycle_t ret = (cycle_t)rpcc();
- return ret;
-}
-
-static struct clocksource clocksource_rpcc = {
- .name = "rpcc",
- .rating = 300,
- .read = read_rpcc,
- .mask = CLOCKSOURCE_MASK(32),
- .flags = CLOCK_SOURCE_IS_CONTINUOUS
-};
-
-static inline void register_rpcc_clocksource(long cycle_freq)
-{
- clocksource_register_hz(&clocksource_rpcc, cycle_freq);
-}
-#else /* !CONFIG_SMP */
-static inline void register_rpcc_clocksource(long cycle_freq)
-{
-}
-#endif /* !CONFIG_SMP */
-
void __init
time_init(void)
{
@@ -364,20 +362,20 @@ time_init(void)
"and unable to estimate a proper value!\n");
}
+ if (hwrpb->nr_processors == 1)
+ clocksource_register_hz(&clocksource_rpcc, cycle_freq);
+
/* From John Bowman <bowman@math.ualberta.ca>: allow the values
to settle, as the Update-In-Progress bit going low isn't good
enough on some hardware. 2ms is our guess; we haven't found
bogomips yet, but this is close on a 500Mhz box. */
__delay(1000000);
-
if (HZ > (1<<16)) {
extern void __you_loose (void);
__you_loose();
}
- register_rpcc_clocksource(cycle_freq);
-
state.last_time = cc1;
state.scaled_ticks_per_cycle
= ((unsigned long) HZ << FIX_SHIFT) / cycle_freq;
--
1.8.1.4
next prev parent reply other threads:[~2013-07-16 17:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-16 17:34 [RFC PATCH 00/10] Alpha support for QEMU Richard Henderson
2013-07-16 17:34 ` [RFC PATCH 01/10] alpha: Don't if-out dp264_device_interrupt Richard Henderson
2013-07-16 17:34 ` [RFC PATCH 02/10] alpha: Notice if we're being run under QEMU Richard Henderson
2013-07-16 17:34 ` [RFC PATCH 03/10] alpha: Force the user-visible HZ to a constant 1024 Richard Henderson
2013-07-16 17:34 ` [RFC PATCH 04/10] alpha: Allow HZ to be configured Richard Henderson
2013-07-16 17:34 ` [RFC PATCH 05/10] alpha: Primitive support for CPU power down Richard Henderson
2013-07-17 5:17 ` Matt Turner
2013-07-17 13:16 ` Richard Henderson
2013-07-16 17:34 ` [RFC PATCH 06/10] alpha: Reorganize rtc handling Richard Henderson
2013-07-16 17:34 ` [RFC PATCH 07/10] alpha: Add an rtc driver for the qemu wallclock PALcall Richard Henderson
2013-07-16 17:34 ` Richard Henderson [this message]
2013-07-16 17:34 ` [RFC PATCH 09/10] alpha: Switch to GENERIC_CLOCKEVENTS Richard Henderson
2013-07-16 17:34 ` [RFC PATCH 10/10] alpha: Use qemu+cserve provided high-res clock and alarm Richard Henderson
2013-07-18 1:14 ` [RFC PATCH 00/10] Alpha support for QEMU Michael Cree
2013-07-18 13:38 ` Richard Henderson
2013-07-18 21:28 ` Michael Cree
2013-07-18 22:04 ` Richard Henderson
2013-07-19 10:03 ` Michael Cree
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=1373996058-13399-9-git-send-email-rth@twiddle.net \
--to=rth@twiddle.net \
--cc=ink@jurassic.park.msu.ru \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mattst88@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.