[U-Boot] [RFC] Review of U-Boot timer API

[J. William Campbell]

On 5/23/2011 12:33 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4DDAA705.1040702 at 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
>