On Tue, 6 Jan 2015, Catalin Marinas wrote:
> I think that's where the misunderstanding is. We don't have any idea
> how many times we go through the delay loop. We just go through the
> delay loop until the counter (driven by an independent frequency)
> changes X times. From arch/arm/lib/delay.c:
>
> static void __timer_delay(unsigned long cycles)
> {
> cycles_t start = get_cycles();
>
> while ((get_cycles() - start) < cycles)
> cpu_relax();
> }
>
> where the number of cycles is based on the pre-calculated lpj_fine
> value using the counter/timer frequency (read from DT or hardware).
>
> I think Nico already pointed out that the way we use loops_per_jiffy
> when the udelay is timer-based is probably wrong. We actually need a
> ticks_per_jiffy which has nothing to do with loops_per_jiffy, the
> former is actually completely independent from the CPU speed.
We already have the former.
The patch I posted rehabilitated thelater. That's the sanest we can do.
Then we have both a timer based delay and a bogomips that is somewhat
related to CPU speed again.
I also posted another patch to remove the 3355 bogomips limitation on
ARM.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
