There is no point in having an extra type for extra confusion. u64 is
unambiguous.
Conversion was done with the following coccinelle script:
@rem@
@@
-typedef u64 cycle_t;
@fix@
typedef cycle_t;
@@
-cycle_t
+u64
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: John Stultz <john.stultz@linaro.org>
Migrate i8253 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
The i8253 clockevent & clocksource driver uses PIT_LATCH
except for two cases where it uses LATCH:
1)
/* VIA686a test code... reset the latch if count > max + 1 */
if (count > LATCH) {
LATCH is based on CLOCK_TICK_RATE which is defined as
PIT_TICK_RATE on x86 so this should just be the later.
2)
...
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
/* binary, mode 2, LSB/MSB, ch 0 */
outb_p(0x34, PIT_MODE);
outb_p(LATCH & 0xff , PIT_CH0); /* LSB */
outb_p(LATCH >> 8 , PIT_CH0); /* MSB */
...
MIPS and ARM are the only other arches that use this driver. In
the MIPS case CLOCK_TICK_RATE is defined as the same value as
PIT_TICK_RATE. For ARM, the only machine that uses it is
Footbridge which has a totally bogus CLOCK_TICK_RATE according
to the comments. Furthermore, the clockevent_i8253_init()
initializes the clockevent with PIT_TIC_RATE, so there's
no reason to use the generic LATCH.
This is part of work to remove and depecrate the global
CLOCK_TICK_RATE symbol.
Signed-off-by: Deepak Saxena <dsaxena@linaro.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
