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

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

Le 13/12/2010 01:27, Reinhard Meyer a écrit :

Dear Wolfgang Denk,

...

Dear Reinhard Meyer,

In message4D01EA19.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,