[PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation

[Colin Cross]

On Tue, Jun 28, 2011 at 4:46 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Tue, Jun 28, 2011 at 04:37:08PM -0700, Colin Cross wrote:
>> I don't think it affects bogomips - loops_per_jiffy can still be
>> calibrated and updated by cpufreq, udelay just wont use them.
>
> No, you can't avoid it.  __delay(), udelay(), and the global
> loops_per_jiffy are all linked together - for instance this is how
> the spinlock code has a 1s timeout:
>
> static void __spin_lock_debug(raw_spinlock_t *lock)
> {
>        u64 loops = loops_per_jiffy * HZ;
>        int print_once = 1;
>
>        for (;;) {
>                for (i = 0; i < loops; i++) {
>                        if (arch_spin_trylock(&lock->raw_lock))
>                                return;
>                        __delay(1);
>                }
>
> which goes wrong for all the same reasons you're pointing out about
> udelay().  So just restricting your argument to udelay() is not
> realistic.
>

True, there are a few other users of loops_per_jiffy and __delay, but
it looks like __spin_lock_debug is the only one worth worrying about,
and it's timing is not as critical as udelay - worst case here is that
the warning occurs after 250 ms instead of 1s.  Leaving
loops_per_jiffy and __delay intact, and fixing udelay, would still be
a net gain.