On Tue, Jun 28, 2011 at 4:46 PM, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
