64-bit friendly generic sched_clock()

We're going to increase the cyc value to 64 bits in the near future. Doing that is going to break the custom seqcount implementation in the sched_clock code because 64 bit numbers aren't guaranteed to be atomic. Replace the cyc_copy with a seqcount to avoid this problem.

Cc Russell King <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

---
 kernel/time/sched_clock.c | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

Looks good to me. The current scheme would be very fiddly to extend to 64-bit values on 32-bit architectures without cheap atomic doubleword accesses.

Quoted 3 lines · Will Deacon

Looks good to me. The current scheme would be very fiddly to extend to 64-bit values on 32-bit architectures without cheap atomic doubleword accesses.

You should have a look at include/linux/cnt32_to_63.h. This could be applied to pure software counters if the low part is atomically increased.

In the next patch we're going to increase the number of bits that the generic sched_clock can handle to be greater than 32. With more than 32 bits the wraparound time can be larger than what can fit into the units that msecs_to_jiffies takes (unsigned int). Luckily, the wraparound is initially calculated in nanoseconds which we can easily use with hrtimers, so switch to using an hrtimer.

Cc Russell King <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Quoted 10 lines · Stephen Boyd

In the next patch we're going to increase the number of bits that the generic sched_clock can handle to be greater than 32. With more than 32 bits the wraparound time can be larger than what can fit into the units that msecs_to_jiffies takes (unsigned int). Luckily, the wraparound is initially calculated in nanoseconds which we can easily use with hrtimers, so switch to using an hrtimer.

Cc Russell King <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Hrmm. So in my testing (under qemu), this patch causes bootup to hang.

qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9 -nographic -m 1024 -append 'root=/dev/mmcblk0p2 rw mem=1024M raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22

Config file attached.

I haven't gotten a chance to look very closely, but it seems the folowing patch resolves the issue. I'm not sure if we're seeing callers to setup_sched_clock happen after sched_clock_postinit or what, but it probably needs another look over.

thanks

(quoted diff) +0 -1

-john

kernel/time/sched_clock.c +0 -6

index a269890b..c018ffc 100644
@@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void),
 int bits, unsigned long rate)
     pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns,
 wraps every %lluns\n",
         bits, r, r_unit, res, wrap);
 
-    /*
-     * Start the timer to keep sched_clock() properly updated and
-     * sets the initial epoch.
-     */
-    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
-    sched_clock_timer.function = sched_clock_poll;
     update_sched_clock();

 
     /*

kernel/time/sched_clock.c +0 -0

@@ -175,6 +169,13 @@ void __init sched_clock_postinit(void)
         setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
 
     update_sched_clock();

Quoted 52 lines · John Stultz

Quoted 10 lines · Stephen Boyd

In the next patch we're going to increase the number of bits that the generic sched_clock can handle to be greater than 32. With more than 32 bits the wraparound time can be larger than what can fit into the units that msecs_to_jiffies takes (unsigned int). Luckily, the wraparound is initially calculated in nanoseconds which we can easily use with hrtimers, so switch to using an hrtimer.

Cc Russell King <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Hrmm. So in my testing (under qemu), this patch causes bootup to hang.

qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9 -nographic -m 1024 -append 'root=/dev/mmcblk0p2 rw mem=1024M raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22

Config file attached.

I haven't gotten a chance to look very closely, but it seems the folowing patch resolves the issue. I'm not sure if we're seeing callers to setup_sched_clock happen after sched_clock_postinit or what, but it probably needs another look over.

thanks

(quoted diff) +0 -1

-john

kernel/time/sched_clock.c +0 -6

index a269890b..c018ffc 100644
@@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void),
 int bits, unsigned long rate)
     pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns,
 wraps every %lluns\n",
         bits, r, r_unit, res, wrap);
 
-    /*
-     * Start the timer to keep sched_clock() properly updated and
-     * sets the initial epoch.
-     */
-    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
-    sched_clock_timer.function = sched_clock_poll;
     update_sched_clock();

 
     /*

kernel/time/sched_clock.c +0 -0

@@ -175,6 +169,13 @@ void __init sched_clock_postinit(void)
         setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
 

kernel/time/sched_clock.c void __init sched_clock_postinit(void) · line 181

Quoted 12 lines

kernel/time/sched_clock.c +7 -0

     update_sched_clock();
+
+    /*
+     * Start the timer to keep sched_clock() properly updated and
+     * sets the initial epoch.
+     */
+    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+    sched_clock_timer.function = sched_clock_poll;
     hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
 }
 

Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into sched_clock_register() also causes the same crash.

