Make ARM's sched_clock generic + 64 bit friendly

Nothing about the sched_clock implementation in the ARM port is specific to the architecture. Generalize the code so that other architectures can use it by selecting GENERIC_SCHED_CLOCK.

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

---
 arch/arm/Kconfig                                      | 1 +
 arch/arm/common/timer-sp.c                            | 2 +-
 arch/arm/kernel/Makefile                              | 2 +-
 arch/arm/kernel/arch_timer.c                          | 2 +-
 arch/arm/kernel/time.c                                | 4 +---
 arch/arm/mach-davinci/time.c                          | 2 +-
 arch/arm/mach-imx/time.c                              | 2 +-
 arch/arm/mach-integrator/integrator_ap.c              | 2 +-
 arch/arm/mach-ixp4xx/common.c                         | 2 +-
 arch/arm/mach-mmp/time.c                              | 2 +-
 arch/arm/mach-msm/timer.c                             | 2 +-
 arch/arm/mach-omap1/time.c                            | 2 +-
 arch/arm/mach-omap2/timer.c                           | 2 +-
 arch/arm/mach-pxa/time.c                              | 2 +-
 arch/arm/mach-sa1100/time.c                           | 2 +-
 arch/arm/mach-u300/timer.c                            | 2 +-
 arch/arm/plat-iop/time.c                              | 2 +-
 arch/arm/plat-omap/counter_32k.c                      | 2 +-
 arch/arm/plat-orion/time.c                            | 2 +-
 arch/arm/plat-samsung/samsung-time.c                  | 2 +-
 arch/arm/plat-versatile/sched-clock.c                 | 2 +-
 drivers/clocksource/bcm2835_timer.c                   | 2 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c             | 3 +--
 drivers/clocksource/dw_apb_timer_of.c                 | 2 +-

 drivers/clocksource/mxs_timer.c                       | 2 +-
 drivers/clocksource/nomadik-mtu.c                     | 2 +-
 drivers/clocksource/samsung_pwm_timer.c               | 2 +-
 drivers/clocksource/tegra20_timer.c                   | 2 +-
 drivers/clocksource/time-armada-370-xp.c              | 2 +-
 drivers/clocksource/timer-marco.c                     | 2 +-
 drivers/clocksource/timer-prima2.c                    | 2 +-
 {arch/arm/include/asm => include/linux}/sched_clock.h | 9 +++++++--

 init/Kconfig                                          | 3 +++
 init/main.c                                           | 2 ++
 kernel/time/Makefile                                  | 1 +
 {arch/arm/kernel => kernel/time}/sched_clock.c        | 3 +--
 36 files changed, 45 insertions(+), 37 deletions(-)
 rename {arch/arm/include/asm => include/linux}/sched_clock.h (75%)
 rename {arch/arm/kernel => kernel/time}/sched_clock.c (99%)

Hi Stephen,

Quoted 30 lines · Stephen Boyd

Nothing about the sched_clock implementation in the ARM port is specific to the architecture. Generalize the code so that other architectures can use it by selecting GENERIC_SCHED_CLOCK.

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

---
 arch/arm/Kconfig                                      | 1 +
 arch/arm/common/timer-sp.c                            | 2 +-
 arch/arm/kernel/Makefile                              | 2 +-
 arch/arm/kernel/arch_timer.c                          | 2 +-
 arch/arm/kernel/time.c                                | 4 +---
 arch/arm/mach-davinci/time.c                          | 2 +-
 arch/arm/mach-imx/time.c                              | 2 +-
 arch/arm/mach-integrator/integrator_ap.c              | 2 +-
 arch/arm/mach-ixp4xx/common.c                         | 2 +-
 arch/arm/mach-mmp/time.c                              | 2 +-
 arch/arm/mach-msm/timer.c                             | 2 +-
 arch/arm/mach-omap1/time.c                            | 2 +-
 arch/arm/mach-omap2/timer.c                           | 2 +-
 arch/arm/mach-pxa/time.c                              | 2 +-
 arch/arm/mach-sa1100/time.c                           | 2 +-
 arch/arm/mach-u300/timer.c                            | 2 +-
 arch/arm/plat-iop/time.c                              | 2 +-
 arch/arm/plat-omap/counter_32k.c                      | 2 +-
 arch/arm/plat-orion/time.c                            | 2 +-
 arch/arm/plat-samsung/samsung-time.c                  | 2 +-
 arch/arm/plat-versatile/sched-clock.c                 | 2 +-
 drivers/clocksource/bcm2835_timer.c                   | 2 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c             | 3 +--
 drivers/clocksource/dw_apb_timer_of.c                 | 2 +-

