When I moved sparc64 over to HZ==1000 this added some
problems to the udelay() handling.  Specifically, with
slower cpus we could now get underflows to zero for
things like udelay(1) due to the order of multiplies
and shifts.

Fix this, and move it out to arch/sparc64/lib/delay.c
so it is easier to tinker with this in the future and
also to optimize away one of the multiplies for the
constant delay case just like other platforms do.
Signed-off-by: David S. Miller <davem@davemloft.net>