> > #1 udelay has to be for the worst case bus clock (6MHz) while the > > #device may be at 10Mhz or even 12MHz ISA. So it slows it down stuff > > unneccessarily- and stuff that really really is slow enough as is. > > udelay is supposed to be reliable. If someone runs a new kernel and has > no TSC (which might happen even on modern hardware or with notsc) _and_ > finds that udelay is not calibrated well enough then that's a kernel bug > we want to fix.
You miss the point entirely. The delay is in bus clocks not CPU clocks, not tsc clocks not PIT clocks, and it is permitted to vary by a factor of two. So you'll worst case halve the speed of network packet up/download even if your udelay is accurate. > > #2 Most of the ancient wind up relics with ISA bus don't have a tsc so > > their udelay value is kind of iffy. > > iffy in what way? Again, we might be hiding real udelay bugs. As you say - its only a few instructions so small udelays tend to be inaccurate - overlong. > yes, there are always risks in changing something, but using udelay is a > common-sense consolidation of code. Not for ISA bus hardware. For chipset logic, for PCI yes - for ISA stuff no. It's all about ISA clocks not wall clocks. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/