[PATCH] U300 sched_clock implementation

[Linus Walleij]

This patch was submitted to the ARM Linux maillist, but we need
some scheduler person to have a look at this sched_clock() thing.

The U300 timekeeping code is in the -next tree at:
arch/arm/mach-u300/time.c

The OMAP2 solution is in:
arch/arm/plat-omap/common.c

When I look at it I get the feeling, that if this works at all times, then
anything that has a continous clock source should actually
implement it this way if they have nothing else so schedule with.
I wonder how hard that would be to do in a generic way.


PATCH FOLLOWS
This overrides the global sched_clock() symbol in the Linux
scheduler with a local implementation which takes advantage of
the timesource in U300 giving a scheduling resolution of 1us. The
solution is the same as found in the OMAP2 core code.

Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxxxxxx>
---
 arch/arm/mach-u300/timer.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index 4bf82f8..222de18 100644
--- a/arch/arm/mach-u300/timer.c
+++ b/arch/arm/mach-u300/timer.c
@@ -346,6 +346,22 @@ static struct clocksource clocksource_u300_1mhz = {
       .flags          = CLOCK_SOURCE_IS_CONTINUOUS,
 };

+/*
+ * Override the global weak sched_clock symbol with this
+ * local implementation which uses the clocksource to get some
+ * better resolution when scheduling the kernel. We accept that
+ * this wraps around for now, since it is just a relative time
+ * stamp. (Inspired by OMAP implementation.)
+ */
+unsigned long long sched_clock(void)
+{
+       unsigned long long ret;
+
+       ret = (unsigned long long) u300_get_cycles();
+       ret = (ret * clocksource_u300_1mhz.mult_orig) >>
+               clocksource_u300_1mhz.shift;
+       return ret;
+}

 /*
 * This sets up the system timers, clock source and clock event.
--
1.6.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/