[PATCH 0/3] ARM sched_clock selection enhancements

[PATCH 0/3] ARM sched_clock selection enhancements

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

In preparation to move more timer initialization to use CLKSRC_OF and
out of the platforms, a way to select the timer used for sched_clock is
needed. This series makes the ARM sched_clock support code prefer 64-bit
counters or higher frequency counters. This is sufficient at least on
ARM Ltd boards to use the 24MHz counter rather than sp804 and to always
use the 64-bit architected timer when present. This mechanism can be
extended to DT properties if needed for any non-discoverable h/w feature.

Rob

Rob Herring (3):
  ARM: sched_clock: allow changing to higher frequency counter
  ARM: sched_clock: support 64-bit counters
  ARM: arch_timer: use the 64-bit sched_clock setup

 arch/arm/include/asm/sched_clock.h |    1 +
 arch/arm/kernel/arch_timer.c       |    8 +-------
 arch/arm/kernel/sched_clock.c      |   35 ++++++++++++++++++++++++++++++++---
 3 files changed, 34 insertions(+), 10 deletions(-)

-- 
1.7.10.4

[PATCH 1/3] ARM: sched_clock: allow changing to higher frequency counter

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

Allow multiple calls to setup_sched_clock and switch to the new counter
if it is higher frequency.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
 arch/arm/kernel/sched_clock.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index bd6f56b..040168e 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -20,6 +20,7 @@ struct clock_data {
 	u64 epoch_ns;
 	u32 epoch_cyc;
 	u32 epoch_cyc_copy;
+	unsigned long rate;
 	u32 mult;
 	u32 shift;
 	bool suspended;
@@ -113,11 +114,14 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	u64 res, wrap;
 	char r_unit;
 
+	if (cd.rate > rate)
+		return;
+
 	BUG_ON(bits > 32);
 	WARN_ON(!irqs_disabled());
-	WARN_ON(read_sched_clock != jiffy_sched_clock_read);
 	read_sched_clock = read;
 	sched_clock_mask = (1 << bits) - 1;
+	cd.rate = rate;
 
 	/* calculate the mult/shift to convert counter ticks to ns. */
 	clocks_calc_mult_shift(&cd.mult, &cd.shift, rate, NSEC_PER_SEC, 0);
-- 
1.7.10.4

[PATCH 2/3] ARM: sched_clock: support 64-bit counters

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

With architected timers, we now have 64-bit counters which can be used
directly for sched_clock. However, the ARM sched_clock code currently just
uses the lower 32-bits and handles wrapping in software. Add support for
using the full 64-bit counter values. If multiple counters are registered,
a 64-bit counter is preferred.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
 arch/arm/include/asm/sched_clock.h |    1 +
 arch/arm/kernel/sched_clock.c      |   29 +++++++++++++++++++++++++++--
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
index e3f7572..e093ea4 100644
--- a/arch/arm/include/asm/sched_clock.h
+++ b/arch/arm/include/asm/sched_clock.h
@@ -10,5 +10,6 @@
 
 extern void sched_clock_postinit(void);
 extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
+extern void setup_sched_clock_64(u64 (*read)(void), unsigned long rate);
 
 #endif
diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index 040168e..1708357 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -45,6 +45,7 @@ static u32 notrace jiffy_sched_clock_read(void)
 }
 
 static u32 __read_mostly (*read_sched_clock)(void) = jiffy_sched_clock_read;
+static u64 __read_mostly (*read_sched_clock_64)(void);
 
 static inline u64 cyc_to_ns(u64 cyc, u32 mult, u32 shift)
 {
@@ -165,14 +166,38 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate)
 	pr_debug("Registered %pF as sched_clock source\n", read);
 }
 
