Round up in __udelay(): 2**32 / 100000 is 4294.97, so it's more intuitive
to round up, and it causes more predictable results:

n usec delay on a 1500000 BogoMIPS system:

  n 	   before	  -mull		after
  1	 1000 ticks	 1499 ticks	 1500 ticks
 10	14000 ticks	14999 ticks	15000 ticks

n usec delay on a 100000 BogoMIPS system: 

 n 	   before	  -mull		after
  1	    0 ticks	   99 ticks	  100 ticks
 10	    0 ticks	  999 ticks	 1000 ticks
100	 9000 ticks	 9999 ticks	10000 ticks

While it can be argued that some time is also spent in the delay functions,
it's better to spend _at least_ the specified time sleeping, in my humble
opinion.  And the overhead of a specific ->delay() implementation should be
substracted in the specific ->delay() implementation.
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>