From mboxrd@z Thu Jan 1 00:00:00 1970 From: J. William Campbell Date: Mon, 23 May 2011 13:26:29 -0700 Subject: [U-Boot] [RFC] Review of U-Boot timer API In-Reply-To: <20110523193305.D2C461499BF9@gemini.denx.de> References: <4DD7B245.5000008@gmail.com> <4DD8908E.7040501@emk-elektronik.de> <4DD8ABD3.2070506@gmail.com> <4DD8B993.3010704@comcast.net> <4DD8C639.30200@emk-elektronik.de> <4DD9A6F7.1040509@comcast.net> <4DD9B608.7080307@comcast.net> <20110523120912.493E01499BF6@gemini.denx.de> <4DDA5334.4060308@gmail.com> <20110523131959.9256D1499BF6@gemini.denx.de> <4DDAA705.1040702@comcast.net> <20110523193305.D2C461499BF9@gemini.denx.de> Message-ID: <4DDAC2F5.7060202@comcast.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 5/23/2011 12:33 PM, Wolfgang Denk wrote: > Dear "J. William Campbell", > > In message<4DDAA705.1040702@comcast.net> you wrote: >> My apologies for being a little (perhaps more than a little) >> dense. As they say, "after further review", I think the key aspect of >> the PPC timer system is that it uses the decrementer register to >> generate an interrupt at a 1 KHz rate. What I have been attempting here >> is to produce a timer system that does not use interrupts at all. This >> is a fundamental design question. Naturally, systems that can generate > No, it is not. It is an implementation detail which is irrelevant to > almost all users of U-Boot. > > Or do you actucally care if your UART driver uses polling or > interrupts? Hi All, I might care a lot if I expect typeahead to work, or if I am sending a command script via a terminal emulator and I don't want to loose characters while u-boot is off executing a command. One might (correctly) say that that is too much to expect of a boot loader, and define polling as "good enough", which I advocate, or not. YMMV. >> an interrupt at a 1 KHz rate (or at any (reasonable) higher rate for >> that matter) using the decrementer register can produce a 1 ms >> resolution software counter that updates "by magic". If my understanding >> of this PPC code is incorrect, somebody please stop me before I make a >> further fool of myself! Is it then a design requirement that the timer >> system use interrupts? Is that what is meant by using the PPC system as > No, it is not a design requirement. It is just one possible > implementation. Any other method that achieves the same or similar > results is as good. As noted before, on PowerPC we could have > probably avoided this and just base all timer services on the timebase > register. > > [The reason for this dual implementation is historical. When I wrote > this code, I did not know if we would ever need any fancy timer- > controlled callbacks or similar. And I needed to implement interrupt > handling for a few other purposes (for example for use in standalone > applications; this was an explicit requirement at that time). And the > timer was something that made a good and simple example.] > >> a model? If so, is it possible/reasonable on all the u-boots that are >> out there to generate and process timer interrupts at some (hopefully >> but not necessarily) programmable rate? > I consider this an implementation detail. On all architectures it > should be possible to use interrupts, so if the hardware supports a > timer that can generate interrupts it should be possible to use this. > But it is not a requirement that all implementations must work like Ok, this is very nice to understand. I will attempt to summarize what I think this email and the previous one means. First, the required properties of the get_timer routine. 1. It must have 1 millisecond resolution and accuracy (more or less). For instance, the old NIOS timer that incremented the timestamp by 10 every 10 milliseconds in response to an interrupt is not compliant. 2. The get_timer routine must have full period accuracy without any assumptions regarding what is going on in u-boot. This period is 4294967 seconds or so. I then suggest that the minimum system requirements to support the u-boot timer are as follows: * Either there exists a free-running timer whose period is > 4294967 and whose resolution is 1 millisecond or better. This probably includes all 64 bit timestamp counters. * Or there exists a method of generating interrupts at a known rate of 1 millisecond or faster. This is a superset of the current PPC method. * Or there exists a method of generating interrupts at a known fixed rate slower than once a millisecond AND there exists a readable free running counter whose period is longer or the same as the interrupt rate AND whose resolution is at least 1 ms. This would include N bit counters that generate an interrupt when they overflow, or some long timestamp counter with another, possibly unrelated interrupt generating methodology that is faster than the counter overflow interval. There are many systems that are able to do all three cases, or two of three, so they have a choice on how to implement get_timer(). I claim that these are sufficient conditions. I also claim they are necessary. If a hardware system does not meet these criteria, I claim it can't meet the get_timer requirements. Do such systems exist today that use u-boot? I think probably so, but maybe they are corner cases. Note that you cannot extend a 32 bit counter to a 64 bit counter reliably without using interrupts to do so when get_timer is not being called. Systems using the first approach above have essentially all their logic in the get_timer routine, but MUST use at least some 64 bit arithmetic (actually 33 bit arithmetic if you don't count shifts) to do so because the delta time between calls can be very large. The routine is not too complex to write however. Systems using the second approach have a real simple get_timer routine but a more complex interrupt routine. The interrupt routine is still quite simple, it being either a single 32 bit add or 2 32 bit adds (if the update rate is a fraction of a ms). Systems using the last approach are the most complex. They need a routine like the get_timer routine I provided yesterday that can be called in the interrupt routine to kick the timer up to present day, plus a version of the routine called by the user that disables interrupts, updates the timestamp, and re-enables interrupts. Are there any such systems out there? Probably, but I will wait for someone to identify them before I dive in! Certainly the other two methods are much easier to create. Does that sound right? Best Regards, Bill Campbell > this. > > Best regards, > > Wolfgang Denk >