[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 at 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