Quoted 8 lines

 drivers/clocksource/mxs_timer.c                       | 2 +-
 drivers/clocksource/nomadik-mtu.c                     | 2 +-
 drivers/clocksource/samsung_pwm_timer.c               | 2 +-
 drivers/clocksource/tegra20_timer.c                   | 2 +-
 drivers/clocksource/time-armada-370-xp.c              | 2 +-
 drivers/clocksource/timer-marco.c                     | 2 +-
 drivers/clocksource/timer-prima2.c                    | 2 +-
 {arch/arm/include/asm => include/linux}/sched_clock.h | 9 +++++++--

Shouldn't we just merge this header into the existing linux/sched.h?

Quoted 5 lines · Baruch Siach

Hi Stephen,

Quoted 1 line · Stephen Boyd

  {arch/arm/include/asm => include/linux}/sched_clock.h | 9 +++++++--

Shouldn't we just merge this header into the existing linux/sched.h?

I don't know. John/Thomas, any thoughts? One benefit with it this way is that we don't have to recompile all the timer drivers if we change sched.h for other reasons.

Quoted 6 lines · Stephen Boyd

Quoted 5 lines · Baruch Siach

Hi Stephen,

Quoted 1 line · Stephen Boyd

  {arch/arm/include/asm => include/linux}/sched_clock.h | 9 +++++++--

Shouldn't we just merge this header into the existing linux/sched.h?

Quoted 3 lines

I don't know. John/Thomas, any thoughts? One benefit with it this way is that we don't have to recompile all the timer drivers if we change sched.h for other reasons.

Yea, I'm fine keeping it separate for now. We can merge them together if we see fit later.

But if anyone feels particularly strongly, let me know.

Nothing about the sched_clock implementation in the ARM port is specific to the architecture. Generalize the code so that other architectures can use it by selecting GENERIC_SCHED_CLOCK.

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

---
 arch/arm/Kconfig                                      | 1 +
 arch/arm/common/timer-sp.c                            | 2 +-
 arch/arm/kernel/Makefile                              | 2 +-
 arch/arm/kernel/arch_timer.c                          | 2 +-
 arch/arm/kernel/time.c                                | 4 +---
 arch/arm/mach-davinci/time.c                          | 2 +-
 arch/arm/mach-imx/time.c                              | 2 +-
 arch/arm/mach-integrator/integrator_ap.c              | 2 +-
 arch/arm/mach-ixp4xx/common.c                         | 2 +-
 arch/arm/mach-mmp/time.c                              | 2 +-
 arch/arm/mach-msm/timer.c                             | 2 +-
 arch/arm/mach-omap1/time.c                            | 2 +-
 arch/arm/mach-omap2/timer.c                           | 2 +-
 arch/arm/mach-pxa/time.c                              | 2 +-
 arch/arm/mach-sa1100/time.c                           | 2 +-
 arch/arm/mach-u300/timer.c                            | 2 +-
 arch/arm/plat-iop/time.c                              | 2 +-
 arch/arm/plat-omap/counter_32k.c                      | 2 +-
 arch/arm/plat-orion/time.c                            | 2 +-
 arch/arm/plat-samsung/samsung-time.c                  | 2 +-
 arch/arm/plat-versatile/sched-clock.c                 | 2 +-
 drivers/clocksource/bcm2835_timer.c                   | 2 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c             | 3 +--
 drivers/clocksource/dw_apb_timer_of.c                 | 2 +-
 drivers/clocksource/mxs_timer.c                       | 2 +-
 drivers/clocksource/nomadik-mtu.c                     | 2 +-
 drivers/clocksource/samsung_pwm_timer.c               | 2 +-
 drivers/clocksource/tegra20_timer.c                   | 2 +-

 drivers/clocksource/time-armada-370-xp.c              | 2 +-
 drivers/clocksource/timer-marco.c                     | 2 +-
 drivers/clocksource/timer-prima2.c                    | 2 +-
 {arch/arm/include/asm => include/linux}/sched_clock.h | 9 +++++++--
 init/Kconfig                                          | 3 +++
 init/main.c                                           | 2 ++
 kernel/time/Makefile                                  | 1 +
 {arch/arm/kernel => kernel/time}/sched_clock.c        | 3 +--

