On Mon, 19 Oct 2015, Sekhar Nori wrote:
> +     /*
> +      * A spurious IRQ can result if interrupt that triggered the
> +      * sorting is no longer active during the sorting (10 INTC
> +      * functional clock cycles after interrupt assertion). Or a
> +      * change in interrupt mask affected the result during sorting
> +      * time. There is no special handling required except ignoring
> +      * the SIR register value just read and retrying.
> +      * See section 6.2.5 of AM335x TRM Literature Number: SPRUH73K
> +      */
> +     if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {
> +             pr_debug_ratelimited("%s: spurious irq!\n", __func__);

I'd prefer that this is a pr_once() and the spurious interrupt counter
is incremented. That's far more useful as it gives you real
information about the frequency of the issue.

Thanks,

        tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to