[U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

[Wolfgang Denk]

Dear "J. William Campbell",

In message <4E1CF2E0.1030702 at comcast.net> you wrote:
>
>        Yes, this is true. However, the time_elapsed_since routine can do 
> this dynamically (i.e. add twice the timer resolution) . I think you had 

That would IMHO be a very bad idea.  We have a number of places where
we have to deal with pretty long timeouts (usually because of protocol
specifications that require this - often in the order of several
seconds), where the normal path is very fast.  The typical approach is
to break the timeout into a large number of very short loops.
Sometimes we use udelay() for this, other places use get_timer().

So assume we have a timeout of 5 seconds, and implement this as 50,000
loops of 100 microseconds.  If you silently turn each of these into 20
milliseconds on NIOS, the timeout would become 1,000 seconds instead
of 5 - users would return boards as broken and report "it just
freezes" because nobody expects that it will wake up again after some
16 minutes.

> another function name (at_least) involved, but you can define 
> time_elapsed_since as always compensating for the resolution. That will 
> fix any resolution questions in a processor-specific way. It is either 
> that or the ifdefs. One way or another, the resolution must be 
> addressed. Up to now, the implicit resolution has been 1 ms, but we now 
> know that is not general enough.

It's not as simple as this.  You have to change a lot of code to make
this work for such slow clock systems.

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
Sometimes a man will tell his bartender things he'll never tell his doctor.
	-- Dr. Phillip Boyce, "The Menagerie" ("The Cage"),
	   stardate unknown.