clocksource: convert mips to generic i8253 clocksource
Convert MIPS i8253 clocksource code to use generic i8253 clocksource. Acked-by: John Stultz <john.stultz@linaro.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This commit is contained in:
parent
82491451dd
commit
798778b865
3 changed files with 7 additions and 77 deletions
|
@ -2339,6 +2339,7 @@ config MMU
|
|||
|
||||
config I8253
|
||||
bool
|
||||
select CLKSRC_I8253
|
||||
select MIPS_EXTERNAL_TIMER
|
||||
|
||||
config ZONE_DMA32
|
||||
|
|
|
@ -12,8 +12,13 @@
|
|||
#define PIT_CH0 0x40
|
||||
#define PIT_CH2 0x42
|
||||
|
||||
#define PIT_LATCH LATCH
|
||||
|
||||
extern raw_spinlock_t i8253_lock;
|
||||
|
||||
extern void setup_pit_timer(void);
|
||||
|
||||
#define inb_pit inb_p
|
||||
#define outb_pit outb_p
|
||||
|
||||
#endif /* __ASM_I8253_H */
|
||||
|
|
|
@ -125,87 +125,11 @@ void __init setup_pit_timer(void)
|
|||
setup_irq(0, &irq0);
|
||||
}
|
||||
|
||||
/*
|
||||
* Since the PIT overflows every tick, its not very useful
|
||||
* to just read by itself. So use jiffies to emulate a free
|
||||
* running counter:
|
||||
*/
|
||||
static cycle_t pit_read(struct clocksource *cs)
|
||||
{
|
||||
unsigned long flags;
|
||||
int count;
|
||||
u32 jifs;
|
||||
static int old_count;
|
||||
static u32 old_jifs;
|
||||
|
||||
raw_spin_lock_irqsave(&i8253_lock, flags);
|
||||
/*
|
||||
* Although our caller may have the read side of xtime_lock,
|
||||
* this is now a seqlock, and we are cheating in this routine
|
||||
* by having side effects on state that we cannot undo if
|
||||
* there is a collision on the seqlock and our caller has to
|
||||
* retry. (Namely, old_jifs and old_count.) So we must treat
|
||||
* jiffies as volatile despite the lock. We read jiffies
|
||||
* before latching the timer count to guarantee that although
|
||||
* the jiffies value might be older than the count (that is,
|
||||
* the counter may underflow between the last point where
|
||||
* jiffies was incremented and the point where we latch the
|
||||
* count), it cannot be newer.
|
||||
*/
|
||||
jifs = jiffies;
|
||||
outb_p(0x00, PIT_MODE); /* latch the count ASAP */
|
||||
count = inb_p(PIT_CH0); /* read the latched count */
|
||||
count |= inb_p(PIT_CH0) << 8;
|
||||
|
||||
/* VIA686a test code... reset the latch if count > max + 1 */
|
||||
if (count > LATCH) {
|
||||
outb_p(0x34, PIT_MODE);
|
||||
outb_p(LATCH & 0xff, PIT_CH0);
|
||||
outb(LATCH >> 8, PIT_CH0);
|
||||
count = LATCH - 1;
|
||||
}
|
||||
|
||||
/*
|
||||
* It's possible for count to appear to go the wrong way for a
|
||||
* couple of reasons:
|
||||
*
|
||||
* 1. The timer counter underflows, but we haven't handled the
|
||||
* resulting interrupt and incremented jiffies yet.
|
||||
* 2. Hardware problem with the timer, not giving us continuous time,
|
||||
* the counter does small "jumps" upwards on some Pentium systems,
|
||||
* (see c't 95/10 page 335 for Neptun bug.)
|
||||
*
|
||||
* Previous attempts to handle these cases intelligently were
|
||||
* buggy, so we just do the simple thing now.
|
||||
*/
|
||||
if (count > old_count && jifs == old_jifs) {
|
||||
count = old_count;
|
||||
}
|
||||
old_count = count;
|
||||
old_jifs = jifs;
|
||||
|
||||
raw_spin_unlock_irqrestore(&i8253_lock, flags);
|
||||
|
||||
count = (LATCH - 1) - count;
|
||||
|
||||
return (cycle_t)(jifs * LATCH) + count;
|
||||
}
|
||||
|
||||
static struct clocksource clocksource_pit = {
|
||||
.name = "pit",
|
||||
.rating = 110,
|
||||
.read = pit_read,
|
||||
.mask = CLOCKSOURCE_MASK(32),
|
||||
.mult = 0,
|
||||
.shift = 20,
|
||||
};
|
||||
|
||||
static int __init init_pit_clocksource(void)
|
||||
{
|
||||
if (num_possible_cpus() > 1) /* PIT does not scale! */
|
||||
return 0;
|
||||
|
||||
clocksource_pit.mult = clocksource_hz2mult(CLOCK_TICK_RATE, 20);
|
||||
return clocksource_register(&clocksource_pit);
|
||||
return clocksource_i8253_init();
|
||||
}
|
||||
arch_initcall(init_pit_clocksource);
|
||||
|
|
Loading…
Reference in a new issue