From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ladislav Michl <ladis@linux-mips.org>
Date: Thu, 23 Apr 2009 10:01:14 +0200
Subject: [U-Boot] U-Boot Timer Qualification
In-Reply-To: <20090422221800.D3EF883420E8@gemini.denx.de>
References: <20090422204936.GB29252@game.jcrosoft.org>
	<20090422210835.B1EB583420E8@gemini.denx.de>
	<20090422212816.GA18705@game.jcrosoft.org>
	<20090422221800.D3EF883420E8@gemini.denx.de>
Message-ID: <20090423080114.GA2072@localhost.localdomain>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Thu, Apr 23, 2009 at 12:18:00AM +0200, Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090422212816.GA18705@game.jcrosoft.org> you wrote:
> >
> > > Who needs this, and why and when, and why didn't we need it the past?
> > a lot of actual timer are not correct and we have problem on network timeout
> > as example.
> 
> Hm... how muich of precision do we actuually need?

Well, I already complained about all such a testing on the IRC yesterday,
so I'm not going to repeat...

And if I got Jean-Christophe correctly he cares about "real world"
verification that timer code is written the right way.

> > So we need to known the precision of the timer to known the impact on all
> > timer depends part of u-boot as timeout or bitbanging stack
> > 
> > so when you have to respect some delay to init some chip or other you will to
> > known the delay you will have in reality. This will avoid you a lots of pain
> > during the dev
> 
> In my experience, no parts of the code actually care about precision
> of the timers, especially not when implementing delay loops or
> timeouts using udelay() which always includes static overhead. For
> example, the following two snippets of code are only in theory
> equivalent:
> 
> 	for (i=0; i < 100; ++i)
> 		udelay (10000);
> 
> versus
> 
> 	for (i=0; i < 1000; ++i) {
> 		for (j=0; j < 1000; ++j)
> 			udelay (1);
> 	}
> 
> But - is this really a problem? I am not aware of any place in the
> code where a tolerance of +/- 10% or maybe even more would matter.

Well, more interesting case to test is:

	reset_timer();
	while (get_timer() < 100000)
		udelay(10000);

to prove get_timer has no bad interference with udelay. Proposed method also
doesn't verify another corner case - timer {under,over}flow.

> Note: when you are implementing a bit-banging protcol that requires
> precise timings and run into problems, then this is not a problem with
> U-Boot timer accuracy, but with incorrect system design on your
> system.

Seconded, same point made on IRC.

Best regards,
	ladis