[PATCH] clockevents/drivers/arm_global_timer: Fix erratum 740657 workaround
Marc Zyngier
marc.zyngier at arm.com
Tue Mar 29 09:13:05 PDT 2016
Hi Rabin,
On 29/03/16 09:08, Rabin Vincent wrote:
> From: Rabin Vincent <rabinv at axis.com>
>
> According to the errata document for the Cortex A9 MPCore, the correct
> code sequence in the interrupt handler to workaround erratum 740657
> "Global Timer can send two interrupts for the same event" is:
>
> (1) Read the ICCIAR (Interrupt Acknowledge) register
> (2) Modify the comparator value, to set it to a higher value
> (3) Clear the Global Timer flag
> (4) Clear the Pending Status information for Interrupt 27 (Global
> Timer interrupt) in the Distributor of the Interrupt Controller.
> (5) Write the ICCEOIR (End of Interrupt) register
>
> (1) and (5) are done by the GIC driver and (2) and (3) are done by the
> Global Timer driver. However, nobody does (4) and thus the workaround
> is inactive and the timer triggers many spurious interrupts:
>
> <idle>-0 [001] d.h2 99.850527: irq_handler_entry: irq=16 name=gt
> <idle>-0 [001] d.h2 99.850538: irq_handler_exit: irq=16 ret=handled
> <idle>-0 [001] d.H2 99.850540: irq_handler_entry: irq=16 name=gt
> <idle>-0 [001] d.H2 99.850542: irq_handler_exit: irq=16 ret=unhandled
> <idle>-0 [001] d.h2 99.987832: irq_handler_entry: irq=16 name=gt
> <idle>-0 [001] dnh2 99.987845: irq_handler_exit: irq=16 ret=handled
> <idle>-0 [001] dnh2 99.987848: irq_handler_entry: irq=16 name=gt
> <idle>-0 [001] dnh2 99.987850: irq_handler_exit: irq=16 ret=unhandled
>
> Make the Global Timer driver perform step (4) via the GIC driver with
> the help of the irq_set_irqchip_state() function, to prevent the
> spurious interrupts.
>
> Signed-off-by: Rabin Vincent <rabinv at axis.com>
> ---
> drivers/clocksource/arm_global_timer.c | 21 +++++++++++++--------
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c
> index 9df0d16..b9d0f86 100644
> --- a/drivers/clocksource/arm_global_timer.c
> +++ b/drivers/clocksource/arm_global_timer.c
> @@ -140,26 +140,31 @@ static int gt_clockevent_set_next_event(unsigned long evt,
> static irqreturn_t gt_clockevent_interrupt(int irq, void *dev_id)
> {
> struct clock_event_device *evt = dev_id;
> + bool workaround = clockevent_state_oneshot(evt);
>
> if (!(readl_relaxed(gt_base + GT_INT_STATUS) &
> GT_INT_STATUS_EVENT_FLAG))
> return IRQ_NONE;
>
> /**
> - * ERRATA 740657( Global Timer can send 2 interrupts for
> + * ERRATA 740657 (Global Timer can send 2 interrupts for
> * the same event in single-shot mode)
> * Workaround:
> - * Either disable single-shot mode.
> - * Or
> - * Modify the Interrupt Handler to avoid the
> - * offending sequence. This is achieved by clearing
> - * the Global Timer flag _after_ having incremented
> - * the Comparator register value to a higher value.
> + * - Read the ICCIAR (Interrupt Acknowledge) register
> + * - Modify the comparator value, to set it to a higher value
> + * - Clear the Global Timer flag
> + * - Clear the Pending Status information for Interrupt 27 (Global
> + * Timer interrupt) in the Distributor of the Interrupt Controller.
> + * - Write the ICCEOIR (End of Interrupt) register
> */
> - if (clockevent_state_oneshot(evt))
> + if (workaround)
> gt_compare_set(ULONG_MAX, 0);
>
> writel_relaxed(GT_INT_STATUS_EVENT_FLAG, gt_base + GT_INT_STATUS);
> +
> + if (workaround)
> + irq_set_irqchip_state(irq, IRQCHIP_STATE_PENDING, false);
> +
This raises a few questions:
- What if my timer is not connected to a controller that implements this
API? Something that is not a GIC, for example?
- How does it work when the GIC (with EOImode==1) performs a priority
drop (by writing to the EOI register) before calling into the timer
handler, and finishing the handling with a write to DIR?
- What are the comparative costs of taking a spurious (but nonetheless
harmless) interrupt vs poking the distributor (which is by no mean a
cheap operation)?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
More information about the linux-arm-kernel
mailing list