This causes build failures when doing a simple merge with the arm-soc tree:

==> build/clps711x_defconfig/faillog <== /git/arm-soc/arch/arm/mach-clps711x/common.c:37:29: fatal error: asm/sched_clock.h: No such file or directory

 #include <asm/sched_clock.h>
                             ^

==> build/imx_v6_v7_defconfig/faillog <== /git/arm-soc/drivers/clocksource/vf_pit_timer.c:15:29: fatal error: asm/sched_clock.h: No such file or directory
#include <asm/sched_clock.h>

How about adding back a temporary arch/arm/include/asm/sched_clock.h that only contains "#include <linux/sched_clock.h>" so we can change those two files after the merge and still get a bisectible history?

Quoted 11 lines · Arnd Bergmann

This causes build failures when doing a simple merge with the arm-soc tree:

==> build/clps711x_defconfig/faillog <== /git/arm-soc/arch/arm/mach-clps711x/common.c:37:29: fatal error: asm/sched_clock.h: No such file or directory

  #include <asm/sched_clock.h>
                              ^

==> build/imx_v6_v7_defconfig/faillog <== /git/arm-soc/drivers/clocksource/vf_pit_timer.c:15:29: fatal error: asm/sched_clock.h: No such file or directory
#include <asm/sched_clock.h>

Quoted 4 lines

How about adding back a temporary arch/arm/include/asm/sched_clock.h that only contains "#include <linux/sched_clock.h>" so we can change those two files after the merge and still get a bisectible history?

Sounds fine. John can you add this patch on top?

Quoted 14 lines · Stephen Boyd

Quoted 13 lines · Arnd Bergmann

This causes build failures when doing a simple merge with the arm-soc tree:

==> build/clps711x_defconfig/faillog <== /git/arm-soc/arch/arm/mach-clps711x/common.c:37:29: fatal error:
asm/sched_clock.h: No such file or directory

  #include <asm/sched_clock.h>
                              ^

==> build/imx_v6_v7_defconfig/faillog <== /git/arm-soc/drivers/clocksource/vf_pit_timer.c:15:29: fatal error:
asm/sched_clock.h: No such file or directory
#include <asm/sched_clock.h>

Quoted 5 lines

Quoted 4 lines

How about adding back a temporary arch/arm/include/asm/sched_clock.h that only contains "#include <linux/sched_clock.h>" so we can change those two files after the merge and still get a bisectible history?

Sounds fine. John can you add this patch on top?

Thanks. I've queued this and will send it on to Thomas here shortly.

Quoted 19 lines · John Stultz

Quoted 18 lines · Stephen Boyd

Quoted 17 lines · Arnd Bergmann

This causes build failures when doing a simple merge with the arm-soc tree:

==> build/clps711x_defconfig/faillog <== /git/arm-soc/arch/arm/mach-clps711x/common.c:37:29: fatal error:
asm/sched_clock.h: No such file or directory

   #include <asm/sched_clock.h>
                               ^

==> build/imx_v6_v7_defconfig/faillog <== /git/arm-soc/drivers/clocksource/vf_pit_timer.c:15:29: fatal error:
asm/sched_clock.h: No such file or directory
#include <asm/sched_clock.h>

How about adding back a temporary arch/arm/include/asm/sched_clock.h that only contains "#include <linux/sched_clock.h>" so we can change those two files after the merge and still get a bisectible history?

