|
Rockbox mail archiveSubject: Re: TMS320DM320 udelay() problemRe: TMS320DM320 udelay() problem
From: Maurus Cuelenaere <mcuelenaere_at_gmail.com>
Date: Wed, 21 Dec 2011 21:40:25 +0100 "Tomasz Moń" <desowin_at_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 Received on 2011-12-21 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |