From: John Stultz <johnstul@us.ibm.com>
To: lkml <linux-kernel@vger.kernel.org>
Cc: John Stultz <johnstul@us.ibm.com>, Thomas Gleixner <tglx@linutronix.de>
Subject: [PATCH 1/3] Add clocksource_register_hz/khz interface
Date: Fri, 30 Apr 2010 18:36:23 -0700 [thread overview]
Message-ID: <1272677785-23881-1-git-send-email-johnstul@us.ibm.com> (raw)
Hey Thomas,
It would be great to get this into 2.6.35, so I can push on getting the per-arch
clocksource conversions queued and tested for 2.6.36-37.
thanks
-john
How to pick good mult/shif pairs has always been difficult to describe
to folks writing clocksource drivers, since it requires careful tradeoffs
in adjustment accuracy vs overflow limits.
Now, with the clocks_calc_mult_shift function, its much easier. However,
not many clocksources have converted to using that function, and there is
still the issue of the max interval length assumption being made by
each clocksource driver independently.
So this patch simplifies the registration process by having clocksources
be registered with a hz/khz value and the the registration function taking
care of setting mult/shift.
This should take most of the confusion out of writing a clocksource driver.
Additionally it also keeps the shift size tradeoff (more accuracy vs longer
possible nohz times) centralized so the timekeeping core can keep track of the
assumptions being made.
CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <johnstul@us.ibm.com>
---
include/linux/clocksource.h | 5 +++
kernel/time/clocksource.c | 71 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 4bca8b6..1ef1c36 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -274,6 +274,9 @@ static inline s64 clocksource_cyc2ns(cycle_t cycles, u32 mult, u32 shift)
/* used to install a new clocksource */
+
+extern int clocksource_register_hz(struct clocksource*, u32);
+extern int clocksource_register_khz(struct clocksource*, u32);
extern int clocksource_register(struct clocksource*);
extern void clocksource_unregister(struct clocksource*);
extern void clocksource_touch_watchdog(void);
@@ -294,6 +297,8 @@ clocksource_calc_mult_shift(struct clocksource *cs, u32 freq, u32 minsec)
NSEC_PER_SEC, minsec);
}
+
+
#ifdef CONFIG_GENERIC_TIME_VSYSCALL
extern void
update_vsyscall(struct timespec *ts, struct clocksource *c, u32 mult);
diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index 1f5dde6..73b9aeb 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -625,6 +625,77 @@ static void clocksource_enqueue(struct clocksource *cs)
list_add(&cs->list, entry);
}
+
+
+
+/* Maximum time we expect to go between ticks.
+ * This is includes idle tickless time. It provides
+ * the trade off between selecting a mult/shift pair
+ * that is very precise but can only handle a short period
+ * of time, vs. a mult/shift pair that can handle long
+ * periods of time but isn't as precise.
+ *
+ * This is a subsystem constant, and actual hardware limitations
+ * may override it (ie: clocksources that wrap every 3 seconds).
+ */
+#define MAX_UPDATE_LENGTH 5 /* Seconds */
+
+
+/**
+ * clocksource_register - Used to install new clocksources
+ * @t: clocksource to be registered
+ *
+ * Returns -EBUSY if registration fails, zero otherwise.
+ */
+int clocksource_register_hz(struct clocksource *cs, u32 hz)
+{
+
+ /* Ideally we want to use some of the limits used in
+ * clocksource_max_deferment, to provide a more informed
+ * MAX_UPDATE_LENGTH. But for now this just gets the
+ * regiseter interface working properly.
+ */
+ clocks_calc_mult_shift(&cs->mult, &cs->shift, hz,
+ NSEC_PER_SEC, MAX_UPDATE_LENGTH);
+ cs->max_idle_ns = clocksource_max_deferment(cs);
+
+ mutex_lock(&clocksource_mutex);
+ clocksource_enqueue(cs);
+ clocksource_select();
+ clocksource_enqueue_watchdog(cs);
+ mutex_unlock(&clocksource_mutex);
+ return 0;
+}
+EXPORT_SYMBOL(clocksource_register_hz);
+
+/**
+ * clocksource_register - Used to install new clocksources
+ * @t: clocksource to be registered
+ *
+ * Returns -EBUSY if registration fails, zero otherwise.
+ */
+int clocksource_register_khz(struct clocksource *cs, u32 khz)
+{
+
+ /* Ideally we want to use some of the limits used in
+ * clocksource_max_deferment, to provide a more informed
+ * MAX_UPDATE_LENGTH. But for now this just gets the
+ * regiseter interface working properly.
+ */
+ clocks_calc_mult_shift(&cs->mult, &cs->shift, khz,
+ NSEC_PER_SEC/1000,
+ MAX_UPDATE_LENGTH*1000);
+ cs->max_idle_ns = clocksource_max_deferment(cs);
+
+ mutex_lock(&clocksource_mutex);
+ clocksource_enqueue(cs);
+ clocksource_select();
+ clocksource_enqueue_watchdog(cs);
+ mutex_unlock(&clocksource_mutex);
+ return 0;
+}
+EXPORT_SYMBOL(clocksource_register_hz);
+
/**
* clocksource_register - Used to install new clocksources
* @t: clocksource to be registered
--
1.6.0.4
next reply other threads:[~2010-05-01 1:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-01 1:36 John Stultz [this message]
2010-05-01 1:36 ` [PATCH 2/3] Convert common x86 clocksources to use clocksource_register_hz/khz John Stultz
2010-05-01 1:36 ` [RFC][PATCH 3/3] Try to convert non-trivial clocksources to clocksource_register_hz John Stultz
2010-05-10 15:53 ` Martin Schwidefsky
2010-05-10 19:19 ` john stultz
2010-05-11 6:20 ` Martin Schwidefsky
2010-05-10 21:33 ` Jim Cromie
2010-05-11 0:04 ` john stultz
2010-05-11 1:51 ` Jim Cromie
2010-05-11 0:37 ` john stultz
2010-05-12 16:43 ` Julien Ridoux
2010-05-01 8:45 ` [PATCH 1/3] Add clocksource_register_hz/khz interface Thomas Gleixner
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=1272677785-23881-1-git-send-email-johnstul@us.ibm.com \
--to=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.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
all inboxes | Powered by JetHome®