Quoted 2 lines

Quoted 1 line

Sounds fine. John can you add this patch on top?

Thanks. I've queued this and will send it on to Thomas here shortly.

Thanks John. Can you send this off to the tip tree? I think we'll need to merge tip/timers into arm-soc so I can send the rest of my "kill ARM local timer API" series through and this patch helps make that more palatable.

The ARM architected system counter has at least 56 useable bits. Add support for counters with more than 32 bits to the generic sched_clock implementation so we can avoid the complexity of 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.

kernel/time/sched_clock.c +4 -0

+}
+
+void __init
+setup_sched_clock_64(u64 (*read)(void), int bits, unsigned long rate)

kernel/time/sched_clock.c static unsigned long long notrace sched_clock_32(void) · line 188

Quoted 4 lines · Stephen Boyd

kernel/time/sched_clock.c +4 -0

+static unsigned long long notrace sched_clock_64(void)
+{
+	u64 cyc = read_sched_clock_64() - cd.epoch_ns;
+	return cyc * cd.mult;

So, the use of cd.mult implies that the return value from read_sched_clock_64() is not nanoseconds but something else. But then we subtract it from the nanoseconds epoch - which has to be nanoseconds because you simply return that when suspended.

Quoted 11 lines

kernel/time/sched_clock.c +10 -0

+}
+
+void __init
+setup_sched_clock_64(u64 (*read)(void), int bits, unsigned long rate)
+{
+	if (cd.rate > rate)
+		return;
+
+	BUG_ON(bits <= 32);
+	WARN_ON(!irqs_disabled());

kernel/time/sched_clock.c static unsigned long long notrace sched_clock_32(void) · line 202

Quoted 4 lines

kernel/time/sched_clock.c +4 -0

+	read_sched_clock_64 = read;
+	sched_clock_func = sched_clock_64;
+	cd.rate = rate;
+	cd.mult = NSEC_PER_SEC / rate;

Here, you don't check that the (2^bits) * mult results in a wrap of the resulting 64-bit number, which is a _basic_ requirement for sched_clock (hence all the code for <=32bit clocks, otherwise we wouldn't need this complexity in the first place.)

Quoted 11 lines · Russell King - ARM Linux

Quoted 10 lines · Stephen Boyd

kernel/time/sched_clock.c +10 -0

+}
+
+void __init
+setup_sched_clock_64(u64 (*read)(void), int bits, unsigned long rate)
+{
+	if (cd.rate > rate)
+		return;
+
+	BUG_ON(bits <= 32);
+	WARN_ON(!irqs_disabled());

Quoted 8 lines

kernel/time/sched_clock.c static unsigned long long notrace sched_clock_32(void) · line 202

Quoted 4 lines

kernel/time/sched_clock.c +4 -0

+	read_sched_clock_64 = read;
+	sched_clock_func = sched_clock_64;
+	cd.rate = rate;
+	cd.mult = NSEC_PER_SEC / rate;

Here, you don't check that the (2^bits) * mult results in a wrap of the resulting 64-bit number, which is a _basic_ requirement for sched_clock (hence all the code for <=32bit clocks, otherwise we wouldn't need this complexity in the first place.)

Ok I will use clocks_calc_mult_shift() here.

Quoted 20 lines · Stephen Boyd

Quoted 11 lines · Russell King - ARM Linux

Quoted 10 lines · Stephen Boyd

kernel/time/sched_clock.c +10 -0

+}
+
+void __init
+setup_sched_clock_64(u64 (*read)(void), int bits, unsigned long rate)
+{
+	if (cd.rate > rate)
+		return;
+
+	BUG_ON(bits <= 32);
+	WARN_ON(!irqs_disabled());

Quoted 8 lines

kernel/time/sched_clock.c static unsigned long long notrace sched_clock_32(void) · line 202

Quoted 4 lines

kernel/time/sched_clock.c +4 -0

+	read_sched_clock_64 = read;
+	sched_clock_func = sched_clock_64;
+	cd.rate = rate;
+	cd.mult = NSEC_PER_SEC / rate;

Here, you don't check that the (2^bits) * mult results in a wrap of the resulting 64-bit number, which is a _basic_ requirement for sched_clock (hence all the code for <=32bit clocks, otherwise we wouldn't need this complexity in the first place.)

