From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott McNutt Date: Tue, 12 Jul 2011 11:23:20 -0400 Subject: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite In-Reply-To: <20110712131042.74D0D16F7669@gemini.denx.de> References: <1309261269-4363-1-git-send-email-graeme.russ@gmail.com> <20110711215637.6BC6A1579E14@gemini.denx.de> <4E1B7E0C.8000900@gmail.com> <4E1B88EE.9040104@gmail.com> <4E1BAED7.3070009@gmail.com> <20110712084954.C928C16F7669@gemini.denx.de> <4E1C23B8.6020101@gmail.com> <20110712131042.74D0D16F7669@gemini.denx.de> Message-ID: <4E1C66E8.6060300@psyent.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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. And quite frankly, the enormous amount of discussion in this matter reminds me of an undergraduate science project. > 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