[U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

On Thu, May 26, 2011 at 10:15 AM, J. William Campbell
<jwilliamcampbell at comcast.net> wrote:
> On 5/25/2011 4:13 PM, Graeme Russ wrote:
>>
>> Hi Wolfgang
>>
>> On Thu, May 26, 2011 at 7:16 AM, Wolfgang Denk<wd at denx.de>  wrote:
>>>
>>> Dear Graeme Russ,
>>>
>>> In message<4DDD7066.4000505 at gmail.com>  you wrote:
>>>>>

[snip]

>>>> _exactly_ what I am suggesting we do (and what does already happen on
>>>> ARM).
>>>
>>> I don't think so.
>
> Hi All,
>      Just to be clear, while ARMv7 has a 64 bit performance counter, it is
> not presently used by get_time. This is a change we want to make correct?

If it is a constant time-base then yes, that would be preferable - But I
doubt all ARM CPUs have these, so these need to be enabled on a case by
case basis - get_ticks() can then use them trivially

>>
>> On closer inspection, some do, some don't. All ARMv7 (OMAP, S5P, Tegra2)
>> do. at91 is odd - It looks like it uses interrupts, but get_timer() and
>> udelay() both end up calling get_timer_raw() (with udelay only having
>> millisecond resolution it seems).
>
> I am not sure why you say at91 appears to use interrupts. There is a comment
> in arch/arm/cpu/arm930t/at91/timer.c that says "timer without interrupts"
> (line 73). There is the same comment in
> arch/arm/cpu/arm930t/at91rm9200/timer.c Nothing in either routine refers to
> interrupts, so I would say the timer doesn't use them. I could be wrong of
> course.

You are correct

[snip]

>>  6) A 32-bit micro-second tick counter
>>       - No prescaler needed[6]
>>       - Max 'glitch free' duration is 71 minutes
>>       - ISR needed to kick prescaler if events longer than 71 minutes need
>>         to be timed
>>       - Can be used by get_timer() trivially
>
> I think this should be "Can be used by udelay and get_timer trivially"

Yes, you are again correct

Regards,

Graeme