Quoted 1 line

Ok I will use clocks_calc_mult_shift() here.

No, that's not the problem.

If you have a 56-bit clock which ticks at a period of 1ns, then cd.rate = 1, and your sched_clock() values will be truncated to 56-bits. The scheduler always _requires_ 64-bits from sched_clock. That's why we have the complicated code to extend the 32-bits-or-less to a _full_ 64-bit value.

Let me make this clearer: sched_clock() return values _must_ without exception monotonically increment from zero to 2^64-1 and then wrap back to zero. No other behaviour is acceptable for sched_clock().

Quoted 9 lines · Russell King - ARM Linux

If you have a 56-bit clock which ticks at a period of 1ns, then cd.rate = 1, and your sched_clock() values will be truncated to 56-bits. The scheduler always _requires_ 64-bits from sched_clock. That's why we have the complicated code to extend the 32-bits-or-less to a _full_ 64-bit value.

Let me make this clearer: sched_clock() return values _must_ without exception monotonically increment from zero to 2^64-1 and then wrap back to zero. No other behaviour is acceptable for sched_clock().

Ok so you're saying if we have less than 64 bits of useable information we _must_ do something to find where the wraparound will occur and adjust for it so that epoch_ns is always incrementing until 2^64-1. Fair enough. I was trying to avoid more work because on arm architected timer platforms it takes many years for that to happen.

I'll see what I can do.

Quoted 17 lines · Stephen Boyd

Quoted 9 lines · Russell King - ARM Linux

If you have a 56-bit clock which ticks at a period of 1ns, then cd.rate = 1, and your sched_clock() values will be truncated to 56-bits. The scheduler always _requires_ 64-bits from sched_clock. That's why we have the complicated code to extend the 32-bits-or-less to a _full_ 64-bit value.

Let me make this clearer: sched_clock() return values _must_ without exception monotonically increment from zero to 2^64-1 and then wrap back to zero. No other behaviour is acceptable for sched_clock().

Ok so you're saying if we have less than 64 bits of useable information we _must_ do something to find where the wraparound will occur and adjust for it so that epoch_ns is always incrementing until 2^64-1. Fair enough. I was trying to avoid more work because on arm architected timer platforms it takes many years for that to happen.

Quoted 1 line

I'll see what I can do.

Well, 56 bits at 1ns intervals is 833 days (2^56 / (1000000000*60*60*24)). We used to say that 497 days was enough several years ago, and that got fixed. We used to say 640K was enough memory for anything, and that got fixed.

Quoted 20 lines · Russell King - ARM Linux

Quoted 18 lines · Stephen Boyd

Quoted 9 lines · Russell King - ARM Linux

If you have a 56-bit clock which ticks at a period of 1ns, then cd.rate = 1, and your sched_clock() values will be truncated to 56-bits. The scheduler always _requires_ 64-bits from sched_clock. That's why we have the complicated code to extend the 32-bits-or-less to a _full_ 64-bit value.

Let me make this clearer: sched_clock() return values _must_ without exception monotonically increment from zero to 2^64-1 and then wrap back to zero. No other behaviour is acceptable for sched_clock().

Ok so you're saying if we have less than 64 bits of useable information we _must_ do something to find where the wraparound will occur and adjust for it so that epoch_ns is always incrementing until 2^64-1. Fair enough. I was trying to avoid more work because on arm architected timer platforms it takes many years for that to happen.

I'll see what I can do.

Quoted 4 lines

Well, 56 bits at 1ns intervals is 833 days (2^56 / (1000000000*60*60*24)). We used to say that 497 days was enough several years ago, and that got fixed. We used to say 640K was enough memory for anything, and that got fixed.

The ARM ARM states a minimum resolution of 40 years AND at least 56-bits of resolution. So a 1Gz counter would have to have more that 56 bits.

