From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lee Jones <lee.jones@linaro.org>
Date: Wed, 21 Nov 2012 14:54:34 +0000
Subject: [U-Boot] [PATCH 1/8] u8500: Correct unnecessary mathematical
 roll-over
In-Reply-To: <20121121135108.DB0A82003CF@gemini.denx.de>
References: <1353422034-28107-1-git-send-email-lee.jones@linaro.org>
	<1353422034-28107-2-git-send-email-lee.jones@linaro.org>
	<20121120181453.568D620009C@gemini.denx.de>
	<20121121100228.GJ28265@gmail.com>
	<20121121135108.DB0A82003CF@gemini.denx.de>
Message-ID: <20121121145434.GB28899@gmail.com>
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

> > > > -#define COUNT_TO_USEC(x)	((x) * 16 / 133)
> > > > +#define COUNT_TO_USEC(x)	((x) / 133 * 16)
> > > 
> > > Before the change, the result is useful for all values of x in the
> > > interval from 0 through UINT_MAX/16 = 268435455 = 268 seconds, i. e.
> > > for all values that make sense to be measured in microseconds.
> > 
> > We're actually discussing this elsewhere. I don't have
> > permission to paste the other side of the conversation, but
> > I can show you my calculations:
> > 
> > > The original implementation is fine until we reach 32.28 seconds, which
> > > as you predicted is 0x1000_0000:
> > 
> > > 0x10000000 * PRESCALER) / (CLOCK_SPEED_133_MHZ)
> > > (268435456 * 16       ) / (133  * 1000  * 1000) == 32.28 seconds
> > 
> > > If we spend >30 seconds at the u-boot commandline, which is not
> > > unreasonable by any stretch, then the kernel assumes responsibility for
> > > the remaining of the time spent at the prompt, which is obviously not
> > > acceptable for this usecase.
> 
> This makes no sense to me.  An overflow will not happen before
> UINT_MAX/16 = 268435455 = 268 seconds.

Right, but that's the timer.

The issue here is not that the timer is overflowing, it's the
arithmetics that takes place once the timer value is obtained.
If a value of >0x10000000 is read, then we carry out the
arithmetic above, then other registers overflow.

> Anyway.  If you have overflof problems, then use proper arithmetics.
> 
> > > If you need a bigger number range, then use proper arithmetics. It';s
> > > available, just use it.
> > 
> > Would you be able to lend a hand here, as I'm no mathematician?
> > 
> > What are the correct arithmetics?
> 
> There are routines like do_div() or lldiv() etc. that can be used when
> 32 bit arithmetics is really not good enough.

Ah ha, thanks.
 
> However, I fail to see why that should even be needed here.

As above.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog