Hi Scott, On Wednesday, May 25, 2011, Scott McNutt <[email protected]> wrote: > Graeme Russ wrote: > > Hi Scott, > > On Wednesday, May 25, 2011, Scott McNutt <[email protected]> wrote: > > Graeme Russ wrote: > > Hi Scott, > > On 25/05/11 22:36, Scott McNutt wrote: > > Graeme Russ wrote: > > OK, let's wind back - My original suggestion made no claim towards changing > what the API is used for, or how it looks to those who use it (for all > practical intents and purposes). I suggested: > - Removing set_timer() and reset_timer() > - Implement get_timer() as a platform independent function > > Why do you suggest removing set_timer() and reset_timer() ? > > > > Because if the timer API is done right, they are not needed > > > To continue the wind back ... > > In several implementations, reset_timer() actually reloads > or re-initializes the hardware timer. This has the effect of > synchronizing get_timer() calls with subsequent interrupts. > This prevents the early timeouts if the implementer chooses > to use an interrupt rate less than 1 ms. > > So my original question was, how do we address this issue? > > > We fix them dear Liza dear Liza ;) > > That is what this thread is trying to figure out > > > I'm getting a bit frustrated here as I can see we're going > in circles. So I'll just make a few statements a leave well > enough alone. > > - I'm not convinced that reset_timer() and set_timer() should be > removed simply because you state that "if the timer API is done > right, they are not needed."
Sorry, I should have been more specific - get and reset break nested loops. Some implementations (mostly ARM) also do a silent reset in udelay(), which breaks loops containing udelay. > > - If an implementation can't use interrupts that occur less > frequently than 1 msec to satisfy the prevailing use of > get_timer(), without breaking existing capability, I consider > the interface that "is done right" to be wrong. > Sorry, I don't understand what you mean here I hope to get an implementation agreed upon that does not require interrupts at all, provided a tick counter with sufficiently long roll over time is available (longer than the maximum expected period between 'related' get_timer() calls, for example calls to get_timer() in a timeout testing while loop). This 'bare minimum' implementation can be optionally augmented with an ISR which kicks the timer calculation in the background (typically by just calling get_timer()) It really is quite simple in the end. Regards, Graeme _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