Quoted 21 lines · Stephen Boyd

Quoted 11 lines · Russell King - ARM Linux

Quoted 10 lines · Stephen Boyd

kernel/time/sched_clock.c +10 -0

+}
+
+void __init
+setup_sched_clock_64(u64 (*read)(void), int bits, unsigned long rate)
+{
+  if (cd.rate > rate)
+          return;
+
+  BUG_ON(bits <= 32);
+  WARN_ON(!irqs_disabled());

Quoted 8 lines

kernel/time/sched_clock.c static unsigned long long notrace sched_clock_32(void) · line 202

Quoted 4 lines

kernel/time/sched_clock.c +4 -0

+  read_sched_clock_64 = read;
+  sched_clock_func = sched_clock_64;
+  cd.rate = rate;
+  cd.mult = NSEC_PER_SEC / rate;

Here, you don't check that the (2^bits) * mult results in a wrap of the resulting 64-bit number, which is a _basic_ requirement for sched_clock (hence all the code for <=32bit clocks, otherwise we wouldn't need this complexity in the first place.)

Quoted 1 line

Ok I will use clocks_calc_mult_shift() here.

No, that's not the problem.

If you have a 56-bit clock which ticks at a period of 1ns, then cd.rate = 1, and your sched_clock() values will be truncated to 56-bits. The scheduler always _requires_ 64-bits from sched_clock. That's why we have the complicated code to extend the 32-bits-or-less to a _full_ 64-bit value.

Let me make this clearer: sched_clock() return values _must_ without exception monotonically increment from zero to 2^64-1 and then wrap back to zero. No other behaviour is acceptable for sched_clock().

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Probably a trivial question.I was wondering why this particular requirement exists in the first place.I looked into this commit 112f38a4a3 but couldn't gather the reason.

Quoted 3 lines

Probably a trivial question.I was wondering why this particular requirement exists in the first place.I looked into this commit 112f38a4a3 but couldn't gather the reason.

You're looking at a commit introducing an implementation. The requirement isn't driven by the implementation. It's driven by the code and the maths in the core scheduler, and its been a requirement for years.

sched_clock() needs to be monotonic, and needs to wrap at 64-bit, because calculations are done by comparing the difference of two 64-bit values returned from this function.

Let's take a trivial example - if you have a 16 bit counter, and you have a value of 0xc000 ns, and next time you read it, it has value 0x0001 ns, then what value do you end up with when you calculate the time passed using 64-bit maths.

That's 0x0000000000000001 - 0x000000000000c000. The answer is a very big number which is not the correct 16385. This means that things like process timeslice counting and scheduler fairness is compromised - I'd expect even

more so if you're running RT and this is being used to provide guarantees.

On Mon, Jun 10, 2013 at 9:08 PM, Russell King - ARM Linux <[email protected]> wrote:

Least I can do is to say "Thanks".

Quoted 9 lines · anish singh

Quoted 3 lines

Probably a trivial question.I was wondering why this particular requirement exists in the first place.I looked into this commit 112f38a4a3 but couldn't gather the reason.

You're looking at a commit introducing an implementation. The requirement isn't driven by the implementation. It's driven by the code and the maths in the core scheduler, and its been a requirement for years.

Quoted 3 lines

sched_clock() needs to be monotonic, and needs to wrap at 64-bit, because calculations are done by comparing the difference of two 64-bit values returned from this function.

Yes, and this is the question.If it is 32 bit then also it can overflow but it will happen relatively fast.So I guess that is the reason why we use 64 bit and this will avoid recalculations for recalibration.

Quoted 8 lines

Let's take a trivial example - if you have a 16 bit counter, and you have a value of 0xc000 ns, and next time you read it, it has value 0x0001 ns, then what value do you end up with when you calculate the time passed using 64-bit maths.

That's 0x0000000000000001 - 0x000000000000c000. The answer is a very big number which is not the correct 16385. This means that things like process timeslice counting and scheduler fairness is compromised - I'd expect even

So you mean when counter overflows the scheduler doesn't handle it?

