[U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

From: J. William Campbell <jwilliamcampbell@comcast.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Date: Tue, 12 Jul 2011 10:27:29 -0700	[thread overview]
Message-ID: <4E1C8401.9040203@comcast.net> (raw)
In-Reply-To: <4E1C66E8.6060300@psyent.com>

On 7/12/2011 8:23 AM, Scott McNutt wrote:
> Dear Wolfgang
>
> Wolfgang Denk wrote:
>
>> What exactly is the reason that we cannot have better timer
>> resolutions in NIOS?
> You _can_ have better timer resolutions in Nios. However, there
> are legacy systems that implement timer(s) with a fixed period
> of 10 msec. The use of such implementations is very common.
> How do I know? Because my customers have such implementations.
> Why not upgrade? Because most sane engineers are loathe to
> change their rtl just so they can fix a simple software bug
> or add a simple custom feature.
>
> My obvious preference is to continue to use the latest u-boot in
> such systems ... without having to create a custom branch for
> customers with older Nios implementations, where I use the old
> timer interfaces ... simply because we "improved" the API.
>
>> Scott, maybe you can comment here?
> I have only one comment: Out of pure frustration, I have been
> avoiding any discussions regarding this timer re-write effort.
>
>> At the moment I'm trying to understand if we really have a problem on
>> NIOS2 that cannot be fixed in a way that is compatible with our
>> current plans.
> This is where my frustration begins. I've said this several times
> before, and I don't know how else to say this ... but I'll give it
> one more try:
>
>       This is not a Nios problem.
>
> If I can't use a 10 msec timer interrupt to detect a simple timeout
> condition when I'm programming a flash memory, then the timer API
> design is garbage.
Hi All,
       I agree with the idea that mandating a particular timer 
resolution is an un-desired limitation. You may need it for some cases, 
but not for all. Proof of this concept is the number of legacy UNIX 
systems running on 10 ms timer ticks, or for that matter the number of 
systems running on line cycle interrupts (16.666 ms in the US). It is 
also however true that one cannot ignore the timer resolution. That is 
what produced the problem in the first place. Asking for a delay that is 
less than the resolution isn't going to work as expected. This problem 
can be easily fixed by always adding twice the timer resolution to any 
requested delay, to ensure you waited at least two ticks , or by having 
a routine that does this for you (like the suggested API does). Right 
now, there are many places in the u-boot code that wait a certain small 
number of milliseconds under the assumption that the timer resolution is 
either 1) not an issue at all, or 2) is 1 ms. Both cases are wrong, the 
first case more so than the second. I wonder how many delays in the 
program that say "wait  5 ms" are aware that you could exit the loop 
after 4ms plus epsilon every so often, even with 1 ms resolution? 
Perhaps the tolerance is built into the number 5, perhaps not. However, 
it is surely not if the timer resolution is 16.666 ms.
>   And quite frankly, the enormous amount of
> discussion in this matter reminds me of an undergraduate science
> project.
Or any government project. But when you will effect lots of people, you 
often must kill a few trees to make sure nobody (such as yourself and 
other NIOS users) somehow gets a bad deal.

I am now returning to "real work" and will be offline for a while. Good 
Luck All.

Best Regards,
Bill Campbell
>> We also have to deal with decrementing counters, but this is just aan
>> unimportant detail.  And it appears that we actually can have this,
>> even on NIOS.
> Wow! Even on Nios! Arrggghh!
>
>> The only architecture I remember that seemed prolematic was NIOS
> Really? There have been occasional issues that have required a patch
> here and there. But I consider most of them far from "problematic."
>
> This is exhausting. As I recall, this entire fuss was born out
> of an issue with nested calls to get_timer() ... and that begat
> removing reset_timer ... and that begat ... and so on. And we're
> still spilling lots of intellectual seed here. And now we have
> what? A jack-of-all-trades API that can do everything with
> exacting precision ... other than handling a 10 msec interrupt?
>
> Best Regards,
> --Scott
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>