[U-Boot] arm926ejs, timer:

[U-Boot] arm926ejs, timer:

[Heiko Schocher]

Hello,

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?

Or are there pending patches, which fix this issues for some (all)
arm926ejs architectures?

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] arm926ejs, timer:

[Reinhard Meyer]

Dear Heiko Schocher,
> Hello,
> 
> 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.

> 
> Or are there pending patches, which fix this issues for some (all)
> arm926ejs architectures?
at91 timer is still not perfect, it will break after 2**64 ticks. That is well
after the end of the Solar System :)

Best Regards,
Reinhard

[U-Boot] arm926ejs, timer:

[Reinhard Meyer]

Reinhard Meyer schrieb:
> Dear Heiko Schocher,
>> Hello,
>>
>> 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.

> 
>> Or are there pending patches, which fix this issues for some (all)
>> arm926ejs architectures?
> at91 timer is still not perfect, it will break after 2**64 ticks. That is well
> after the end of the Solar System :)

[U-Boot] arm926ejs, timer:

[Reinhard Meyer]

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;

and have the timer implementations themselves use defines to make them more readable.

#define lastinc gd->timer_use1

A future AT91 timer might not use tbu/tbl, but would need 4 values to keep track
of 2 independant timers for udelay() and a 1kHz base for *_timer().

Reinhard

[U-Boot] arm926ejs, timer:

[Heiko Schocher]

Hello Reinhard,

Reinhard Meyer 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.

Thats already done ;-)

>> 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;
> 
> and have the timer implementations themselves use defines to make them more readable.
> 
> #define lastinc gd->timer_use1

Yep, that would be a good idea, but that will break again all arm
boards, so I have to fixup all timer.c implementations ... in the
first step, I think, I do a

#define lastinc gd->lastdec

for the arm926ejs boards which use lastinc ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] arm926ejs, timer:

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4D01EA19.8070200@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).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As far as the laws of mathematics refer  to  reality,  they  are  not
certain;  and  as  far  as  they  are  certain,  they do not refer to
reality.                                           -- Albert Einstein

[U-Boot] arm926ejs, timer:

[Reinhard Meyer]

Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message<4D01EA19.8070200@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...

Reinhard

[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@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.

[U-Boot] arm926ejs, timer:

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4D05687F.9090100@emk-elektronik.de> you wrote:
>
> > 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...

Maybe we should lean back and have a look at what Linux is doing in
this area?

The recent patch series "64-bit sched_clock" on the lak ML seems to
fit pretty well :-)

See http://thread.gmane.org/gmane.linux.ports.arm.kernel/99740


Can we copy from Linux?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
... The things love can drive a man to -- the  ecstasies,  the  mise-
ries,  the broken rules, the desperate chances, the glorious failures
and the glorious victories.
	-- McCoy, "Requiem for Methuselah", stardate 5843.7

[U-Boot] arm926ejs, timer:

[Nick Thompson]

On 10/12/10 08:16, Heiko Schocher wrote:
> Hello,
> 
> 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?
> 
> Or are there pending patches, which fix this issues for some (all)
> arm926ejs architectures?

There is an outstanding patch for davinci:

http://patchwork.ozlabs.org/patch/74860/

Nick.