On 23/05/11 22:09, Wolfgang Denk wrote: > Dear Graeme Russ, > > sorry for jumping in late here (was busy with the ELDK 5.0 release).
I thought you were a bit quite on such a 'touchy' subject ;) > > In message <banlktimqgpnsbrsf1hwmjjaamxv3m_k...@mail.gmail.com> you wrote: >> OK, so in summary, we can (in theory) have: >> - A timer API in /lib/ with a single u32 get_timer(u32 base) function >> - A HAL with two functions >> - u32 get_raw_ticks() > > What des this provide? > >> - u32 get_raw_tick_rate() which returns the tick rate in kHz (which >> max's out at just after 4GHz) > > Can we please omit the _raw part in these names? > >> - 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 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 so that if the architecture can provide a free running 1ms counter, there is no (code size) penalty 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. >> - If the hardware supports a native 32-bit ms counter, get_raw_ms() >> can be overridden to simply return the hardware counter. In this case, >> get_raw_ticks() would return 1 > > I don't think this is possible on may systems, so I doubt if this is > auseful approach. x86 does as it implements a 1ms interrupt (I know other systems do as well) >> - 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 over the time period you are measuring (i.e. two independent 5s delays 2 hours apart will not be a problem) Kicking the pre-scaler (like kicking the watchdog) eliminates the problem entirely. > >> - 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? >> - An optional HAL function u32 get_raw_us() which can be used for >> performance profiling (must wrap correctly) > > Sorry for rewinding the thread. > > 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 > 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 Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
