From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott McNutt Date: Fri, 27 May 2011 11:44:17 -0400 Subject: [U-Boot] [RFC][Timer API] Revised Specification - Implementation details In-Reply-To: <4DDFBC8A.8030403@comcast.net> References: <4DDE5548.3020906@gmail.com> <4DDE8639.3090909@comcast.net> <20110527071355.5DA8014EF7F@gemini.denx.de> <4DDF543D.6020506@gmail.com> <20110527074832.5B98E1354FC@gemini.denx.de> <20110527112721.9023C101D7A@gemini.denx.de> <4DDFA206.5050101@psyent.com> <4DDFBC8A.8030403@comcast.net> Message-ID: <4DDFC6D1.10305@psyent.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de J. William Campbell wrote: > On 5/27/2011 6:07 AM, Scott McNutt wrote: >> Graeme Russ wrote: >>> Hi Wolfgang >>> >>> On Friday, May 27, 2011, Wolfgang Denk wrote: >>>> Dear Graeme Russ, >>>> >>>> In message you >>>> wrote: >>>>> Besides, Nios can return an increment of 10 (presumably ms) between >>>>> two immediately consecutive calls. This causes early timeouts in CFI >>>>> driver >>>> Now this in turn is a bug in the timer implementation that needs to be >>>> fixed. >> >> And this is what reset_timer() corrected. >> >>> Agreed, but that is not something I can achieve - I don't want to hold >>> up this whole show that we have all put so much effort into for the >>> sake of one weak function >> >> And I don't want to see something that currently works become broken >> because we "improved" a feature ... simply because the resolution of >> the timestamp is 10 msec rather than 1 msec. >> >> And just to be clear. This is not a Nios issue. Currently, if the >> timestamp is incremented via a fixed period interrupt, and the period >> of the interrupt is longer that 1 msec, calls to get_timer() may >> produce early timeouts ... regardless of platform. > This can be > fixed in get_timer, making the 8 ms delay become a minimum of 10 ms at > the expense of it becoming up to 20 ms sometimes. Ok. Now I get it. Thanks. > This reset approach is bad in that it prevents > proper nesting of timing loops. In my particular case, because reset_timer() resets the timestamp to zero rather than simply restarting the timer. I believe leaving the timestamp alone would solve the nesting problem. > The other fix > is in my opinion nicer, because it affects the nest loops less. If the > inner loop is executed 100 times, with the reset, the outer loop timeout > is extended by up to 1000 ms. Bill, thank you for explaining -- probably for the nth time -- but it did finally sink in. Regards, --Scott