On Wed, 2014-02-05 at 11:50 +0000, Russell King - ARM Linux wrote:
On Tue, Feb 04, 2014 at 08:36:36AM -0800, Joe Perches wrote:
quoted
On Tue, 2014-02-04 at 08:03 +0100, Holger Schurig wrote:
quoted
Joe, look in linux/arch/arm/include/asm/delay.h. The macro udelay
cannot handle large values because of lost-of-precision.
IMHO udelay on ARM is broken, because it also cannot work with fast
ARM processors (where bogomips >= 3355, which is in sight now). It's
just not broken enought that someone did something against it ... so
the current kludge is good enought.
Maybe something like this would be better?
No, the point of __bad_udelay() is that people doing stupidly large
udelay()s result in build errors,
Apparently, people just convert stupidly large udelay()s
to mdelay and not be bothered.
rather than having to run the kernel
and trip over a non-existent debugging message beacuse they haven't
built the kernel with DEBUG defined.
NAK.
<shrug>
Perhaps there should be some runtime udelay > maximum
supported check.