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

[Graeme Russ <graeme.russ@gmail.com>]

On 12/07/11 07:56, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 

[snip]

> One thing I always wanted to do in the previous discussion was to check
> what other projects (like Linux, barebox, etc.) are doing in this area.
> I think it is worth reading the Linux Documentation/timers/highres.txt
> document, especially the sections about John Stultz's Generic Time Of
> Day (GTOD) framework, please the documents linked there (i. e. the OLS
> slides [the link in Documentation/timers/highres.txt is stale; use
> http://www.kernel.org/pub/linux/kernel/people/tglx/hrtimers/ols2006-hrtimers.pdf
> instead] and the paper "We Are Not Getting Any Younger: A New Approach
> to Time and Timers" by J. Stultz et al. in
> http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf p. 219ff).
> 
> Having this still in mind, I took a look across the fence to what
> barebox is doing.  Guess what?  From "common/clock.c":
> 
> 	 * clock.c - generic clocksource implementation
> 	 *
> 	 * This file contains the clocksource implementation from the Linux
> 	 * kernel originally by John Stultz
> 
> OK.  Message received.

Yes, and barebox is also pulling in slabs of other Linux code such as
driver framework etc. I think you will find barebox will ultimately have a
very large code-base and binary image because of that. I think that U-Boot
and barebox are heading in two different directions (and so they should,
what would be the point otherwise) - barebox will become modular but
larger, U-Boot will continue to be homogeneous and small.

> What I'm asking myself (and now you) is: Should we really re-invent
> the wheel again?

OK, I've now had a brief look and I have the following comments:

- Looking at the low-level framework described in ols2006-hrtimers.pdf
(Linux API), we are looking at implementing the same thing - An
architecture specific free running, high speed, high resolution, high
accuracy hardware counter/timer and a low speed interrupt which translates
the hardware counter/timer to a common API. In this respect, we are not
re-inventing that wheel at all

- The rest of the Linux API is like hitting a thumb-tack with a
sledgehammer - Timer Queues, NTP, Callbacks, Scheduling etc, etc, etc. We
only want to do two things:

  1. Monitor timeouts
  2. Calculate code execution time (and even then, not everyone all the
     time)

- The Linux API is nanosecond resolution. We are hard pressed to get the
average hardware to support microsecond resolution

- The Linux API includes usage of 'clock events' - These are timer
interrupts driven by programmable hardware and relieve the stress on the
timer scheduler keeping track of every single timer - Overkill for a boot
loader

- The Linux API includes 'Time of Day' (Wall Time) - Again, I don't think
we really need this in a boot loader (we have an RTC API we can use if we
want to get the current Date and Time).

So, all we need is a fixed resolution free running timer we can use to do
simple (one at a time) timing operations. No callbacks, no scheduling, to
'Wall Time', no 'Clock Events', no NTP etc. The Linux API is 'Too Big'

I don't think we are re-inventing the wheel with our underlying concept -
Use a hardware counter to handle the accuracy and resolution and use a less
frequent interrupt to map the hardware implementation to a common software
API. In U-Boot, the interrupt can be as simple as the actual call into the
API, but where the hardware timer does not have sufficient resolution (a
32-bit nanosecond timer of 16-bit millisecond timer for example) an
additional hardware interrupt will be required.

I personally think we are headed in the right direction 'for U-Boot' -
small, tight, elegant, and fit-for-purpose

Regards,

Graeme