Quoted 2 lines · Stephen Boyd

Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into sched_clock_register() also causes the same crash.

Yes that seems to be the problem. The vexpress board is setting up the sched_clock in setup_arch() (via v2m_init_early) which runs before hrtimers_init(). I've only tested this on boards that setup the timer in the time_init() callback which runs after hrtimers_init(). Your patch should be fine, although it would be nice if we didn't have callers setting up the sched_clock so early.

Quoted 52 lines · Stephen Boyd

Quoted 51 lines · John Stultz

Quoted 10 lines · Stephen Boyd

In the next patch we're going to increase the number of bits that the generic sched_clock can handle to be greater than 32. With more than 32 bits the wraparound time can be larger than what can fit into the units that msecs_to_jiffies takes (unsigned int). Luckily, the wraparound is initially calculated in nanoseconds which we can easily use with hrtimers, so switch to using an hrtimer.

Cc Russell King <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Hrmm. So in my testing (under qemu), this patch causes bootup to hang.

qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9 -nographic -m 1024 -append 'root=/dev/mmcblk0p2 rw mem=1024M raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22

Config file attached.

I haven't gotten a chance to look very closely, but it seems the folowing patch resolves the issue. I'm not sure if we're seeing callers to setup_sched_clock happen after sched_clock_postinit or what, but it probably needs another look over.

thanks

(quoted diff) +0 -1

-john

kernel/time/sched_clock.c +0 -6

index a269890b..c018ffc 100644
@@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void),
 int bits, unsigned long rate)
      pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns,
 wraps every %lluns\n",
          bits, r, r_unit, res, wrap);
 
-    /*
-     * Start the timer to keep sched_clock() properly updated and
-     * sets the initial epoch.
-     */
-    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
-    sched_clock_timer.function = sched_clock_poll;
      update_sched_clock();

  
      /*

kernel/time/sched_clock.c +0 -0

@@ -175,6 +169,13 @@ void __init sched_clock_postinit(void)
          setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
 

Quoted 14 lines

kernel/time/sched_clock.c void __init sched_clock_postinit(void) · line 181

Quoted 12 lines

kernel/time/sched_clock.c +7 -0

      update_sched_clock();
+
+    /*
+     * Start the timer to keep sched_clock() properly updated and
+     * sets the initial epoch.
+     */
+    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+    sched_clock_timer.function = sched_clock_poll;
      hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
  }
 

Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into sched_clock_register() also causes the same crash.

Yes that seems to be the problem. The vexpress board is setting up the sched_clock in setup_arch() (via v2m_init_early) which runs before hrtimers_init(). I've only tested this on boards that setup the timer in the time_init() callback which runs after hrtimers_init(). Your patch should be fine, although it would be nice if we didn't have callers setting up the sched_clock so early.

Quoted 65 lines · Stephen Boyd

Quoted 56 lines · Stephen Boyd

Quoted 55 lines · John Stultz

Quoted 10 lines · Stephen Boyd

In the next patch we're going to increase the number of bits that the generic sched_clock can handle to be greater than 32. With more than 32 bits the wraparound time can be larger than what can fit into the units that msecs_to_jiffies takes (unsigned int). Luckily, the wraparound is initially calculated in nanoseconds which we can easily use with hrtimers, so switch to using an hrtimer.

Cc Russell King <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Hrmm. So in my testing (under qemu), this patch causes bootup to hang.

qemu-system-arm -kernel zImage-arm -M vexpress-a9 -cpu cortex-a9 -nographic -m 1024 -append 'root=/dev/mmcblk0p2 rw mem=1024M raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB devtmpfs.mount=0' -sd test-arm.img -redir tcp:4300::22

Config file attached.

I haven't gotten a chance to look very closely, but it seems the folowing patch resolves the issue. I'm not sure if we're seeing callers to setup_sched_clock happen after sched_clock_postinit or what, but it probably needs another look over.

thanks

(quoted diff) +0 -1

-john

kernel/time/sched_clock.c +5 -5

index a269890b..c018ffc 100644
@@ -138,12 +138,6 @@ void __init setup_sched_clock(u32 (*read)(void),
 int bits, unsigned long rate)
      pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns,
 wraps every %lluns\n",
          bits, r, r_unit, res, wrap);
  -    /*
-     * Start the timer to keep sched_clock() properly updated and
-     * sets the initial epoch.
-     */
-    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC,
 HRTIMER_MODE_REL);
