Re: PATCH: __bad_udelay fixes(?) for linux-2.4.0-prerelease

[Alan Cox]

> (that is, 20 milliseconds).  I guess the purpose of this change is
> to tell driver maintainers to either take a harder look at whether they
> really need to do a busy sleep for that long (you can still do it with

It is primarily there because udelay() that long will fail. An mdelay is
an acceptable substitution. mdelay knows the delays will be bigger so the
time to do the math and a loop doesnt throw small delays

> drivers/video/atyfb.c           - An intentional 50ms delay.
> drivers/video/clgenfb.c	        - An intentional 100ms delay.
> 				  I've changed both files to keep the
> 				  delays by using mdelay instead of udelay.
> 				  Perhaps somebody could check the
> 				  approaprirate documentation and test
> 				  on real hardware to determine if the
> 				  delays really need to be this long.

Seems sane. For toshoboe in my tree I just switched it to mdelay()