[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

Wolfgang Denk
2011-05-30T12:31:44Z

Dear Graeme Russ,

In message <4DE383D3.7020008@gmail.com> you wrote:
>
> Some platforms are _way_ worse than this - I am sure I have seen a udelay()
> done with the millisecond time - So udelay(100) could be closer to
> udelay(1000) - So your above 5 second delay could take as long as 50 seconds!!!

That should show up quickly as soon as you run a "sleep 5" command on
the console (which is implemented like that).

> > while (test_for_event() == 0) {
> > now = get_timer(0);
> > if ((now - start) > timeout)
> > handle_timeout();
> >
> > udelay(100);
> > }
> >
> > Here the loop overhead caused by short delay which may result in a
> > high number of calls to test_for_event() gets eliminated because
> > the time reference is independet of the delay.
>
> I personally think _any_ timeout greater than 1s (maybe even >500ms) should
> be done this way

Agreed. As soon as the timeout is >> the interval size of the
underlying timer service this is the best we can do.

> > start = get_timer(0);
> >
> > do_something_complicated();
> >
> > now = get_timer(0);
> >
> > printf("execution time: %ld millisec\n", now - start);
>
> Currently fails spectacularly if do_something_complicated() involves a
> delay loop which calls reset_timer()

Note that I (intentionally) always used argument 0 in the calls to
get_timer(). I think we really should get rid of this argument.

> I think this may become more popular for performance tuning once the API
> has been established. The desire for boot profiling was what initially made
> me investigate the API given the current use of reset_timer() prohibits
> profiling across a timeout loop.

Agreed.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I find this a nice feature but it is not according to the documen-
tation. Or is it a BUG?" "Let's call it an accidental feature. :-)"
- Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>