Fix the dubious use of cycles_t where cycle_t was appropriate.  On the machines
with 32-bit cycles_t (like ARM/PPC) it caused these warnings:

In file included from arch/powerpc/kernel/time.c:1045:
include/linux/clocksource.h: In function `ns2cyc':
include/linux/clocksource.h:213: warning: comparison of distinct pointer types lacks a cast
include/linux/clocksource.h:213: warning: right shift count >= width of type
include/linux/clocksource.h:213: warning: passing argument 1 of `__div64_32' from incompatible pointer type

This function and therefore usecs_to_cycles() was unlikely to return a correct
result on such machines because of the shift result truncation.

Signed-off-by: Sergei Shtylyov <redacted>

---
I'm also uncertain about 'preempt_max_latency' and 'preempt_thresh' variables
being declared as 'unsigned long' -- however, looks like those are unlikely to
overflow... yet it's unclear why there's casts to 'cycle_t' (which is always
64-bit) when initializing/comparing them...

Index: linux-2.6/include/linux/clocksource.h
===================================================================

--- linux-2.6.orig/include/linux/clocksource.h
+++ linux-2.6/include/linux/clocksource.h

@@ -206,9 +206,9 @@ static inline s64 cyc2ns(struct clocksou
  * @cs:		Pointer to clocksource
  * @nsecs:	Nanoseconds
  */
-static inline cycles_t ns2cyc(struct clocksource *cs, u64 nsecs)
+static inline cycle_t ns2cyc(struct clocksource *cs, u64 nsecs)
 {
-	cycles_t ret = nsecs << cs->shift;
+	cycle_t ret = nsecs << cs->shift;
 
 	do_div(ret, cs->mult + 1);