Dear Lee Jones,
In message 20121121100228.GJ28265@gmail.com you wrote:
-#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.
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.
However, I fail to see why that should even be needed here.
Best regards,
Wolfgang Denk