Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754176AbbLKF0M (ORCPT ); Fri, 11 Dec 2015 00:26:12 -0500 Received: from smtprelay2.synopsys.com ([198.182.60.111]:47671 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753813AbbLKF0I convert rfc822-to-8bit (ORCPT ); Fri, 11 Dec 2015 00:26:08 -0500 From: Vineet Gupta To: Marc Zyngier , Daniel Lezcano , Jason Cooper CC: Peter Zijlstra , Thomas Gleixner , arcml , lkml , "maxime.ripard@free-electrons.com" Subject: Re: percpu irq APIs and perf Thread-Topic: percpu irq APIs and perf Thread-Index: AdEzLMRmgLK5hO2ATNaqHxhV1QsWjQ== Date: Fri, 11 Dec 2015 05:26:02 +0000 Message-ID: References: <56694C0E.5050707@arm.com> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.197.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2679 Lines: 69 Hi Marc, On Thursday 10 December 2015 03:26 PM, Marc Zyngier wrote: > Hi Vinnet, > > On 10/12/15 09:25, Vineet Gupta wrote: >> Hi Marc / Daniel / Jason, >> >> I had a couple of questions about percpu irq API, hopefully you can help answer. >> >> On ARM, how do u handle requesting per cpu IRQs - specifically usage >> of request_percpu_irq() / enable_percpu_irq() API. >> It seems, for using them, we obviously need to explicitly set irq as >> percpu and as a consequence explicitly enable autoen (since former >> disables that). See arch/arc/kernel/irq.c: arc_request_percpu_irq() >> called by ARC per cpu timer setup. > Indeed. The interrupt controller code flags these interrupts as being > per-cpu, and we do rely on each CPU performing an enable_percpu_irq(). > > So the way the whole thing flows is as such: > - Interrupt controller (GIC) flags the PPIs (Private Peripheral > Interrupt) as per-CPU (hwirq 16 to 31 are replicated per CPU) very early > in the boot process Thx for your reply and the pointers irq-gic.c seems to be doing irq_set_status_flags(irq, IRQ_NOAUTOEN); So it is setting NOAUTOEN, which is already the case per side effect of irq_set_percpu_devid(). No harm in making it explicit. So this will make __setup_irq() skip irq_startup() and instead rely on enable_precpu_irq() to be called even for the local core. I think we can make percpu irq API a bit easier to use. (1) First thing which request_percpu_irq() does is check for irq_settings_is_per_cpu_devid(). Thus irq_set_percpu_devid() can be built into the API itself eliding the need to set it apriori. (2) It seems that disabling autoen by default for percpu irq makes sense as evident from drivers/net/ethernet/marvell/mvneta.c where users want to control this. However the comment there is misleading /* Even though the documentation says that request_percpu_irq * doesn't enable the interrupts automatically, it actually * does so on the local CPU. * * Make sure it's disabled. */ Either sme core code is clearing NOAUTOEN or calling enable_precpu_irq() making request_percpu_irq() enable it. IMHO it makes more sense to make autoen explicit in the API. Perhaps introduce a API flavour, which takes the autoen as arg. It could take flags to make it more extensible / future safe but that will be an overkill I think. Do let me know what you think and I can send RFC patches to same effect. Thx, -Vineet -- 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/