[U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

Hi Wolfgang,

On 25/05/11 22:26, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4DDCED75.8030906 at gmail.com> 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