Subject: [PATCH 3/4] ARM: sched_clock: Add support for >32 bit sched_clock

From: [email-masked] (Stephen Boyd)
Date: Mon, 22 Apr 2013 08:35:42 -0700

On 04/22/13 03:48, Will Deacon wrote:
> Hi Stephen,
>
> On Sat, Apr 20, 2013 at 01:29:05AM +0100, Stephen Boyd wrote:
>> The arm architected system counter has at least 56 bits of
>> useable bits. Add support to ARM's sched_clock implementation for
>> counters with more than 32 bits so we can avoid the complexity of
>> dealing with wraparound on these devices while benefiting from
>> the irqtime accounting and suspend/resume handling that the ARM
>> sched_clock code already has.
>>
>> Signed-off-by: Stephen Boyd <[email-masked]>
>> ---
>>
>> Maybe we need a union for the epoch_ns usage?
>>
>>  arch/arm/include/asm/sched_clock.h |   2 +
>>  arch/arm/kernel/sched_clock.c      | 101 +++++++++++++++++++++++++++----------
>>  2 files changed, 77 insertions(+), 26 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/sched_clock.h b/arch/arm/include/asm/sched_clock.h
>> index 3d520dd..7fcd2ee 100644
>> --- a/arch/arm/include/asm/sched_clock.h
>> +++ b/arch/arm/include/asm/sched_clock.h
>> @@ -13,4 +13,6 @@ extern void setup_sched_clock(u32 (*read)(void), int bits, unsigned long rate);
>>  
>>  extern unsigned long long (*sched_clock_func)(void);
>>  
>> +extern void setup_sched_clock_64(u64 (*read)(void), int bits,
>> +				 unsigned long rate);
> Curious, but why do we need two setup_sched_clock functions, where the bits
> are passed as a parameter? Can't we just do the right thing if the clock
> claims to be more than 32 bits wide (and get rid of the BUG_ONs at the same
> time)?

This is to avoid having to change a bunch of code that is using
setup_sched_clock() already where their read function returns a u32
instead of a u64. I suppose we could make the 64 bit version fall back
to the 32 bit version if the bits aren't large enough and provide some
sort of u32 wrapper function around the u64 callback. It may also be
useful if we can determine that the timer wraps too quickly even when
there are more than 32 bits.

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