[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

J. William Campbell
2011-05-27T14:16:54Z

On 5/27/2011 12:33 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4DDF2072.5090802@comcast.net> you wrote:
> ...
>> The problem is that the way we previously detected wrapping does not
>> work if the interrupt rate is == to the counter wrap time, which it
>> essentially always is. If get_ticks is trying to update the wrap count
> You ignore the fact that this is only ever a problem when the rollover
> cannot signal through an interrupt or similar. Also, some processors
> allow daisy-chaning of timers, etc.
>
> Again, I would really like to know about how many exotic systems we
> are talking that fulfil your worst-case expectations. I bet the
> overwhelming majority behaves absolutely harmless.
Hi Wolfgang,
I think that in fact the opposite is true. The problems occur if
both the main program and the interrupt routine are trying to update the
timer msb using the same code, as we were originally talking about.
There is no problem if only the interrupt routine detects the rollover.
That is the correct way to go if your interrupts work. There was nothing
particularly exotic required. It was the "normal" case. Take a look at
what would happen on the PPC is the main program was reading the
decrementer, detecting wraps and increasing the timestamp while the
interrupt routine was also incrementing the timestamp. Every so often
you get a double increment. Why were we doing this? Because I was trying
to re-use exactly the same code in the interrupt case and the
non-interrupt case. Not a good idea, in fact a bad idea as it turns out.

Best Regards,
Bill Campbell
> Best regards,
>
> Wolfgang Denk
>