From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Tue, 12 Jul 2011 09:36:14 +1000 Subject: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite In-Reply-To: <20110711215637.6BC6A1579E14@gemini.denx.de> References: <1309261269-4363-1-git-send-email-graeme.russ@gmail.com> <20110711215637.6BC6A1579E14@gemini.denx.de> Message-ID: <4E1B88EE.9040104@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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