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

[J. William Campbell]

On 5/27/2011 8:44 AM, Scott McNutt wrote:
> J. William Campbell wrote:
>> 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.
> <snip>
>> 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.
>
> Ok. Now I get it. Thanks.
>
> <snip>
>> This reset approach is bad in that it prevents proper nesting of 
>> timing loops.
>
> In my particular case, because reset_timer() resets the timestamp
> to zero rather than simply restarting the timer. I believe leaving
> the timestamp alone would solve the nesting problem.
>
> <snip>
>> 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.
>
> Bill, thank you for explaining -- probably for the nth time -- but it
> did finally sink in.
Hi Scott,
      Glad to help, I finally think I understand it myself in looking 
into it further! I think we have a good way ahead that should keep 
everything working. We will get you an alpha copy of whatever we do as 
soon as possible so you can verify we didn't break nios2!
Best Regards,
Bill Campbell
>
> Regards,
> --Scott
>
>