From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754659AbbLJPRM (ORCPT <rfc822;w@1wt.eu>);
	Thu, 10 Dec 2015 10:17:12 -0500
Received: from devils.ext.ti.com ([198.47.26.153]:57611 "EHLO
	devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752974AbbLJPRK (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 10 Dec 2015 10:17:10 -0500
Subject: Re: [PATCH v2] irqchip: omap-intc: add support for spurious irq
 handling
To: Felipe Balbi <balbi@ti.com>, Tony Lindgren <tony@atomide.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Jason Cooper <jason@lakedaemon.net>,
        Marc Zyngier <marc.zyngier@arm.com>
References: <0958510b69cf679fef64ccf535b1cdc43c5ffccc.1449572109.git.nsekhar@ti.com>
 <87mvtlm4ts.fsf@saruman.tx.rr.com>
CC: John Ogness <john.ogness@linutronix.de>,
        Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
From: Sekhar Nori <nsekhar@ti.com>
Message-ID: <56699762.1030501@ti.com>
Date: Thu, 10 Dec 2015 20:46:50 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <87mvtlm4ts.fsf@saruman.tx.rr.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

Thanks,
Sekhar