On Sun, May 29, 2011 at 8:55 AM, Wolfgang Denk wd@denx.de wrote:
Dear Scott McNutt,
In message 4DDFA206.5050101@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@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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot