From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752568AbbLNFwN (ORCPT ); Mon, 14 Dec 2015 00:52:13 -0500 Received: from us01smtprelay-2.synopsys.com ([198.182.47.9]:39350 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110AbbLNFwL convert rfc822-to-8bit (ORCPT ); Mon, 14 Dec 2015 00:52:11 -0500 From: Vineet Gupta To: Marc Zyngier CC: Daniel Lezcano , Jason Cooper , 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: Mon, 14 Dec 2015 05:50:39 +0000 Message-ID: References: <56694C0E.5050707@arm.com> <566AB24C.3040407@arm.com> <566ABF86.9030308@synopsys.com> <566B0EC4.5060000@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 On Friday 11 December 2015 11:28 PM, Marc Zyngier wrote: >>> But auto-enabling cannot be done from a single CPU. It can only be done >>> >> from the core that is going to be delivered that interrupt. This >>> >> requires access to registers that are simply not available to other CPUs. >> > >> > I'm not talking about eliminating enable_percpu_irq() call from all cores and >> > still getting the auto-enable semantics. What I mean is doing the equivalent of >> > >> > irq_set_status_flags(irq, IRQ_NOAUTOEN); >> > >> > from within request_percpu_irq_xxx() based on an additional arg (vs. doing it >> > aprioiri outside). >> > >> > OTOH, thinking a bit more abt this, I think the current semantics of auto-disable >> > w/o any arg is just fine. Most percpu irqs in general purpose drivers would want >> > the auto-disable anyways. Only for core irws such as timer / IPI etc do we want >> > auto-enable. > So assuming we can do this (forgetting about any form of HW limitation): > CPU0 request the per-CPU IRQ with an AUTOEN flag. What happens on CPU1? > Are you expecting it to immediately be able to take interrupts? What > handler data gets passed to it? Right - autoen=true will only help on CPU0. Others will still need to call enable - for register tinkling etc. A true autoen API should have done that across the board which it clearly can't and hence is pointless. Thx, -Vineet From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vineet.Gupta1@synopsys.com (Vineet Gupta) Date: Mon, 14 Dec 2015 05:50:39 +0000 Subject: percpu irq APIs and perf References: <56694C0E.5050707@arm.com> <566AB24C.3040407@arm.com> <566ABF86.9030308@synopsys.com> <566B0EC4.5060000@arm.com> List-ID: Message-ID: To: linux-snps-arc@lists.infradead.org On Friday 11 December 2015 11:28 PM, Marc Zyngier wrote: >>> But auto-enabling cannot be done from a single CPU. It can only be done >>> >> from the core that is going to be delivered that interrupt. This >>> >> requires access to registers that are simply not available to other CPUs. >> > >> > I'm not talking about eliminating enable_percpu_irq() call from all cores and >> > still getting the auto-enable semantics. What I mean is doing the equivalent of >> > >> > irq_set_status_flags(irq, IRQ_NOAUTOEN); >> > >> > from within request_percpu_irq_xxx() based on an additional arg (vs. doing it >> > aprioiri outside). >> > >> > OTOH, thinking a bit more abt this, I think the current semantics of auto-disable >> > w/o any arg is just fine. Most percpu irqs in general purpose drivers would want >> > the auto-disable anyways. Only for core irws such as timer / IPI etc do we want >> > auto-enable. > So assuming we can do this (forgetting about any form of HW limitation): > CPU0 request the per-CPU IRQ with an AUTOEN flag. What happens on CPU1? > Are you expecting it to immediately be able to take interrupts? What > handler data gets passed to it? Right - autoen=true will only help on CPU0. Others will still need to call enable - for register tinkling etc. A true autoen API should have done that across the board which it clearly can't and hence is pointless. Thx, -Vineet