[U-Boot] [PATCH] arm925t: Fix CONFIG_SYS_HZ to 1000

[Dirk Behme]

Dear Ladis,

ah, and some remarks on the patch itself ;)

Ladislav Michl wrote:
> Let CONFIG_SYS_HZ to have value of 1000 effectively fixing all users of
> get_timer.
> 
> Signed-off-by: Ladislav Michl <ladis at linux-mips.org>
> 
> diff --git a/cpu/arm925t/interrupts.c b/cpu/arm925t/interrupts.c
> index e5c77f7..a22be66 100644
> --- a/cpu/arm925t/interrupts.c
> +++ b/cpu/arm925t/interrupts.c
...
> -#define TIMER_LOAD_VAL 0xffffffff
> +#define TIMER_LOAD_VAL	0xffffffff
> +#define TIMER_CLOCK	(CONFIG_SYS_CLK_FREQ / (2 << CONFIG_SYS_PTV))

Just to get an idea of the math:

CONFIG_SYS_CLK_FREQ is 12000000 (12MHz)? This is divided by 256, so 
TIMER_CLOCK is 46875Hz? A free running 32-bit count down timer is used 
starting at 0xffffffff? Underflow (0) is reached after ~91626s == 
~25hours with this?

Please correct if something is wrong ;)

> -/* delay x useconds AND preserve advance timestamp value */
> +/* delay usec microseconds preserving timestamp value */

Hmm, 'usec microseconds' sounds somehow confusing?

>  void udelay (unsigned long usec)
>  {
...
> +	int32_t tmo = usec * (TIMER_CLOCK / 1000) / 1000;
> +	uint32_t now, last = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM);

The first '1000' should be CONFIG_SYS_HZ? I.e.

(TIMER_CLOCK / CONFIG_SYS_HZ) / 1000;

?

In my udelay patch, I use

+	tmo = usec * (TIMER_CLOCK / CONFIG_SYS_HZ);
+	tmo /= 1000;

 From some printf debugging, for OMAP3 there was a difference doing it 
in one or two lines. If I remember correctly due to integer vs 
floating point math and rounding. What do you think?

Running OMAP3 counter with 1.625MHz, max udelay resolution is ~1.62us. 
If you run with 46875Hz, you have max udelay resolution of ~22us?

> +	while (tmo > 0) {
> +		now = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM);
> +		if (last < now) /* count down timer underflow */
> +			tmo -= TIMER_LOAD_VAL - now + last;
> +		else
> +			tmo -= last - now;
> +		last = now;

I will think about this, I always need some time for this clock math ;)

In contrast to OMAP3 your timer here counts down, right? So while 
OMAP1 has to deal with underflow, OMAP3 will need overflow handling, 
right?

Best regards

Dirk