[U-Boot-Users] CFG_HZ and get_timer() issue

[Shawn]

Wolfgang,

> > Flash write gets stuck in while loop if there is a real problem. It
> > may be other factor(s) that cause this problem. For example, timer is
> > not accurate?
> 
> This is one  possible  explanation.  Check  timer  implementation.  I
> noticed  that  quite  a  lot  of  boards use insane values of CFG_HZ.
> Remember that this should be the  number  of  clock  ticks  (=  timer
> interrupts)  per  second,  and  there  is  usually no reason to chose
> anything else but the default value of 1000.  Many  boards  use  some
> much,  much  higher  clock  values instead. This should be fixed. [We
> recently fixed this for AT91RM9200 systems.]

It seems that people easily get confused about what CFG_HZ should be.
A grep of CFG_HZ finds that many ARM boards (of course, some other
boards) don't interpret CFG_HZ or clock ticks in the way as you did
above. Studying your fix for AT91RM9200 systems finds out your newly
introduced get_timer_raw() function. So now we have a few functions
get_timer(), get_timer_masked(), and get_timer_raw(). I noticed that
some people called get_timer_masked() directly and other used
get_timer() in a loop to determine the timeout of some actions.

Shall we have a rule to guide where and when these functions should be used?

To my understanding based on your fix for AT91RM9200 systems,
1. get_timer_maksed() should return the number of clock ticks, just as
get_ticks().
2. get_timer_raw() returns the value of timestamp, which counts how
many clocks elapse according to the timer's setting. It'a local
function and should not be called in any other modules.

Regards,
-Shawn.