From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Tue, 24 May 2011 06:48:36 +1000 Subject: [U-Boot] [RFC] Review of U-Boot timer API In-Reply-To: <20110523131959.9256D1499BF6@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> Message-ID: <4DDAC824.7050705@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 23/05/11 23:19, Wolfgang Denk wrote: > Dear Graeme Russ, > > In message <4DDA5334.4060308@gmail.com> you wrote: >> >>>> - A helper function in /lib/ u32 get_raw_ms() which uses get_raw_ticks() >>>> and get_tick_rate() to correctly maintain the ms counter used by >>>> get_timer() - This function can be weak (so next point) >>> >>> Ditto. What would that do? If it gets milliseconds as the name >>> suggest, that's already the function needed for get_timer()? >> >> OK, there appears to be a consensus that not all hardware actually supports >> a free-running timer with 1ms resolution. To overcome this, the idea is to > > Indeed. I guess most of them do not. > >> create a common library function which maintains the free running counter. >> The library function acts as a pre-scaler using a 'raw tick counter' and a >> 'raw tick rate' supplied by the low level architecture. We define this weak > > What are "raw" ticks? And what are "cooked" ticks, then? > We never talked about cooked tick - I agree 'raw' is superfluous >> so that if the architecture can provide a free running 1ms counter, there >> is no (code size) penalty > > Why do we need a free running 1ms counter at all? Any free running > counter of at least millisecoind resolution should be good enough. > Because it get_timer() is 1ms - Yes, get_timer() can calculate it from a higher resolution source, but that creates multiple implementations of the pre-scaler of multiple arches - The goal is to reduce code duplication here. get_timer() calls get_raw_ms() (ok, we could just call that get_ms) which is a common library routine which does the pre-scaling. Arches which can maintain this 1ms counter (via interrupts or native hardware counters for example) don't need it. >> This approach eliminates all the existing per-arch code which (attempts) to >> manage the time base behind get time. So we simplify each arch down to it's >> bare essentials - Provide a counter which increments at a natural fixed >> rate and what the rate is - Let common library code deal with the rest. > > Did you have a look at the PowerPC implementation? I'd like to see > this used as reference. > >>>> - Calling of get_raw_ticks() regularly in the main loop (how ofter will >>>> depend on the raw tick rate, but I image it will never be necessary >>>> to call more often than once every few minutes) >>> >>> NAK. This concept is fundamentally broken. I will not accept it. >> >> Some existing timers are fundamentally broken - The glitch at the >> 0xffffffff to 0x00000000 rollover or rollover early - The method discussed >> in this thread eliminates all such glitches. Provided pre-scaler in /lib/ >> (triggered by get_timer() usually) is called often enough (71 minutes for a >> 32-bit 1MHz counter) then there is no need. Even then, it is only important > > We already have this nightmare of code for triggering the watchdog on > systems that use it. > > Assuming there are places in the main loop that get executed often > enough is a broken concept, and I will not accept any such code. > >> over the time period you are measuring (i.e. two independent 5s delays 2 >> hours apart will not be a problem) > > What is the practical purpose of get_timer()? What is the longest > interval we have to cover? And what is the problem with a rollover? > >>>> - If the hardware implements a native 32-bit 1ms counter, no call in >>>> the main loop is required >>> >>> We should make no such requirements. >> >> No such requirement of what? > > Of making any calls in the main loop. > >>> Can we not start simple, say by a plain free-runnign 64 bit counter, >>> be it implemented in hardwar eor in software? On PowerPC, we have >> >> That's exactly what we are suggesting - Let the hardware be free to >> implement the counter at whatever frequency suits it. 64-bit is not needed >> in reality > > It may not be needed on some systems, but may be needed on others > where 32 bit is too short. Let's use the common base that is know to > work on all systems, even if it's not strictly needed on all of them. > >>> this immediately in form of the time base register (or more precisely >>> in form of the two 32 bit registers tbu and tbl representing time base >>> upper and time base lower). >>> >>> Modelling a similar interface using _any_ kind of timer service should >>> be trivial. And from there, we can just use the existing code again. >> >> Yes, have the library function manage the actual '1ms' aspect > > This is what PPC is doing. And I understand that Reinhard did the same > in software for AT91. Yes, duplicate code - lets 'libify' it Regards, Graeme