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." - 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. Best Regards, --Scott _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
