diff options
author | Russell King <rmk@dyn-67.arm.linux.org.uk> | 2007-11-12 22:45:16 +0000 |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2008-01-26 15:07:50 +0000 |
commit | a88264c24c44924a549f3d596b86d611b7ee9909 (patch) | |
tree | 1f8e339e22743acf64b0d19a9b8328bbf5b66ac3 /arch/arm/mach-pxa/time.c | |
parent | 3777f7748a5d10222a55ce88f753a19b16c17032 (diff) | |
download | talos-op-linux-a88264c24c44924a549f3d596b86d611b7ee9909.tar.gz talos-op-linux-a88264c24c44924a549f3d596b86d611b7ee9909.zip |
[ARM] pxa: remove periodic mode emulation support
Apparantly, the generic time subsystem can accurately emulate periodic
mode via the one-shot support code, so we don't need our own periodic
emulation code anymore. Just ensure that we build support for one shot
into the generic time subsystem.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'arch/arm/mach-pxa/time.c')
-rw-r--r-- | arch/arm/mach-pxa/time.c | 61 |
1 files changed, 8 insertions, 53 deletions
diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c index fbfa1920353d..3c4abbf31803 100644 --- a/arch/arm/mach-pxa/time.c +++ b/arch/arm/mach-pxa/time.c @@ -59,55 +59,17 @@ unsigned long long sched_clock(void) } +#define MIN_OSCR_DELTA 16 + static irqreturn_t pxa_ost0_interrupt(int irq, void *dev_id) { - int next_match; struct clock_event_device *c = dev_id; - if (c->mode == CLOCK_EVT_MODE_ONESHOT) { - /* Disarm the compare/match, signal the event. */ - OIER &= ~OIER_E0; - OSSR = OSSR_M0; - c->event_handler(c); - } else if (c->mode == CLOCK_EVT_MODE_PERIODIC) { - /* Call the event handler as many times as necessary - * to recover missed events, if any (if we update - * OSMR0 and OSCR0 is still ahead of us, we've missed - * the event). As we're dealing with that, re-arm the - * compare/match for the next event. - * - * HACK ALERT: - * - * There's a latency between the instruction that - * writes to OSMR0 and the actual commit to the - * physical hardware, because the CPU doesn't (have - * to) run at bus speed, there's a write buffer - * between the CPU and the bus, etc. etc. So if the - * target OSCR0 is "very close", to the OSMR0 load - * value, the update to OSMR0 might not get to the - * hardware in time and we'll miss that interrupt. - * - * To be safe, if the new OSMR0 is "very close" to the - * target OSCR0 value, we call the event_handler as - * though the event actually happened. According to - * Nico's comment in the previous version of this - * code, experience has shown that 6 OSCR ticks is - * "very close" but he went with 8. We will use 16, - * based on the results of testing on PXA270. - * - * To be doubly sure, we also tell clkevt via - * clockevents_register_device() not to ask for - * anything that might put us "very close". - */ -#define MIN_OSCR_DELTA 16 - do { - OSSR = OSSR_M0; - next_match = (OSMR0 += LATCH); - c->event_handler(c); - } while (((signed long)(next_match - OSCR) <= MIN_OSCR_DELTA) - && (c->mode == CLOCK_EVT_MODE_PERIODIC)); - } + /* Disarm the compare/match, signal the event. */ + OIER &= ~OIER_E0; + OSSR = OSSR_M0; + c->event_handler(c); return IRQ_HANDLED; } @@ -133,14 +95,6 @@ pxa_osmr0_set_mode(enum clock_event_mode mode, struct clock_event_device *dev) unsigned long irqflags; switch (mode) { - case CLOCK_EVT_MODE_PERIODIC: - raw_local_irq_save(irqflags); - OSSR = OSSR_M0; - OIER |= OIER_E0; - OSMR0 = OSCR + LATCH; - raw_local_irq_restore(irqflags); - break; - case CLOCK_EVT_MODE_ONESHOT: raw_local_irq_save(irqflags); OIER &= ~OIER_E0; @@ -158,13 +112,14 @@ pxa_osmr0_set_mode(enum clock_event_mode mode, struct clock_event_device *dev) break; case CLOCK_EVT_MODE_RESUME: + case CLOCK_EVT_MODE_PERIODIC: break; } } static struct clock_event_device ckevt_pxa_osmr0 = { .name = "osmr0", - .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT, + .features = CLOCK_EVT_FEAT_ONESHOT, .shift = 32, .rating = 200, .cpumask = CPU_MASK_CPU0, |