[U-Boot] [RFC] Review of U-Boot timer API

[Graeme Russ]

Hi Scott,

On Wednesday, May 25, 2011, Scott McNutt <smcnutt at psyent.com> wrote:
> Graeme Russ wrote:
>
> Hi Scott,
>
> On Wednesday, May 25, 2011, Scott McNutt <smcnutt at psyent.com> 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