+void __init setup_sched_clock_64(u64 (*read)(void), unsigned long rate)
+{
+	if (cd.rate > rate)
+		return;
+
+	WARN_ON(!irqs_disabled());
+	read_sched_clock_64 = read;
+	cd.rate = rate;
+
+	/* Cache the sched_clock multiplier to save a divide in the hot path. */
+	cd.mult = NSEC_PER_SEC / rate;
+	cd.shift = 0;
+
+	/* Enable IRQ time accounting if we have a fast enough sched_clock */
+	if (irqtime > 0 || (irqtime == -1 && rate >= 1000000))
+		enable_sched_clock_irqtime();
+
+	pr_debug("Registered %pF as sched_clock source\n", read);
+}
+
 unsigned long long notrace sched_clock(void)
 {
-	u32 cyc = read_sched_clock();
-	return cyc_to_sched_clock(cyc, sched_clock_mask);
+	if (read_sched_clock_64)
+		return cyc_to_ns(read_sched_clock_64(), cd.mult, cd.shift);
+
+	return cyc_to_sched_clock(read_sched_clock(), sched_clock_mask);
 }
 
 void __init sched_clock_postinit(void)
 {
+	if (read_sched_clock_64)
+		return;
 	/*
 	 * If no sched_clock function has been provided at that point,
 	 * make it the final one one.
-- 
1.7.10.4

[PATCH 2/3] ARM: sched_clock: support 64-bit counters

[Christopher Covington]

Hi Rob,

On 03/11/2013 10:26 PM, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> With architected timers, we now have 64-bit counters which can be used
> directly for sched_clock. However, the ARM sched_clock code currently just
> uses the lower 32-bits and handles wrapping in software. Add support for
> using the full 64-bit counter values. If multiple counters are registered,
> a 64-bit counter is preferred.

To be more precise, architected timers are anywhere between 56 and 64 bits
wide, zero-extended to 64-bits. See section B8.1.1 of the ARM ARM rev C.b. I
don't know if the code really needs to change until someone has a need to
distinguish more finely between timers, but if you're using access size as an
approximation for counter width, I feel like it at least deserves a mention in
the comments.

[...]

Regards,
Christopher

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

[PATCH 2/3] ARM: sched_clock: support 64-bit counters

[Rob Herring]

On 03/21/2013 09:02 AM, Christopher Covington wrote:
> Hi Rob,
> 
> On 03/11/2013 10:26 PM, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> With architected timers, we now have 64-bit counters which can be used
>> directly for sched_clock. However, the ARM sched_clock code currently just
>> uses the lower 32-bits and handles wrapping in software. Add support for
>> using the full 64-bit counter values. If multiple counters are registered,
>> a 64-bit counter is preferred.
> 
> To be more precise, architected timers are anywhere between 56 and 64 bits
> wide, zero-extended to 64-bits. See section B8.1.1 of the ARM ARM rev C.b. I
> don't know if the code really needs to change until someone has a need to
> distinguish more finely between timers, but if you're using access size as an
> approximation for counter width, I feel like it at least deserves a mention in
> the comments.

Is there a defined way to determine the number of active bits?
setup_sched_clock could be generalized to take any sizes >32 - 64 bits,
but then we need some threshold as to when we need to worry about
wrapping or not.

Rob

[PATCH 2/3] ARM: sched_clock: support 64-bit counters

[Christopher Covington]

Hi Rob,

On 03/21/2013 06:15 PM, Rob Herring wrote:
> On 03/21/2013 09:02 AM, Christopher Covington wrote:
>> Hi Rob,
>>
>> On 03/11/2013 10:26 PM, Rob Herring wrote:
>>> From: Rob Herring <rob.herring@calxeda.com>
>>>
>>> With architected timers, we now have 64-bit counters which can be used
>>> directly for sched_clock. However, the ARM sched_clock code currently just
>>> uses the lower 32-bits and handles wrapping in software. Add support for
>>> using the full 64-bit counter values. If multiple counters are registered,
>>> a 64-bit counter is preferred.
>>
>> To be more precise, architected timers are anywhere between 56 and 64 bits
>> wide, zero-extended to 64-bits. See section B8.1.1 of the ARM ARM rev C.b. I
>> don't know if the code really needs to change until someone has a need to
>> distinguish more finely between timers, but if you're using access size as an
>> approximation for counter width, I feel like it at least deserves a mention in
>> the comments.
> 
> Is there a defined way to determine the number of active bits?
> setup_sched_clock could be generalized to take any sizes >32 - 64 bits,
> but then we need some threshold as to when we need to worry about
> wrapping or not.

An easy way isn't clear to me. As a thought experiment, one might be able to
write all ones to the CNTCV and see what sticks, or if that doesn't work,
write 56 ones, turn the timer on and see if that rolls over, and if not check
57 ones, etc. However, the write(s) are only possible using the memory-mapped
interface from the secure world while the timer is off. Perhaps the width
could be enumerated in the device tree entry.

Regards,
Christopher

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

[PATCH 2/3] ARM: sched_clock: support 64-bit counters

[Rob Herring]

On 03/22/2013 07:03 AM, Christopher Covington wrote:
> Hi Rob,
> 
> On 03/21/2013 06:15 PM, Rob Herring wrote:
>> On 03/21/2013 09:02 AM, Christopher Covington wrote:
>>> Hi Rob,
>>>
>>> On 03/11/2013 10:26 PM, Rob Herring wrote:
>>>> From: Rob Herring <rob.herring@calxeda.com>
>>>>
>>>> With architected timers, we now have 64-bit counters which can be used
>>>> directly for sched_clock. However, the ARM sched_clock code currently just
>>>> uses the lower 32-bits and handles wrapping in software. Add support for
>>>> using the full 64-bit counter values. If multiple counters are registered,
>>>> a 64-bit counter is preferred.
>>>
>>> To be more precise, architected timers are anywhere between 56 and 64 bits
>>> wide, zero-extended to 64-bits. See section B8.1.1 of the ARM ARM rev C.b. I
>>> don't know if the code really needs to change until someone has a need to
>>> distinguish more finely between timers, but if you're using access size as an
>>> approximation for counter width, I feel like it at least deserves a mention in
>>> the comments.
>>
>> Is there a defined way to determine the number of active bits?
>> setup_sched_clock could be generalized to take any sizes >32 - 64 bits,
>> but then we need some threshold as to when we need to worry about
>> wrapping or not.
> 
> An easy way isn't clear to me. As a thought experiment, one might be able to
> write all ones to the CNTCV and see what sticks, or if that doesn't work,
> write 56 ones, turn the timer on and see if that rolls over, and if not check
> 57 ones, etc. However, the write(s) are only possible using the memory-mapped
> interface from the secure world while the timer is off. Perhaps the width
> could be enumerated in the device tree entry.

The ARM ARM also says the roll-over time must be greater than 40 years.
So if you have fewer bits, then it needs to run at lower frequency. So I
think we should be fine.

Rob

[PATCH 2/3] ARM: sched_clock: support 64-bit counters

[Russell King - ARM Linux]

On Fri, Mar 22, 2013 at 07:58:39AM -0500, Rob Herring wrote:
> The ARM ARM also says the roll-over time must be greater than 40 years.
> So if you have fewer bits, then it needs to run at lower frequency. So I
> think we should be fine.

Well, we have a problem with 32-bit systems in about 19 years time when
32-bit Unix timestamps wrap.  Of course, by that time we'll all be
64-bit won't we. :)

Another issue here is whether it's likely that a system will have an
uptime of 40+ years.  Probably not.  The longest I can think of which
I have come across is the digital public address system on the London
Jubilee Line (Waterloo to Stratford section) which was specified to
have a life of 20 to 30 years... Hmm, I wonder of my Linux based system
activity logger is still in the Stratford PA racks. :)

[PATCH 2/3] ARM: sched_clock: support 64-bit counters

[Russell King - ARM Linux]

On Thu, Mar 21, 2013 at 10:02:57AM -0400, Christopher Covington wrote:
> To be more precise, architected timers are anywhere between 56 and 64 bits
> wide, zero-extended to 64-bits. See section B8.1.1 of the ARM ARM rev C.b. I
> don't know if the code really needs to change until someone has a need to
> distinguish more finely between timers, but if you're using access size as an
> approximation for counter width, I feel like it at least deserves a mention in
> the comments.

If the counter is such that it doesn't produce a full 64-bit nsec value
from sched_clock(), then it needs to be extended to 64-bit.

[PATCH 3/3] ARM: arch_timer: use the 64-bit sched_clock setup

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

Now that the ARM sched_clock code can support using 64-bit counters, call
setup_sched_clock_64 instead.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
 arch/arm/kernel/arch_timer.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index d957a51..d813ae6 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -22,11 +22,6 @@ static unsigned long arch_timer_read_counter_long(void)
 	return arch_timer_read_counter();
 }
 
-static u32 arch_timer_read_counter_u32(void)
-{
-	return arch_timer_read_counter();
-}
-
 static struct delay_timer arch_delay_timer;
 
 static void __init arch_timer_delay_timer_register(void)
@@ -55,7 +50,6 @@ int __init arch_timer_sched_clock_init(void)
 	if (arch_timer_get_rate() == 0)
 		return -ENXIO;
 
-	setup_sched_clock(arch_timer_read_counter_u32,
-			  32, arch_timer_get_rate());
+	setup_sched_clock_64(arch_timer_read_counter, arch_timer_get_rate());
 	return 0;
 }
-- 
1.7.10.4

[PATCH 0/3] ARM sched_clock selection enhancements

[Russell King - ARM Linux]

On Mon, Mar 11, 2013 at 09:26:34PM -0500, Rob Herring wrote:
> In preparation to move more timer initialization to use CLKSRC_OF and
> out of the platforms, a way to select the timer used for sched_clock is
> needed. This series makes the ARM sched_clock support code prefer 64-bit
> counters or higher frequency counters. This is sufficient at least on
> ARM Ltd boards to use the 24MHz counter rather than sp804 and to always
> use the 64-bit architected timer when present. This mechanism can be
> extended to DT properties if needed for any non-discoverable h/w feature.

No - this stuff is designed specifically to cope with the dilemas of
less-than-64-bit sched_clock sources.  If you have 64-bit sources, then
that should be dealt with differently - this code will break with 64-bit
sources due to the multiplication and shift losing the high order bits.

[PATCH 0/3] ARM sched_clock selection enhancements

[Rob Herring]

On 03/12/2013 04:23 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 11, 2013 at 09:26:34PM -0500, Rob Herring wrote:
>> In preparation to move more timer initialization to use CLKSRC_OF and
>> out of the platforms, a way to select the timer used for sched_clock is
>> needed. This series makes the ARM sched_clock support code prefer 64-bit
>> counters or higher frequency counters. This is sufficient at least on
>> ARM Ltd boards to use the 24MHz counter rather than sp804 and to always
>> use the 64-bit architected timer when present. This mechanism can be
>> extended to DT properties if needed for any non-discoverable h/w feature.
> 
> No - this stuff is designed specifically to cope with the dilemas of
> less-than-64-bit sched_clock sources.  If you have 64-bit sources, then
> that should be dealt with differently - this code will break with 64-bit
> sources due to the multiplication and shift losing the high order bits.

It is dealt with differently. In the 64-bit case, there is only a
multiply and all the code to deal with wrapping of 32-bit counters is
skipped. It is exactly the same conversion as arm64.

Rob

[PATCH 0/3] ARM sched_clock selection enhancements

[Rob Herring]

Russell,

On 03/12/2013 07:43 AM, Rob Herring wrote:
> On 03/12/2013 04:23 AM, Russell King - ARM Linux wrote:
>> On Mon, Mar 11, 2013 at 09:26:34PM -0500, Rob Herring wrote:
>>> In preparation to move more timer initialization to use CLKSRC_OF and
>>> out of the platforms, a way to select the timer used for sched_clock is
>>> needed. This series makes the ARM sched_clock support code prefer 64-bit
>>> counters or higher frequency counters. This is sufficient at least on
>>> ARM Ltd boards to use the 24MHz counter rather than sp804 and to always
>>> use the 64-bit architected timer when present. This mechanism can be
>>> extended to DT properties if needed for any non-discoverable h/w feature.
>>
>> No - this stuff is designed specifically to cope with the dilemas of
>> less-than-64-bit sched_clock sources.  If you have 64-bit sources, then
>> that should be dealt with differently - this code will break with 64-bit
>> sources due to the multiplication and shift losing the high order bits.
> 
> It is dealt with differently. In the 64-bit case, there is only a
> multiply and all the code to deal with wrapping of 32-bit counters is
> skipped. It is exactly the same conversion as arm64.

Do you have any further comments?

Rob