Messages in this thread |  | | | Date | Fri, 22 May 1998 13:56:51 +0200 | | From | Alexander Kjeldaas <> | | Subject | Re: mdelay() implementation patch |
| |
On Fri, May 22, 1998 at 05:27:44AM +1000, Paul Gortmaker wrote: > > > > > My question is, do we: > > > > > > (a) ignore it > > > (b) when >1000, replace each occurence with: > > > {unsigned int msec = XXXX; while (--msec) udelay(1000);} > > > (c) indroduce a "mdelay()" that does (b) > > > (d) order a pizza > > > > My answer currently seems to be "all of the above". > > > > (c) would certainly make sense. > > > > Linus > > Here is a diff for (c) as (d) doesn't uuencode well. The semi > interesting bits are in <linux/delay.h> as the rest was mostly a job > for sed. With this patch, you can easily tune (on a per-architecture > basis if you want) the max. number of milliseconds udelay will be > used with (currently set to 5). Patch is against 2.1.103. >
What is the semantic difference between mdelay and udelay? I mean, why don't you just change the implementation of udelay to handle longer delays using __builtin_constant_p et al? Having both mdelay and udelay is confusing.
if you redefine the current udelay to __native_udelay for example, then instead of doing
+#define mdelay(n) (\ + (__builtin_constant_p(n) && (n)<=MAX_UDELAY_MS) ? udelay((n)*1000) : \ + ({unsigned long msec=(n); while (msec--) udelay(1000);})) you could do roughly
#define udelay(n) do { \ if (__builtin_constant_p(n) && (n)<=MAX_UDELAY_MS*1000) \ __native_udelay(n); \ else { \ unsigned long msec=(n)/1000; \ while (msec--) \ __native_udelay(1000); \ __native_udelay((n)%1000); \ } \ } while (0) and we wouldn't have two separate functions.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
|  |