A few arch files won't see the definition of udelay()
in asm/delay.h anymore. Prevent that from biting us later.
Signed-off-by: Denis Vlasenko <[email protected]>
--
vda
We are going to kill MAX_UDELAY_MS, so replace it
in common code with 1. Also fix a buglet on the way:
mpc83xx_spi->nsecs > MAX_UDELAY_MS * 1000
was comparing nanoseconds to microseconds.
Signed-off-by: Denis Vlasenko <[email protected]>
--
vda
This patch does the following:
* make it so than asm/delay.h does not define udelay(),
? only __udelay(), to be used in generic udelay()
* add generic udelay() which calls __udelay() repeatedly
? as needed. Protect against overflow in udelay() argument.
* similarly for mdelay() and ssleep()
* __const_udelay for all arches is removed or renamed to
? __const_delay (it did not do microsecond delays anyway)
? if still used by arch ndelay() function/macro
* remove EXPORT_SYMBOL(__udelay). It is not used in modules
? anymore
* remove MAX_UDELAY_MS
We specifically do not touch ndelay() in these patches.
Signed-off-by: Denis Vlasenko <[email protected]>
--
vda
On Fri, Sep 22, 2006 at 10:00:33AM +0200, Denis Vlasenko wrote:
> * __const_udelay for all arches is removed or renamed to
> ? __const_delay (it did not do microsecond delays anyway)
You never explained this properly - in fact I think your logic is
reversed. Let me remind you of my reply (which afaics never got
a response):
On Wed, Aug 23, 2006 a 09:14:52AM +0100, Russell King wrote:
> On Wed, Aug 23, 2006 at 07:50:24AM +0200, Denis Vlasenko wrote:
> > On Tuesday 22 August 2006 18:55, Russell King wrote:
> > > Please keep a "const" version in ARM. Thanks.
> >
> > Are you talking about this hunk? Why do you want to keep it?
> >
> > I mean, without it udelay(n) will become slower by the time
> > needed for one extra multiply. So we will have maybe
> > udelay(n) ==> udelay(n+0.1).
>
> Why do you think that? With the constant version, the additional
> unnecessary multiply is optimised away by the compiler (since
> constant * constant = constant), so it's actually slightly faster,
> not sligntly slower as you seem to think.
>
> Since the multiply is pure overhead, it's better to get rid of it.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Friday 22 September 2006 11:36, Russell King wrote:
> On Fri, Sep 22, 2006 at 10:00:33AM +0200, Denis Vlasenko wrote:
> > * __const_udelay for all arches is removed or renamed to
> > ? __const_delay (it did not do microsecond delays anyway)
> You never explained this properly - in fact I think your logic is
> reversed.
linux-2.6.18/arch/i386/lib/delay.c:
void __udelay(unsigned long usecs)
{
__const_udelay(usecs * 0x000010c7); /* 2**32 / 1000000 (rounded up) */
}
__udelay(n) is meant to busy loop for N microseconds,
and it is easy to see from above code that
__udelay(n) == __const_udelay(n*0x10c7).
So __const_udelay(x) doesn not delay for x microseconds.
It's a bad name.
> Let me remind you of my reply (which afaics never got
> a response):
> On Wed, Aug 23, 2006 a 09:14:52AM +0100, Russell King wrote:
> > On Wed, Aug 23, 2006 at 07:50:24AM +0200, Denis Vlasenko wrote:
> > > On Tuesday 22 August 2006 18:55, Russell King wrote:
> > > > Please keep a "const" version in ARM. Thanks.
> > >
> > > Are you talking about this hunk? Why do you want to keep it?
> > >
> > > I mean, without it udelay(n) will become slower by the time
> > > needed for one extra multiply. So we will have maybe
> > > udelay(n) ==> udelay(n+0.1).
> >
> > Why do you think that? With the constant version, the additional
> > unnecessary multiply is optimised away by the compiler (since
> > constant * constant = constant), so it's actually slightly faster,
> > not sligntly slower as you seem to think.
> >
> > Since the multiply is pure overhead, it's better to get rid of it.
I did send a reply. Maybe the problem was that I removed
l-k from CC...
On Wednesday 23 August 2006 10:39, Denis Vlasenko wrote:
> > Why do you think that? With the constant version, the additional
> > unnecessary multiply is optimised away by the compiler (since
> > constant * constant = constant), so it's actually slightly faster,
> > not sligntly slower as you seem to think.
>
> We are not disagreeind. I said it wrong way. I meant
> "with this #define removed, udelay(n) will become slower...".
>
> And I am saying that it is _100% okay_ for it to become slower:
>
> > Since the multiply is pure overhead, it's better to get rid of it.
>
> You do not need to optimize delay for speed. If you
> really want to, then you can do:
>
> #define udelay(n) do {} while(0)
>
> Makes sense? No it does not. That's what I'm trying to say.
> You WANT to pause for thousands of cycles. Why you are trying
> to shave off ~10 cycles at the very same time?
>
> Hope it makes things clearer.
So, to reiterate, optimizing udelay(N) for speed makes no sense.
--
vda