From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A4EEC47089 for ; Thu, 27 May 2021 12:21:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DE3246124C for ; Thu, 27 May 2021 12:21:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234795AbhE0MXO (ORCPT ); Thu, 27 May 2021 08:23:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:56480 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234419AbhE0MXN (ORCPT ); Thu, 27 May 2021 08:23:13 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9C935610CC; Thu, 27 May 2021 12:21:40 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lmF18-003wQi-Mx; Thu, 27 May 2021 13:21:38 +0100 Date: Thu, 27 May 2021 13:21:38 +0100 Message-ID: <87wnrks6y5.wl-maz@kernel.org> From: Marc Zyngier To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Lorenzo Pieralisi , Vincenzo Frascino Subject: Re: [RFC PATCH v2 09/10] irqchip/gic: Convert to handle_strict_flow_irq() In-Reply-To: <20210525173255.620606-10-valentin.schneider@arm.com> References: <20210525173255.620606-1-valentin.schneider@arm.com> <20210525173255.620606-10-valentin.schneider@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: valentin.schneider@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, lorenzo.pieralisi@arm.com, vincenzo.frascino@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 25 May 2021 18:32:54 +0100, Valentin Schneider wrote: > > Now that the proper infrastructure is in place, convert the irq-gic chip to > use handle_strict_flow_irq() along with IRQCHIP_AUTOMASKS_FLOW. > > For EOImode=1, the Priority Drop is moved from gic_handle_irq() into > chip->irq_ack(). This effectively pushes the EOI write down into > ->handle_irq(), but doesn't change its ordering wrt the irqaction > handling. > > The EOImode=1 irqchip also gains IRQCHIP_EOI_THREADED, which allows the > ->irq_eoi() call to be deferred to the tail of ONESHOT IRQ threads. This > means a threaded ONESHOT IRQ can now be handled entirely without a single > chip->irq_mask() call. > > EOImode=0 handling remains unchanged. > > Signed-off-by: Valentin Schneider > --- > drivers/irqchip/irq-gic.c | 14 +++++++++++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > index b1d9c22caf2e..4919478c3e41 100644 > --- a/drivers/irqchip/irq-gic.c > +++ b/drivers/irqchip/irq-gic.c > @@ -344,8 +344,6 @@ static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs) > if (unlikely(irqnr >= 1020)) > break; > > - if (static_branch_likely(&supports_deactivate_key)) > - writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI); > isb(); > > /* > @@ -1012,7 +1010,9 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq, > break; > default: > irq_domain_set_info(d, irq, hw, &gic->chip, d->host_data, > - handle_fasteoi_irq, NULL, NULL); > + static_branch_likely(&supports_deactivate_key) ? > + handle_strict_flow_irq : handle_fasteoi_irq, > + NULL, NULL); > irq_set_probe(irq); > irqd_set_single_target(irqd); > break; > @@ -1116,8 +1116,16 @@ static void gic_init_chip(struct gic_chip_data *gic, struct device *dev, > > if (use_eoimode1) { > gic->chip.irq_mask = gic_eoimode1_mask_irq; > + gic->chip.irq_ack = gic_eoi_irq; > gic->chip.irq_eoi = gic_eoimode1_eoi_irq; > gic->chip.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity; > + > + /* > + * eoimode0 shouldn't expose FLOW_MASK because the priority > + * drop is undissociable from the deactivation, and we do need > + * the priority drop to happen within the flow handler. > + */ > + gic->chip.flags |= IRQCHIP_AUTOMASKS_FLOW | IRQCHIP_EOI_THREADED; > } > > if (gic == &gic_data[0]) { How about GICv2M, GICv3-MBI, and the collection of widget that build a domain on top of a GIC domain? I'm worried that they now all need updating one way or another... M. -- Without deviation from the norm, progress is not possible. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28077C47089 for ; Thu, 27 May 2021 12:23:11 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E2FFA613C0 for ; Thu, 27 May 2021 12:23:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2FFA613C0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=W8RUILFSJ6PhqSf/53MbK+v/z55LyRBTM5ASoRzepD4=; b=LHFZUrU+RD1xTn KjVc3SwvL3f0YyL/5ggIXiqKNRmuPb6zWa4OiIVVwR2x2ePz8t/vhOljdaZQ/OQauoAjmzO+IJp7c 4sbKokcCqzumyZSB7/HI2fvhiLYQsa7sIEfFYsdw8vq57bshQiw2TICXhEszc+dJ1zPhNVQmGJyLq WP0dmAEGEIJcfWQuP8oEr7u44PoRtVL5NyAsxq0/Eg6i/LotV57d7zMM5jyLdYhWWnRuVfUIdfPrL 3Duved8RZECZAN+PkkBdK6Wadv1B8PK/nfFTztAid32NmJlBcxyYwC+aOTaBfRMhDJ5vcKdKWU+ve 49Ie07UG4Tf3L0S4zXgg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmF1E-005iFB-UQ; Thu, 27 May 2021 12:21:45 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmF1A-005iDP-Sg for linux-arm-kernel@lists.infradead.org; Thu, 27 May 2021 12:21:42 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9C935610CC; Thu, 27 May 2021 12:21:40 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lmF18-003wQi-Mx; Thu, 27 May 2021 13:21:38 +0100 Date: Thu, 27 May 2021 13:21:38 +0100 Message-ID: <87wnrks6y5.wl-maz@kernel.org> From: Marc Zyngier To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Thomas Gleixner , Lorenzo Pieralisi , Vincenzo Frascino Subject: Re: [RFC PATCH v2 09/10] irqchip/gic: Convert to handle_strict_flow_irq() In-Reply-To: <20210525173255.620606-10-valentin.schneider@arm.com> References: <20210525173255.620606-1-valentin.schneider@arm.com> <20210525173255.620606-10-valentin.schneider@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: valentin.schneider@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, lorenzo.pieralisi@arm.com, vincenzo.frascino@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210527_052140_993420_6952E642 X-CRM114-Status: GOOD ( 31.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 25 May 2021 18:32:54 +0100, Valentin Schneider wrote: > > Now that the proper infrastructure is in place, convert the irq-gic chip to > use handle_strict_flow_irq() along with IRQCHIP_AUTOMASKS_FLOW. > > For EOImode=1, the Priority Drop is moved from gic_handle_irq() into > chip->irq_ack(). This effectively pushes the EOI write down into > ->handle_irq(), but doesn't change its ordering wrt the irqaction > handling. > > The EOImode=1 irqchip also gains IRQCHIP_EOI_THREADED, which allows the > ->irq_eoi() call to be deferred to the tail of ONESHOT IRQ threads. This > means a threaded ONESHOT IRQ can now be handled entirely without a single > chip->irq_mask() call. > > EOImode=0 handling remains unchanged. > > Signed-off-by: Valentin Schneider > --- > drivers/irqchip/irq-gic.c | 14 +++++++++++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > index b1d9c22caf2e..4919478c3e41 100644 > --- a/drivers/irqchip/irq-gic.c > +++ b/drivers/irqchip/irq-gic.c > @@ -344,8 +344,6 @@ static void __exception_irq_entry gic_handle_irq(struct pt_regs *regs) > if (unlikely(irqnr >= 1020)) > break; > > - if (static_branch_likely(&supports_deactivate_key)) > - writel_relaxed(irqstat, cpu_base + GIC_CPU_EOI); > isb(); > > /* > @@ -1012,7 +1010,9 @@ static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq, > break; > default: > irq_domain_set_info(d, irq, hw, &gic->chip, d->host_data, > - handle_fasteoi_irq, NULL, NULL); > + static_branch_likely(&supports_deactivate_key) ? > + handle_strict_flow_irq : handle_fasteoi_irq, > + NULL, NULL); > irq_set_probe(irq); > irqd_set_single_target(irqd); > break; > @@ -1116,8 +1116,16 @@ static void gic_init_chip(struct gic_chip_data *gic, struct device *dev, > > if (use_eoimode1) { > gic->chip.irq_mask = gic_eoimode1_mask_irq; > + gic->chip.irq_ack = gic_eoi_irq; > gic->chip.irq_eoi = gic_eoimode1_eoi_irq; > gic->chip.irq_set_vcpu_affinity = gic_irq_set_vcpu_affinity; > + > + /* > + * eoimode0 shouldn't expose FLOW_MASK because the priority > + * drop is undissociable from the deactivation, and we do need > + * the priority drop to happen within the flow handler. > + */ > + gic->chip.flags |= IRQCHIP_AUTOMASKS_FLOW | IRQCHIP_EOI_THREADED; > } > > if (gic == &gic_data[0]) { How about GICv2M, GICv3-MBI, and the collection of widget that build a domain on top of a GIC domain? I'm worried that they now all need updating one way or another... M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel