On Fri, 2010-02-19 at 16:44 +0000, Ben Hutchings wrote:
> On Fri, Feb 19, 2010 at 09:28:19AM -0600, James Bottomley wrote:
> > On Fri, 2010-02-19 at 01:56 +0000, Ben Hutchings wrote:
> > > udelay() is supposed to be limited to 1 ms, and will generate a
> > > __bad_udelay() on ARM for constant arguments > 2000. Split
> > > udelay(0x800) into mdelay(2); udelay(48). (I suspect that msleep(3)
> > > would work but I do not know how critical the timing is here.)
> >
> > So no to this one. Either ARM is right and udelay > 2000 is wrong
> > (which actually sounds correct given how long this will eat CPU for) so
> > the driver needs fixing, or ARM is wrong and the warning needs fixing.
> >
> > Splitting the delay to defeat the warning while retaining the behaviour
> > it was trying to warn about is the wrong thing to do.
>
> AIUI the restrictions on udelay() are there because the delay is likely
> to be inaccurate for large arguments. If it was actually wrong to wait
> for over a millisecond then mdelay() would not exist.
Please could you respond to the above?
Ben.
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
Attachment:
signature.asc
Description: This is a digitally signed message part