-    sched_clock_timer.function = sched_clock_poll;
      update_sched_clock();
        /*

@@ -175,6 +169,13 @@ void __init sched_clock_postinit(void)
          setup_sched_clock(jiffy_sched_clock_read, 32, HZ);
        update_sched_clock();
+
+    /*
+     * Start the timer to keep sched_clock() properly updated and
+     * sets the initial epoch.
+     */

Quoted 8 lines

kernel/time/sched_clock.c void __init sched_clock_postinit(void) · line 181

Quoted 6 lines

kernel/time/sched_clock.c +2 -0

+    hrtimer_init(&sched_clock_timer, CLOCK_MONOTONIC,
 HRTIMER_MODE_REL);
+    sched_clock_timer.function = sched_clock_poll;
      hrtimer_start(&sched_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
  }
 

Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into sched_clock_register() also causes the same crash.

Quoted 6 lines

Yes that seems to be the problem. The vexpress board is setting up the sched_clock in setup_arch() (via v2m_init_early) which runs before hrtimers_init(). I've only tested this on boards that setup the timer in the time_init() callback which runs after hrtimers_init(). Your patch should be fine, although it would be nice if we didn't have callers setting up the sched_clock so early.

Although as Russell pointed out, setting up sched_clock later isn't really a good option (although I'd like it best if we could handle switching sched_clocks dynamically as needed so there were less constraints on when it has to be registered).

So I'll probably fold in my change into the patch if you're ok with that?

The ARM architected system counter has at least 56 usable bits. Add support for counters with more than 32 bits to the generic sched_clock implementation so we can increase the time between wakeups due to dealing with wrap-around on these devices while benefiting from the irqtime accounting and suspend/resume handling that the generic sched_clock code already has. On my system using 56 bits over 32 bits changes the wraparound time from a few minutes to an hour. For faster running counters (GHz range) this is even more important because we may not be able to execute the timer in time to deal with the wraparound if only 32 bits are used.

We choose a maxsec value of 3600 seconds because we assume no system will go idle for more than an hour. In the future we may need to increase this value.

Note: All users should switch over to the 64-bit read function so we can remove setup_sched_clock() in favor of sched_clock_register().

Cc Russell King <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

---

Quoted 5 lines · Stephen Boyd

kernel/time/sched_clock.c +0 -0

@@ -110,14 +123,13 @@ void __init setup_sched_clock(u32 (*read)(void), int
  bits, unsigned long rate)
 	if (cd.rate > rate)
 		return;
 

kernel/time/sched_clock.c void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate) · line 128

Quoted 5 lines

kernel/time/sched_clock.c +1 -2

-	BUG_ON(bits > 32);
 	WARN_ON(!irqs_disabled());
 	read_sched_clock = read;
-	sched_clock_mask = (1 << bits) - 1;
+	sched_clock_mask = CLOCKSOURCE_MASK(bits);

Note that this conflicts with my integer overflow fix
(http://article.gmane.org/gmane.linux.ports.arm.kernel/252498) that I hope will get merged before 3.11 is out.

Register with the generic sched_clock framework now that it supports 64 bits. This fixes two problems with the current sched_clock support for machines using the architected timers. First off, we don't subtract the start value from subsequent sched_clock calls so we can potentially start off with sched_clock returning gigantic numbers. Second, there is no support for suspend/resume handling so problems such as discussed in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during suspend, 2012-10-23) can happen without this patch. Finally, it allows us to move the sched_clock setup into drivers clocksource out of the arch ports.

arch/arm/kernel/arch_timer.c +0 -14

index 221f07b..1791f12 100644
@@ -11,7 +11,6 @@
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/errno.h>
-#include <linux/sched_clock.h>
 
 #include <asm/delay.h>
 

@@ -22,13 +21,6 @@ static unsigned long arch_timer_read_counter_long(void)
 	return arch_timer_read_counter();
 }
 
-static u32 sched_clock_mult __read_mostly;
-
-static unsigned long long notrace arch_timer_sched_clock(void)
-{
-	return arch_timer_read_counter() * sched_clock_mult;
-}
-
 static struct delay_timer arch_delay_timer;
 
 static void __init arch_timer_delay_timer_register(void)

@@ -48,11 +40,5 @@ int __init arch_timer_arch_init(void)
 
 	arch_timer_delay_timer_register();
 
