[U-Boot] [PATCH 1/8] u8500: Correct unnecessary mathematical roll-over
Lee Jones
lee.jones at linaro.org
Wed Nov 21 11:02:28 CET 2012
> > If we attempt to take a 32bit timer value and multiply it by a
> > significant number, the core will not be able to handle it. This
> > gives the illusion that the timer is rolling over, when in fact
> > this is not the case. If we ensure the division in this instance
> > is carried out before the multiplication, the issue vanishes.
>
> Are you sure this is a good idea?
Not now I'm not. :)
> > --- a/arch/arm/cpu/armv7/u8500/timer.c
> > +++ b/arch/arm/cpu/armv7/u8500/timer.c
> > @@ -70,7 +70,7 @@ struct u8500_mtu {
> > * The MTU is clocked at 133 MHz by default. (V1 and later)
> > */
> > #define TIMER_CLOCK (133 * 1000 * 1000 / 16)
> > -#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.
> I doubt x will never be < 133, as that will be 16 micro-seconds
> post timer-start or role-over. Do we really need that degree of
> resolution?
Am assuming by your response that I'm wrong somewhere, and the
resolution loss will be >16us?
> After the change, the result is changed to the worse for all low
> values of X, especially for the ranges from 16 through 132.
>
> You lose accuracy here, and win nothing.
>
> This makes no sense to me.
>
> 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?
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
More information about the U-Boot
mailing list