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

[Simon Glass]

On Sun, May 29, 2011 at 8:55 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Scott McNutt,
>
> In message <4DDFA206.5050101 at psyent.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
> ...
>> And this is what reset_timer() corrected.
>
> I cannot see how reset_timer() could ever correct the bug that two
> seuccessive calls to get_timer() return an delta of 10 milliseconds?
>
>> > 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.
>
> We agree on that.  Yet, an implementation with a  resolution of 10
> milliseconds must only return a new values (incremented by ten
> missiseconds) after (at least) 10 milliseconds have passed.

Hi Wolfgang,

Sure if you are tracking the timer, and wait for it to increment, and
then wait for it to increment a second time, you can be confident that
the time between the first and second increments is 10ms.

But in general it is possible that your first read of the timer
happens at 9.999ms after the timer last incremented, just because you
are unlucky. Then perhaps two successive reads of the timer only 1us
apart will see a difference of 10ms in time.

I believe this resolution problem could/should be solved by a function
which returns a time not less than n ms in the future. It would work
by returning something like current_time_ms + (delay_ms +
resolution_ms * 2 - 1) / resolution_ms * resolution_ms, where
resolution_ms is 10 in this case. I think someone else mentioned that
too.

When the timer reaches that time then it is guaranteed that at least
delay_ms ms has passed, although it might be up to delay_ms + 10.

Regards,
Simon

>
> What I've been told is that this condition is violated in the code,
> which would be a bug that needs to be fixed.
>
>> 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.
>
> Please point out which other implementations show this problem, too,
> so we can fix these as well.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Q:  How many DEC repairman does it take to fix a flat?
> A:  Five; four to hold the car up and one to swap tires.
> Q:  How long does it take?
> A:  It's indeterminate.  It will depend upon how many flats they've
>    brought with them.
> Q:  What happens if you've got TWO flats?
> A:  They replace your generator.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>