-	/* Cache the sched_clock multiplier to save a divide in the hot path. */
-	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
-	sched_clock_func = arch_timer_sched_clock;
-	pr_info("sched_clock: ARM arch timer >56 bits at %ukHz, resolution %uns\n",
-		arch_timer_rate / 1000, sched_clock_mult);
-
 	return 0;
 }

arch/arm64/Kconfig +1 -0

index 9737e97..e32b471 100644
@@ -14,6 +14,7 @@ config ARM64
 	select GENERIC_IOMAP
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW
+	select GENERIC_SCHED_CLOCK
 	select GENERIC_SMP_IDLE_THREAD
 	select GENERIC_TIME_VSYSCALL
 	select HARDIRQS_SW_RESEND

arch/arm64/kernel/time.c +0 -10

index 03dc371..29c39d5 100644
@@ -61,13 +61,6 @@ unsigned long profile_pc(struct pt_regs *regs)
 EXPORT_SYMBOL(profile_pc);
 #endif
 
-static u64 sched_clock_mult __read_mostly;
-
-unsigned long long notrace sched_clock(void)
-{
-	return arch_timer_read_counter() * sched_clock_mult;
-}
-
 void __init time_init(void)
 {
 	u32 arch_timer_rate;

@@ -78,9 +71,6 @@ void __init time_init(void)
 	if (!arch_timer_rate)
 		panic("Unable to initialise architected timer.\n");
 
-	/* Cache the sched_clock multiplier to save a divide in the hot path. */
-	sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
-
 	/* Calibrate the delay loop directly */
 	lpj_fine = arch_timer_rate / HZ;
 }

drivers/clocksource/arm_arch_timer.c +1 -0

index 053d846..2facf14 100644
@@ -17,6 +17,7 @@
 #include <linux/interrupt.h>
 #include <linux/of_irq.h>
 #include <linux/io.h>
+#include <linux/sched_clock.h>
 
 #include <asm/arch_timer.h>
 #include <asm/virt.h>

Register with the generic sched_clock framework now that it supports 64 bits. This fixes two problems with the current sched_clock support for machines using the architected timers. First off, we don't subtract the start value from subsequent sched_clock calls so we can potentially start off with sched_clock returning gigantic numbers. Second, there is no support for suspend/resume handling so problems such as discussed in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during suspend, 2012-10-23) can happen without this patch. Finally, it allows us to move the sched_clock setup into drivers clocksource out of the arch ports.

Cc Christopher Covington <[email protected]>

Cc Catalin Marinas <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Quoted 12 lines · Stephen Boyd

Register with the generic sched_clock framework now that it supports 64 bits. This fixes two problems with the current sched_clock support for machines using the architected timers. First off, we don't subtract the start value from subsequent sched_clock calls so we can potentially start off with sched_clock returning gigantic numbers. Second, there is no support for suspend/resume handling so problems such as discussed in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during suspend, 2012-10-23) can happen without this patch. Finally, it allows us to move the sched_clock setup into drivers clocksource out of the arch ports.

Quoted 3 lines

Cc Christopher Covington <[email protected]>

Cc Catalin Marinas <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

A boot failure on Exynos5/Arndale showed up in next-20131014[1], and a subsequent bisect has fingered this patch as the culprit.

I haven't had a chance to debug this any further, but wanted to share in case someone else can debug.

The console log is below, but don't think there is much useful there as it shows nothing after the 'Starting kernel ...' from u-boot.

Quoted 20 lines · Kevin Hilman

Quoted 12 lines · Stephen Boyd

Register with the generic sched_clock framework now that it supports 64 bits. This fixes two problems with the current sched_clock support for machines using the architected timers. First off, we don't subtract the start value from subsequent sched_clock calls so we can potentially start off with sched_clock returning gigantic numbers. Second, there is no support for suspend/resume handling so problems such as discussed in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during suspend, 2012-10-23) can happen without this patch. Finally, it allows us to move the sched_clock setup into drivers clocksource out of the arch ports.

Quoted 3 lines

Cc Christopher Covington <[email protected]>

Cc Catalin Marinas <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

A boot failure on Exynos5/Arndale showed up in next-20131014[1], and a subsequent bisect has fingered this patch as the culprit.

Quoted 5 lines

I haven't had a chance to debug this any further, but wanted to share in case someone else can debug.

The console log is below, but don't think there is much useful there as it shows nothing after the 'Starting kernel ...' from u-boot.

debug_ll output would be nice.

Anyway, that patch looks "weird". It is
definitely not what I sent out. Most notably, this hunk jumps out

(quoted diff) +9 -0

