Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1292213 > unrolled thread
| Started by | Sekhar Nori <nsekhar@ti.com> |
|---|---|
| First post | 2015-12-15 15:30 +0100 |
| Last post | 2015-12-15 15:30 +0100 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2] irqchip: omap-intc: add support for spurious irq handling Sekhar Nori <nsekhar@ti.com> - 2015-12-15 15:30 +0100
| From | Sekhar Nori <nsekhar@ti.com> |
|---|---|
| Date | 2015-12-15 15:30 +0100 |
| Subject | Re: [PATCH v2] irqchip: omap-intc: add support for spurious irq handling |
| Message-ID | <qFYM1-5hd-7@gated-at.bofh.it> |
On Thursday 10 December 2015 08:46 PM, Sekhar Nori wrote:
> Hi Felipe,
>
> On Tuesday 08 December 2015 07:15 PM, Felipe Balbi wrote:
>> Sekhar Nori <nsekhar@ti.com> writes:
>
>>> + /*
>>> + * 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
>>> + *
>>> + * Many a times, a spurious interrupt situation has been fixed
>>> + * by adding a flush for the posted write acking the IRQ in
>>> + * the device driver. Typically, this is going be the device
>>> + * driver whose interrupt was handled just before the spurious
>>> + * IRQ occurred. Pay attention to those device drivers if you
>>> + * run into hitting the spurious IRQ condition below.
>>> + */
>>> + if ((irqnr & SPURIOUSIRQ_MASK) == SPURIOUSIRQ_MASK) {
>>
>> sounds like unlikely() wouldn't hurt here.
>
> I can add, but looks like it does not make a big difference. See below.
>
>>
>>> + pr_err_once("%s: spurious irq!\n", __func__);
>>> + irq_err_count++;
>>> + omap_ack_irq(NULL);
>>> + return;
>>> + }
>>> +
>>> irqnr &= ACTIVEIRQ_MASK;
>>> - WARN_ONCE(!irqnr, "Spurious IRQ ?\n");
>>> handle_domain_irq(domain, irqnr, regs);
>>
>> care to run kernel function profiler against omap_intc_handle_irq()
>> before and after this patch ?
>
> Before this patch I see average running time time of 34us. That
> increases to 37.8us after this patch. With unlikely() the number I got
> was 37.4us. So the benefit with unlikely() is in the noise range.
>
> This was using AM335x EVM at 720 MHz.
Just sent a v3 with unlikely() and profiling information added to commit
message.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top | Article view | linux.kernel
csiph-web