linux-mips
[Top] [All Lists]

Re: why we use multu to implement udelay

To: loody <miloody@gmail.com>
Subject: Re: why we use multu to implement udelay
From: Ralf Baechle <ralf@linux-mips.org>
Date: Mon, 2 Nov 2009 08:17:24 +0100
Cc: Linux MIPS Mailing List <linux-mips@linux-mips.org>
In-reply-to: <3a665c760911010618u7216cd68wfbd02610d2029862@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <3a665c760911010618u7216cd68wfbd02610d2029862@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.19 (2009-01-05)
On Sun, Nov 01, 2009 at 10:18:14PM +0800, loody wrote:

> If I search the right place in mip kernel, I find the kernel implement
> udelay by multu and bnez looping, in 32-bits mode.
>       if (sizeof(long) == 4)
>               __asm__("multu\t%2, %3"
>               : "=h" (usecs), "=l" (lo)
>               : "r" (usecs), "r" (lpj)
>               : GCC_REG_ACCUM);
>       else if (sizeof(long) == 8)
>               __asm__("dmultu\t%2, %3"
>               : "=h" (usecs), "=l" (lo)
>               : "r" (usecs), "r" (lpj)
>               : GCC_REG_ACCUM);
> 
>       __delay(usecs);
> why we doing so instead of using kernel timer function and the
> precision will be incorrect if the cpu runs faster or slower, right?

This is an old-fashioned implementation which will work even on systems
where no CPU timer is available or its frequency is unknown or variable.

A while ago patches were posted to use the cp0 counter instead but do
to other necessary rewrites those patches went stale, so need to be
reworked before they can be applied.  Either way, for above restrictions
the delay by looping implementation will still be needed as the fallback
implementation.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>