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

[J. William Campbell]

On 5/27/2011 6:07 AM, Scott McNutt wrote:
> Graeme Russ wrote:
>> Hi Wolfgang
>>
>> On Friday, May 27, 2011, Wolfgang Denk <wd at denx.de> wrote:
>>> Dear Graeme Russ,
>>>
>>> In message <BANLkTik2SUm4Sm8aLjCrCmz+kcMGWgEzKw at mail.gmail.com> you 
>>> wrote:
>>>> Besides, Nios can return an increment of 10 (presumably ms) between
>>>> two immediately consecutive calls. This causes early timeouts in CFI
>>>> driver
>>> Now this in turn is a bug in the timer implementation that needs to be
>>> fixed.
>
> And this is what reset_timer() corrected.
>
>> Agreed, but that is not something I can achieve - I don't want to hold
>> up this whole show that we have all put so much effort into for the
>> sake of one weak function
>
> And I don't want to see something that currently works become broken
> because we "improved" a feature ... simply because the resolution of
> the timestamp is 10 msec rather than 1 msec.
>
> And just to be clear. This is not a Nios issue. Currently, if the
> timestamp is incremented via a fixed period interrupt, and the period
> of the interrupt is longer that 1 msec, calls to get_timer() may
> produce early timeouts ... regardless of platform.
Hi All,
     A more precise statement of the problem is that all timer delays 
may be shortened by the timer resolution. So this means that if you have 
a timeout of 1 ms in your get_time(0) {   } while ( ... < 1), then your 
actual delay may be anywhere between 0 and 1 ms. The problem arises when 
some piece of common code uses a delay of say 8 millisec, expecting the 
actual delay to be between 7 and 8. If the resolution is 10 ms, the 
delay will be between 0 and 10 ms, 0 being particularly bad. This can be 
fixed in get_timer, making the 8 ms delay  become a minimum of 10 ms at 
the expense of it becoming up to 20 ms sometimes. Since these delays are 
used mostly for error conditions, making them longer will probably be 
ok, and doesn't require changing any of the common code. It probably 
will not make things slower either, because the error timeouts should 
not be reached. The reset of the hardware timer would cause all "short" 
delays to become 10 ms. This reset approach is bad in that it prevents 
proper nesting of timing loops. However, in this case it isn't so bad, 
in that the nested loops are just extended, not shortened. Note that if 
the reset is only resetting the HARDWARE interrupt generator, not the 
actual timestamp itself, we are just extending all existing timeouts by 
0 to 10 ms.. So this just lengthens all pending timeouts. The other fix 
is in my opinion nicer, because it affects the nest loops less. If the 
inner loop is executed 100 times, with the reset, the outer loop timeout 
is extended by up to 1000 ms.

Best Regards,
Bill Campbell
>
> --Scott
>
>
>