[U-Boot] arm926ejs, timer:

[Albert ARIBAUD]

Le 13/12/2010 01:27, Reinhard Meyer a écrit :
> Dear Wolfgang Denk,
>> Dear Reinhard Meyer,
>>
>> In message<4D01EA19.8070200 at emk-elektronik.de>   you wrote:
>>> Sorry for the noise, but...
>>>
>>>>>> just looked in the timer implementation for arm926ejs based boards, and
>>>>>> found that there is just the at91, davinci, nomadik timer implementation
>>>>>> fixed in actual u-boot. I want to cleanup this timers too, but
>>>>>> there are kirkwood, mb86r0x, orion5x, spear, versatile archs which use
>>>>>> a lastdec var, which is not in global_data.h defined. So the question
>>>>>> is should we add a lastdec to global_data.h or is it Ok, if I use
>>>>>> lastinc for cleaning up?
>>>>> I would suggest to take tbu, tbl, lastinc out of the AT91FAMILY #ifdef
>>>>> to the generic part.
>>>>
>>>> maybe "unify" last{inc,dec} into last_hw ? Because they are supposedly the
>>>> last (hardware) decrementer/incrementer values from the previous call.
>>>>
>>> define 4 u32's in the generic part:
>>>
>>> u32	timer_use1;
>>> u32	timer_use2;
>>> u32	timer_use3;
>>> u32	timer_use4;
>>
>> NAK.  Please let's agree on common names.  Eventually we will even
>> come up with a common implementation later (with just arch-specific
>> "accessor" routines).
>
> Replace "arch" by "SoC" here! ARM itself does not have a timer (in contrast to
> powerpc where tbu,tbl is part of the architecture) !
>
> Then its a bad idea to take tbu,tbl out of the #ifdef AT91FAMILY part
> when all other ARM timer implementations do not use tbu.
>
> Its simple to NAK attempts to come up with "common" names that are NOT
> misnomers on some implementations... tbu, tbl are certainly misnomers on all
> non AT91 timer implementations...

I think Wolfgang NAK'ed the idea of *complete* misnomers; 
timer_use{1,2,3,4} are good for cross-board unicity but bad for 
readability and maintenability -- you'd need to re-#define their names 
for each arch, or SoC, or even maybe for some boards.

What we need, IIUC, is a (group of) field(s) that will provide a 
monotonous value of the time elapsed  computed from the HW timer devoted 
to this use and name that accordingly.

My understanding is that there will be a need for at least one field for 
storing the last hardware time as directly read from the timer, because 
we'll need it to detect overruns if the timer alone does not provide the 
range that we require, and one other field for the 'more significant 
part' which is basically carried over through HW value overrun detection.

One could argue that only one field could be necessary, the lower bits 
of which would be the HW timer reads and the higher bits being fed from 
the overrun, but managing bitfieds would complicate the issue, plus 
maybe not all timers are free-running full-range powers of two?

Also, as for the size, there does not seem to be a consensus, but maybe 
we can choose 64 bits (and create such a type if necessary) for each and 
then SoCs or arches will cast that as necessary of 64-bit arithmetic is 
a problem. Or we can do a union, with 64 and 32 bit variants.

So, what about:

u64	timer_hw_reading;
u64	timer_sw_carry_over;

> Reinhard

Amicalement,
-- 
Albert.