This is mostly a resend of a patch series I sent a little over a month ago. I've reordered the patches so that John can pick up the first three and get a generic sched_clock layer without having to take the 64 bit patches. The last three patches add 64 bit support and move the architected timers on ARM64 and ARM to use it.

Stephen Boyd (6):
ARM: sched_clock: Remove unused needs_suspend member
ARM: sched_clock: Return suspended count earlier
sched_clock: Make ARM's sched_clock generic for all architectures
sched_clock: Add support for >32 bit sched_clock
ARM: arch_timer: Move to setup_sched_clock_64()
arm64: Move to generic sched_clock infrastructure

 arch/arm/Kconfig                                   |   1 +
 arch/arm/common/timer-sp.c                         |   2 +-
 arch/arm/kernel/Makefile                           |   2 +-
 arch/arm/kernel/arch_timer.c                       |  16 +--
 arch/arm/kernel/time.c                             |   4 +-
 arch/arm/mach-davinci/time.c                       |   2 +-
 arch/arm/mach-imx/time.c                           |   2 +-
 arch/arm/mach-integrator/integrator_ap.c           |   2 +-
 arch/arm/mach-ixp4xx/common.c                      |   2 +-
 arch/arm/mach-mmp/time.c                           |   2 +-
 arch/arm/mach-msm/timer.c                          |   2 +-
 arch/arm/mach-omap1/time.c                         |   2 +-
 arch/arm/mach-omap2/timer.c                        |   2 +-
 arch/arm/mach-pxa/time.c                           |   2 +-
 arch/arm/mach-sa1100/time.c                        |   2 +-
 arch/arm/mach-u300/timer.c                         |   2 +-
 arch/arm/plat-iop/time.c                           |   2 +-
 arch/arm/plat-omap/counter_32k.c                   |   2 +-
 arch/arm/plat-orion/time.c                         |   2 +-
 arch/arm/plat-samsung/samsung-time.c               |   2 +-
 arch/arm/plat-versatile/sched-clock.c              |   2 +-
 arch/arm64/Kconfig                                 |   1 +
 arch/arm64/kernel/time.c                           |  11 +-
 drivers/clocksource/bcm2835_timer.c                |   2 +-
 drivers/clocksource/clksrc-dbx500-prcmu.c          |   3 +-
 drivers/clocksource/dw_apb_timer_of.c              |   2 +-
 drivers/clocksource/mxs_timer.c                    |   2 +-
 drivers/clocksource/nomadik-mtu.c                  |   2 +-
 drivers/clocksource/samsung_pwm_timer.c            |   2 +-
 drivers/clocksource/tegra20_timer.c                |   2 +-
 drivers/clocksource/time-armada-370-xp.c           |   2 +-
 drivers/clocksource/timer-marco.c                  |   2 +-
 drivers/clocksource/timer-prima2.c                 |   2 +-
 .../include/asm => include/linux}/sched_clock.h    |  14 ++-
 init/Kconfig                                       |   3 +
 init/main.c                                        |   2 +
 kernel/time/Makefile                               |   1 +
 {arch/arm/kernel => kernel/time}/sched_clock.c     | 114 +++++++++++++++------
 38 files changed, 132 insertions(+), 92 deletions(-)
 rename {arch/arm/include/asm => include/linux}/sched_clock.h (62%)
 rename {arch/arm/kernel => kernel/time}/sched_clock.c (74%)

Signature · 8 lines

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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

This is mostly a resend of a patch series I sent a little over a month ago. I've reordered the patches so that John can pick up the first three and get a generic sched_clock layer without having to take the 64 bit patches. The last three patches add 64 bit support and move the architected timers on ARM64 and ARM to use it.

Quoted 5 lines · Stephen Boyd

This is mostly a resend of a patch series I sent a little over a month ago. I've reordered the patches so that John can pick up the first three and get a generic sched_clock layer without having to take the 64 bit patches. The last three patches add 64 bit support and move the architected timers on ARM64 and ARM to use it.

