"Tomasz Moń" <deso...@gmail.com> schreef:
>Recently (r31376) I have commited changes that made udelay() for
>TMS320DM320 pretty precise. However nasty bug was discovered later
>that would cause the udelay() to never return when interrupts are
>disabled. This problem was resolved in r31394, although a new issue
>arises.
>
>Current udelay() implementation can exit before specified time if
>called with interrupts disabled. This can happen if TIMER1 interrupt
>goes into active state before values count gets loaded with
>IO_TIMER1_TMCNT.
>
>One crude way to make sure the udelay() won't finish before specified
>amount of time is to explicitly clear the TIMER1 interrupt state. In
>worst case that would make the delay take one tick longer than
>expected.
>
>Are there any other suggestions how to deal with that corner case?
>Is having this crude fix actually better than letting the udelay()
>exit before expected?
>
>I think in general, having to wait a bit longer in special cases is
>reasonable trade-off which shouldn't cause problems.
I agree. As a comparison, IIRC Linux has defined {u,m}delay() as "waits for the
specified amount of time or longer, but NEVER less".
--
Maurus Cuelenaere
