Hi Wolfgang, On 25/05/11 22:26, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <[email protected]> you wrote: >> >>>>> I don't get you. In such a system, the interrupt would be the tick >>>>> (see the PPC implementation). If you miss interrupts, you miss ticks. > ... >>> The "tick counter" is already in the higher level, i. e. implemented >>> in software, without any hardware based registers. > ... > >> Now every time get_timer() is called, the prescaler updates the timer from >> the current tick count - This cannot fail if interrupts are inadvertently >> disabled. > > Arghh... But in this szenario, if interrupts are disabled, then the > ISR will not run, so the tick count will not be incremented BECAUSE > THE TICK COUNTER IS A VARIABLE THAT GETS INCREMENTED BY ONE EACH TIME > THE ISR RUNS. So your prescaler will read a constant value. > > Sorry for shouting, but I feel either you are not listening to me or I > cannot make myself understood to you.
What you are saying is 100% correct - For PPC. Now please - step back from PPC for a minute Many platforms have a hardware counter which is incremented without assistance from software - not by an ISR, nothing (I mentioned this before, but I can't track down the exact email) - THIS is the tick counter returned by get_ticks() which the prescaler uses to update the timer when you either: - Explicitly call get_timer() - Call the prescaler from an ISR The thing is, I have now highlighted that relying on interrupts to keep get_timer() working is a really bad idea - We have no way of stopping anyone from calling disable_interrupts() before using the timer The suggested architecture makes ISR servicing of the timer 'nice' for long delays where the tick counter might wrap and 'always works' for timeout loops which repeatedly call get_timer() Regards, Graeme _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