Yea, so from the initial look over it, I think I'm happy with queuing the first three patches, although I'd like to get some acks from arm folks on at least the first two, just so no one is surprised with it going through the -tip tree.

Quoted 7 lines · John Stultz

Quoted 5 lines · Stephen Boyd

This is mostly a resend of a patch series I sent a little over a month ago. I've reordered the patches so that John can pick up the first three and get a generic sched_clock layer without having to take the 64 bit patches. The last three patches add 64 bit support and move the architected timers on ARM64 and ARM to use it.

Quoted 4 lines

Yea, so from the initial look over it, I think I'm happy with queuing the first three patches, although I'd like to get some acks from arm folks on at least the first two, just so no one is surprised with it going through the -tip tree.

The first two patches are pretty simple so, FWIW, you can add my ack on those:

Acked-by Will Deacon <[email protected]>

Quoted 8 lines · Will Deacon

Quoted 7 lines · John Stultz

Quoted 5 lines · Stephen Boyd

This is mostly a resend of a patch series I sent a little over a month ago. I've reordered the patches so that John can pick up the first three and get a generic sched_clock layer without having to take the 64 bit patches. The last three patches add 64 bit support and move the architected timers on ARM64 and ARM to use it.

Quoted 7 lines

Quoted 4 lines

Yea, so from the initial look over it, I think I'm happy with queuing the first three patches, although I'd like to get some acks from arm folks on at least the first two, just so no one is surprised with it going through the -tip tree.

The first two patches are pretty simple so, FWIW, you can add my ack on those:

Acked-by Will Deacon <[email protected]>

Thanks! Added to the commits.

Hi John,

Quoted 12 lines · John Stultz

Quoted 11 lines · Will Deacon

Quoted 10 lines · John Stultz

Quoted 5 lines · Stephen Boyd

This is mostly a resend of a patch series I sent a little over a month ago. I've reordered the patches so that John can pick up the first three and get a generic sched_clock layer without having to take the 64 bit patches. The last three patches add 64 bit support and move the architected timers on ARM64 and ARM to use it.

Yea, so from the initial look over it, I think I'm happy with queuing the first three patches, although I'd like to get some acks from arm folks on at least the first two, just so no one is surprised with it going through the -tip tree.

Quoted 4 lines

Quoted 3 lines

The first two patches are pretty simple so, FWIW, you can add my ack on those:

Acked-by Will Deacon <[email protected]>

Thanks! Added to the commits.

What is the status of this series then? Is there a chance of seeing it in 3.11? I want to base some xtensa architecture work on this, so I'd like to know whether there is a stable base to start from.

Quoted 15 lines · Baruch Siach

Quoted 14 lines · John Stultz

Quoted 13 lines · Will Deacon

Quoted 10 lines · John Stultz

Quoted 5 lines · Stephen Boyd

This is mostly a resend of a patch series I sent a little over a month ago. I've reordered the patches so that John can pick up the first three and get a generic sched_clock layer without having to take the 64 bit patches. The last three patches add 64 bit support and move the architected timers on ARM64 and ARM to use it.

Yea, so from the initial look over it, I think I'm happy with queuing the first three patches, although I'd like to get some acks from arm folks on at least the first two, just so no one is surprised with it going through the -tip tree.

The first two patches are pretty simple so, FWIW, you can add my ack on those:

Quoted 5 lines

Quoted 2 lines

Quoted 1 line

Acked-by Will Deacon <[email protected]>

Thanks! Added to the commits.

What is the status of this series then? Is there a chance of seeing it in 3.11? I want to base some xtensa architecture work on this, so I'd like to know whether there is a stable base to start from.

I've got the first three in my internal tree, and was going to send it by Thomas for 3.11 this week.

Quoted 2 lines

to send

Quoted 1 line

it by Thomas for 3.11 this week.

Good, thanks. This means that the xtensa ccount sched_clock patch
(http://lists.linux-xtensa.org/pipermail/linux-xtensa/Week-of-Mon-20130617/001077.html)
that depends on the third patch in this series, can go in for 3.11, if the xtensa maintainer acks it (added to Cc). How should we handle the dependency then?