@@ -471,6 +472,15 @@ static int __init arch_timer_register(void)
                goto out;
        }
 
+       clocksource_register_hz(&clocksource_counter, arch_timer_rate);
+       cyclecounter.mult = clocksource_counter.mult;
+       cyclecounter.shift = clocksource_counter.shift;
+       timecounter_init(&timecounter, &cyclecounter,
+                        arch_counter_get_cntvct());
+
+       /* 56 bits minimum, so we assume worst case rollover */
+       sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
+
        if (arch_timer_use_virtual) {
                ppi = arch_timer_ppi[VIRT_PPI];
                err = request_percpu_irq(ppi, arch_timer_handler_virt,

Which is adding the clocksource_register_hz() and timecounter_init() call twice. It should only be adding the sched_clock_register() call and the sched_clock_register() call should be in arch_counter_register(). Can you try this patch?

drivers/clocksource/arm_arch_timer.c +0 -9

 }
 
 static void arch_timer_stop(struct clock_event_device *clk)

@@ -472,15 +475,6 @@ static int __init arch_timer_register(void)
 		goto out;
 	}
 
-	clocksource_register_hz(&clocksource_counter, arch_timer_rate);
-	cyclecounter.mult = clocksource_counter.mult;
-	cyclecounter.shift = clocksource_counter.shift;
-	timecounter_init(&timecounter, &cyclecounter,
-			 arch_counter_get_cntvct());
-
-	/* 56 bits minimum, so we assume worst case rollover */
-	sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
-
 	if (arch_timer_use_virtual) {
 		ppi = arch_timer_ppi[VIRT_PPI];
 		err = request_percpu_irq(ppi, arch_timer_handler_virt,

Quoted 1 line · Stephen Boyd

Can you try this patch?

Yup, your patch gets it booting again.

John, how do you want to proceed on this? The version of $SUBJECT patch that made it to -next doesn't match the one in sent in this thread.

Quoted 17 lines · Kevin Hilman

Quoted 12 lines · Stephen Boyd

Register with the generic sched_clock framework now that it supports 64 bits. This fixes two problems with the current sched_clock support for machines using the architected timers. First off, we don't subtract the start value from subsequent sched_clock calls so we can potentially start off with sched_clock returning gigantic numbers. Second, there is no support for suspend/resume handling so problems such as discussed in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during suspend, 2012-10-23) can happen without this patch. Finally, it allows us to move the sched_clock setup into drivers clocksource out of the arch ports.

Quoted 3 lines

Cc Christopher Covington <[email protected]>

Cc Catalin Marinas <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

Quoted 8 lines

A boot failure on Exynos5/Arndale showed up in next-20131014[1], and a subsequent bisect has fingered this patch as the culprit.

I haven't had a chance to debug this any further, but wanted to share in case someone else can debug.

The console log is below, but don't think there is much useful there as it shows nothing after the 'Starting kernel ...' from u-boot.

debug_ll output would be nice. Anyway, that patch looks "weird". It is definitely not what I sent out. Most notably, this hunk jumps out

(quoted diff) +9 -0

@@ -471,6 +472,15 @@ static int __init arch_timer_register(void)
                goto out;
        }
 
+       clocksource_register_hz(&clocksource_counter, arch_timer_rate);
+       cyclecounter.mult = clocksource_counter.mult;
+       cyclecounter.shift = clocksource_counter.shift;
+       timecounter_init(&timecounter, &cyclecounter,
+                        arch_counter_get_cntvct());
+
+       /* 56 bits minimum, so we assume worst case rollover */
+       sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
+
        if (arch_timer_use_virtual) {
                ppi = arch_timer_ppi[VIRT_PPI];
                err = request_percpu_irq(ppi, arch_timer_handler_virt,

Which is adding the clocksource_register_hz() and timecounter_init() call twice. It should only be adding the sched_clock_register() call and the sched_clock_register() call should be in arch_counter_register().

The 32 bit sched_clock interface now supports 64 bits. Upgrade to the 64 bit function to allow us to remove the 32 bit registration interface.

The 32 bit sched_clock interface now supports 64 bits. Upgrade to the 64 bit function to allow us to remove the 32 bit registration interface.

Cc Stephen Warren <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

---

 drivers/clocksource/bcm2835_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/clocksource/bcm2835_timer.c +2 -2

index 07ea7ce..26ed331 100644
@@ -49,7 +49,7 @@ struct bcm2835_timer {
 
 static void __iomem *system_clock __read_mostly;
 
-static u32 notrace bcm2835_sched_read(void)
+static u64 notrace bcm2835_sched_read(void)
 {
 	return readl_relaxed(system_clock);
 }

@@ -110,7 +110,7 @@ static void __init bcm2835_timer_init(struct device_node *node)
 		panic("Can't read clock-frequency");
 
 	system_clock = base + REG_COUNTER_LO;
-	setup_sched_clock(bcm2835_sched_read, 32, freq);
+	sched_clock_register(bcm2835_sched_read, 32, freq);
 
 	clocksource_mmio_init(base + REG_COUNTER_LO, node->name,
 		freq, 300, 32, clocksource_mmio_readl_up);

Quoted 7 lines · Stephen Boyd

The 32 bit sched_clock interface now supports 64 bits. Upgrade to the 64 bit function to allow us to remove the 32 bit registration interface.

Cc Stephen Warren <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

---

Hi Stephen,

you sent a series with tick and clocksource changes.

John is recipient of part of them. I replaced him to maintain the clocksource drivers.

Is the series you sent for clocksource drivers supposed to be taken by me or by Russell ?

In the future if there are no dependencies, it would be preferable to group the clocksource drivers changes into a series and send them to me.

The 32 bit sched_clock interface now supports 64 bits. Upgrade to the 64 bit function to allow us to remove the 32 bit registration interface.

Cc Srinidhi Kasagar <[email protected]>

Cc Linus Walleij <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

---

The 32 bit sched_clock interface now supports 64 bits. Upgrade to the 64 bit function to allow us to remove the 32 bit registration interface.

Cc Shawn Guo <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

---
 drivers/clocksource/mxs_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/clocksource/mxs_timer.c +2 -2

index 0f5e65f..445b68a 100644
@@ -222,7 +222,7 @@ static struct clocksource clocksource_mxs = {
 	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-static u32 notrace mxs_read_sched_clock_v2(void)
+static u64 notrace mxs_read_sched_clock_v2(void)
 {
 	return ~readl_relaxed(mxs_timrot_base + HW_TIMROT_RUNNING_COUNTn(1));
 }

@@ -236,7 +236,7 @@ static int __init mxs_clocksource_init(struct clk *timer_clk)
 	else {
 		clocksource_mmio_init(mxs_timrot_base + HW_TIMROT_RUNNING_COUNTn(1),
 			"mxs_timer", c, 200, 32, clocksource_mmio_readl_down);
-		setup_sched_clock(mxs_read_sched_clock_v2, 32, c);
+		sched_clock_register(mxs_read_sched_clock_v2, 32, c);
 	}
 
 	return 0;

Signature · 2 lines

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Quoted 4 lines · Stephen Boyd

The 32 bit sched_clock interface now supports 64 bits. Upgrade to the 64 bit function to allow us to remove the 32 bit registration interface.

Quoted 1 line

Cc Shawn Guo <[email protected]>

Acked-by Shawn Guo <[email protected]>

BTW, will the series break setup_sched_clock() users that are not converted, like arch/arm/mach-imx/time.c? I can understand that's the consequence of not moving things into drivers/ folder :)

The 32 bit sched_clock interface now supports 64 bits. Upgrade to the 64 bit function to allow us to remove the 32 bit registration interface.

The 32 bit sched_clock interface now supports 64 bits. Upgrade to the 64 bit function to allow us to remove the 32 bit registration interface.

Cc Gregory CLEMENT <[email protected]>

Signed-off-by Stephen Boyd <[email protected]>

---
 drivers/clocksource/time-armada-370-xp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/clocksource/time-armada-370-xp.c +2 -2

index efdca32..2bec8dc 100644
@@ -71,7 +71,7 @@ static u32 ticks_per_jiffy;
 
 static struct clock_event_device __percpu **percpu_armada_370_xp_evt;
 
-static u32 notrace armada_370_xp_read_sched_clock(void)
+static u64 notrace armada_370_xp_read_sched_clock(void)
 {
 	return ~readl(timer_base + TIMER0_VAL_OFF);
 }

@@ -258,7 +258,7 @@ void __init armada_370_xp_timer_init(void)
 	/*
 	 * Set scale and timer for sched_clock.
 	 */
-	setup_sched_clock(armada_370_xp_read_sched_clock, 32, timer_clk);
+	sched_clock_register(armada_370_xp_read_sched_clock, 32, timer_clk);
 
 	/*
 	 * Setup free-running clocksource timer (interrupts

This patchset adds support for 64 bit counters in the generic sched_clock code and converts drivers over to use it. Based on v3.11-rc1.

Changes since v3:
* Move to use seqcount to fix issues with 64-bit cyc counters
* Move to hrtimer to fix underflow/overflow errors in wraparound calculation
* Use of 1 hour in clocks_calc_mult_shift
* Converted over drivers in drivers/clocksource

Quoted 10 lines · Stephen Boyd

This patchset adds support for 64 bit counters in the generic sched_clock code and converts drivers over to use it. Based on v3.11-rc1.

Changes since v3:
* Move to use seqcount to fix issues with 64-bit cyc counters
* Move to hrtimer to fix underflow/overflow errors in wraparound calculation
* Use of 1 hour in clocks_calc_mult_shift
* Converted over drivers in drivers/clocksource

I've not been able to take a deep review yet, but this looks pretty much like what we discussed last week, so I'm happy with it so far. Has this gotten much testing (on both 32 and 64bit systems?)

Quoted 10 lines · Stephen Boyd

This patchset adds support for 64 bit counters in the generic sched_clock code and converts drivers over to use it. Based on v3.11-rc1.

Changes since v3:
* Move to use seqcount to fix issues with 64-bit cyc counters
* Move to hrtimer to fix underflow/overflow errors in wraparound calculation
* Use of 1 hour in clocks_calc_mult_shift
* Converted over drivers in drivers/clocksource

I've not been able to take a deep review yet, but this looks pretty much like what we discussed last week, so I'm happy with it so far. Has this gotten much testing (on both 32 and 64bit systems?)

One detail: Most of this is likely to go in via tip/timers/core, but the 5/17 "arch_timer: Move to generic sched_clock" will need some synchronization with Catalin to make sure its ok to go in via tip. Not sure what other arm64 changes are pending that would depend or collide with that change.

Quoted 15 lines · John Stultz

Quoted 10 lines · Stephen Boyd

This patchset adds support for 64 bit counters in the generic sched_clock code and converts drivers over to use it. Based on v3.11-rc1.

Changes since v3:
* Move to use seqcount to fix issues with 64-bit cyc counters
* Move to hrtimer to fix underflow/overflow errors in wraparound calculation
* Use of 1 hour in clocks_calc_mult_shift
* Converted over drivers in drivers/clocksource

I've not been able to take a deep review yet, but this looks pretty much like what we discussed last week, so I'm happy with it so far. Has this gotten much testing (on both 32 and 64bit systems?)

Quoted 5 lines

One detail: Most of this is likely to go in via tip/timers/core, but the 5/17 "arch_timer: Move to generic sched_clock" will need some synchronization with Catalin to make sure its ok to go in via tip. Not sure what other arm64 changes are pending that would depend or collide with that change.

I wouldn't expect anything more than a trivial Kconfig clash with the arm64 tree, if that.

Quoted 21 lines · Will Deacon

Quoted 20 lines · John Stultz

Quoted 10 lines · Stephen Boyd

This patchset adds support for 64 bit counters in the generic sched_clock code and converts drivers over to use it. Based on v3.11-rc1.

Changes since v3:
* Move to use seqcount to fix issues with 64-bit cyc counters
* Move to hrtimer to fix underflow/overflow errors in wraparound calculation
* Use of 1 hour in clocks_calc_mult_shift
* Converted over drivers in drivers/clocksource

I've not been able to take a deep review yet, but this looks pretty much like what we discussed last week, so I'm happy with it so far. Has this gotten much testing (on both 32 and 64bit systems?)

One detail: Most of this is likely to go in via tip/timers/core, but the 5/17 "arch_timer: Move to generic sched_clock" will need some synchronization with Catalin to make sure its ok to go in via tip. Not sure what other arm64 changes are pending that would depend or collide with that change.

Quoted 2 lines

I wouldn't expect anything more than a trivial Kconfig clash with the arm64 tree, if that.

So I also have a branch with these changes based on a branch with only the prereqs that are already merged, so I can provide a pull request that can go in via the aarch64 tree and won't collide with tip. Would that be preferrable?

This patchset adds support for 64 bit counters in the generic sched_clock code and converts drivers over to use it. Based on v3.11-rc1.

Changes since v3:

ocksource: dbx500-prcmu: Switch to sched_clock_register()

clocksource: nomadik: Switch to sched_clock_register()

Quoted 7 lines · Stephen Boyd

This patchset adds support for 64 bit counters in the generic sched_clock code and converts drivers over to use it. Based on v3.11-rc1.

Changes since v3:

ocksource: dbx500-prcmu: Switch to sched_clock_register()

Fix subject.

Quoted 1 line

clocksource: nomadik: Switch to sched_clock_register()

Apart from that Acked-by: Linus Walleij <[email protected]> for these two drivers.

BTW: why are you not patching arch/arm/mach-u300/timer.c? Please make sure to grep for all setup_sched_clock() if you're going to do this.

This patchset adds support for 64 bit counters in the generic sched_clock code and converts drivers over to use it. Based on v3.11-rc1.

Changes since v3:
* Move to use seqcount to fix issues with 64-bit cyc counters
* Move to hrtimer to fix underflow/overflow errors in wraparound calculation
* Use of 1 hour in clocks_calc_mult_shift
* Converted over drivers in drivers/clocksource

Stephen Boyd (17):
clocksource: Extract max nsec calculation into separate function
sched_clock: Use seqcount instead of rolling our own
sched_clock: Use an hrtimer instead of timer
sched_clock: Add support for >32 bit sched_clock
arch_timer: Move to generic sched_clock framework
sched_clock: Remove sched_clock_func() hook
clocksource: bcm2835: Switch to sched_clock_register()
ocksource: dbx500-prcmu: Switch to sched_clock_register()
clocksource: dw_apb_timer_of: Switch to sched_clock_register()

clocksource: mxs_timer: Switch to sched_clock_register()
clocksource: nomadik: Switch to sched_clock_register()
clocksource: samsung_pwm_timer: Switch to sched_clock_register()
clocksource: tegra: Switch to sched_clock_register()
clocksource: time-armada-370-xp: Switch to sched_clock_register()
clocksource: sirf: Switch to sched_clock_register() and use 64 bits
clocksource: vf_pit_timer: Switch to sched_clock_register()
sched_clock: Deprecate setup_sched_clock()

This patchset adds support for 64 bit counters in the generic sched_clock code and converts drivers over to use it. Based on v3.11-rc1.

Changes since v3:
* Move to use seqcount to fix issues with 64-bit cyc counters
* Move to hrtimer to fix underflow/overflow errors in wraparound calculation
* Use of 1 hour in clocks_calc_mult_shift
* Converted over drivers in drivers/clocksource

Stephen Boyd (17):
clocksource: Extract max nsec calculation into separate function
sched_clock: Use seqcount instead of rolling our own
sched_clock: Use an hrtimer instead of timer
sched_clock: Add support for >32 bit sched_clock
arch_timer: Move to generic sched_clock framework
sched_clock: Remove sched_clock_func() hook
clocksource: bcm2835: Switch to sched_clock_register()
ocksource: dbx500-prcmu: Switch to sched_clock_register()
clocksource: dw_apb_timer_of: Switch to sched_clock_register()
clocksource: mxs_timer: Switch to sched_clock_register()
clocksource: nomadik: Switch to sched_clock_register()
clocksource: samsung_pwm_timer: Switch to sched_clock_register()
clocksource: tegra: Switch to sched_clock_register()
clocksource: time-armada-370-xp: Switch to sched_clock_register()
clocksource: sirf: Switch to sched_clock_register() and use 64 bits
clocksource: vf_pit_timer: Switch to sched_clock_register()
sched_clock: Deprecate setup_sched_clock()

 arch/arm/kernel/arch_timer.c              |  14 ----
 arch/arm64/Kconfig                        |   1 +
 arch/arm64/kernel/time.c                  |  10 ---
 drivers/clocksource/arm_arch_timer.c      |   4 ++
 drivers/clocksource/bcm2835_timer.c       |   4 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c |   5 +-
 drivers/clocksource/dw_apb_timer_of.c     |   4 +-
 drivers/clocksource/mxs_timer.c           |   4 +-
 drivers/clocksource/nomadik-mtu.c         |   4 +-
 drivers/clocksource/samsung_pwm_timer.c   |   4 +-
 drivers/clocksource/tegra20_timer.c       |   4 +-

 drivers/clocksource/time-armada-370-xp.c  |   4 +-
 drivers/clocksource/timer-prima2.c        |   6 +-
 drivers/clocksource/vf_pit_timer.c        |   4 +-
 include/linux/clocksource.h               |   2 +
 include/linux/sched_clock.h               |   7 +-
 kernel/time/clocksource.c                 |  45 ++++++++-----
 kernel/time/sched_clock.c                 | 105 +++++++++++++++---------------
 18 files changed, 116 insertions(+), 115 deletions(-)