From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shawn Date: Fri, 15 Oct 2004 16:01:43 -0700 Subject: [U-Boot-Users] CFG_HZ and get_timer() issue In-Reply-To: <20041014211001.F02C4C1430@atlas.denx.de> References: <20041014211001.F02C4C1430@atlas.denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.