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=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS 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 EA86EC433DF for ; Tue, 30 Jun 2020 10:15:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B95AB2073E for ; Tue, 30 Jun 2020 10:15:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593512148; bh=AnrGPXZ0L3XFWcwycTfoFtiR62BIC4cXUJGTL2T6Ymk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=nZe9LyggYv+e6clouaAlFuflVllUXpVpaKMcktE9ucs9Bc8Uke36ZrDGol33n5sim 7moH/G361z/vSlbKTKt1MPhHKWevGbplhctx2eImZDK43xE7CQUwqsHillqM8bFDpc +9C+T0gnH+HU9OxAWQi/p08tgo8r10/DoBN+n62E= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732346AbgF3KPq (ORCPT ); Tue, 30 Jun 2020 06:15:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:47728 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731155AbgF3KPp (ORCPT ); Tue, 30 Jun 2020 06:15:45 -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 310812073E; Tue, 30 Jun 2020 10:15:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593512144; bh=AnrGPXZ0L3XFWcwycTfoFtiR62BIC4cXUJGTL2T6Ymk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=poSpxfVsPFzdrIYdiHqRbaXPpyDLpWpyCa/T+q7RuCj//1Y90s/jNdAltWjoJqTv5 xU3qD4C0ZpR+CUSfhDjWssLQ3KHLbtjZGOx2lOH60RKvc23lPiTTD9CCbrkIX/bqvw 2YKqpUMLl4yxpzXAH3qYmxrRyes8clDAaQsKJYc4= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jqDIk-007i3h-O9; Tue, 30 Jun 2020 11:15:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 30 Jun 2020 11:15:42 +0100 From: Marc Zyngier To: Valentin Schneider Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Will Deacon , Catalin Marinas , Russell King , Thomas Gleixner , Jason Cooper , Sumit Garg , Florian Fainelli , Gregory Clement , Andrew Lunn , kernel-team@android.com Subject: Re: [PATCH v2 06/17] irqchip/gic-v3: Configure SGIs as standard interrupts In-Reply-To: References: <20200624195811.435857-1-maz@kernel.org> <20200624195811.435857-7-maz@kernel.org> User-Agent: Roundcube Webmail/1.4.5 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: valentin.schneider@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, linux@arm.linux.org.uk, tglx@linutronix.de, jason@lakedaemon.net, sumit.garg@linaro.org, f.fainelli@gmail.com, gregory.clement@bootlin.com, andrew@lunn.ch, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-06-25 19:25, Valentin Schneider wrote: > On 24/06/20 20:58, Marc Zyngier wrote: >> Change the way we deal with GICv3 SGIs by turning them into proper >> IRQs, and calling into the arch code to register the interrupt range >> instead of a callback. >> >> Signed-off-by: Marc Zyngier >> --- >> drivers/irqchip/irq-gic-v3.c | 81 >> +++++++++++++++++++----------------- >> 1 file changed, 43 insertions(+), 38 deletions(-) >> >> diff --git a/drivers/irqchip/irq-gic-v3.c >> b/drivers/irqchip/irq-gic-v3.c >> index 19b294ed48ba..d275e9b9533d 100644 >> --- a/drivers/irqchip/irq-gic-v3.c >> +++ b/drivers/irqchip/irq-gic-v3.c >> @@ -36,6 +36,8 @@ >> #define FLAGS_WORKAROUND_GICR_WAKER_MSM8996 (1ULL << 0) >> #define FLAGS_WORKAROUND_CAVIUM_ERRATUM_38539 (1ULL << 1) >> >> +#define GIC_IRQ_TYPE_PARTITION (GIC_IRQ_TYPE_LPI + 1) >> + > > Nit: this piqued my interest but ended up being just a define shuffle; > As a > member of the git speleologists' guild, I'd be overjoyed with having a > small notion of that in the changelog. Fair enough. > >> struct redist_region { >> void __iomem *redist_base; >> phys_addr_t phys_base; >> @@ -657,38 +659,14 @@ static asmlinkage void __exception_irq_entry >> gic_handle_irq(struct pt_regs *regs >> if ((irqnr >= 1020 && irqnr <= 1023)) >> return; >> >> - /* Treat anything but SGIs in a uniform way */ >> - if (likely(irqnr > 15)) { >> - int err; >> - >> - if (static_branch_likely(&supports_deactivate_key)) >> - gic_write_eoir(irqnr); >> - else >> - isb(); >> - >> - err = handle_domain_irq(gic_data.domain, irqnr, regs); >> - if (err) { >> - WARN_ONCE(true, "Unexpected interrupt received!\n"); >> - gic_deactivate_unhandled(irqnr); >> - } >> - return; >> - } >> - if (irqnr < 16) { >> + if (static_branch_likely(&supports_deactivate_key)) >> gic_write_eoir(irqnr); >> - if (static_branch_likely(&supports_deactivate_key)) >> - gic_write_dir(irqnr); >> -#ifdef CONFIG_SMP >> - /* >> - * Unlike GICv2, we don't need an smp_rmb() here. >> - * The control dependency from gic_read_iar to >> - * the ISB in gic_write_eoir is enough to ensure >> - * that any shared data read by handle_IPI will >> - * be read after the ACK. >> - */ > > Isn't that still relevant? It is. It is just that there is no really good place to put it. I may end-up just leaving it where it is. > Also, while staring at this it dawned on me that IPI's don't need the > eoimode=0 isb(): due to how the IPI flow-handler is structured, we'll > get a > gic_eoi_irq() just before calling into the irqaction. Dunno how much we > care about it. That's interesting. This ISB is a leftover from the loop we had before the pseudo-NMI code, where we had to make sure the write to EOIR was ordered with the read from IAR. Given that we have an exception return right after the interrupt handling, I *think* we could get rid of it (but that would need mode checking on broken systems such as TX1...). I don't think this is specific to IPIs though. Thanks, M. -- Jazz is not dead. It just smells funny... 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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 21105C433E0 for ; Tue, 30 Jun 2020 10:17:25 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 E03932073E for ; Tue, 30 Jun 2020 10:17:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="alr2sbMZ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="poSpxfVs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E03932073E 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=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=V1HBjFjoOpVoy/9dOpb7KUwVXinr4z4zM19iQSdn44w=; b=alr2sbMZunpSz3/ISjVXoD0oO 39fwO/OouMjbFgqgB/2l51uwaSqsrT/OhRI6I6lDnxZzCE7yrsHIfKBdf/HXV6yw91MmVuKvgeBJq 7s53nhs5aPlDrzXivt89KqDftnO5/iNM93XbfhmDcw0fV2YKeXjTgSKA/KEADNobxlH7XdHOpFztP 2lemJzidcLPVjxyjEXon9uVR2VKKocXB6lZvODpl2a/lYlxo8R4fprRZl5v3v2emtmTNwyygzx5K2 Z70MqvN2C67QpXSx4o7rmh6vdYNbHrAHoGHt4mPA7Shxq6Eauipi16w0OPjSfxI67K9aajh17bIOX 8fl4SS/mA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqDIq-0005RA-4Q; Tue, 30 Jun 2020 10:15:48 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqDIn-0005Qq-Uu for linux-arm-kernel@lists.infradead.org; Tue, 30 Jun 2020 10:15:46 +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 310812073E; Tue, 30 Jun 2020 10:15:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593512144; bh=AnrGPXZ0L3XFWcwycTfoFtiR62BIC4cXUJGTL2T6Ymk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=poSpxfVsPFzdrIYdiHqRbaXPpyDLpWpyCa/T+q7RuCj//1Y90s/jNdAltWjoJqTv5 xU3qD4C0ZpR+CUSfhDjWssLQ3KHLbtjZGOx2lOH60RKvc23lPiTTD9CCbrkIX/bqvw 2YKqpUMLl4yxpzXAH3qYmxrRyes8clDAaQsKJYc4= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jqDIk-007i3h-O9; Tue, 30 Jun 2020 11:15:42 +0100 MIME-Version: 1.0 Date: Tue, 30 Jun 2020 11:15:42 +0100 From: Marc Zyngier To: Valentin Schneider Subject: Re: [PATCH v2 06/17] irqchip/gic-v3: Configure SGIs as standard interrupts In-Reply-To: References: <20200624195811.435857-1-maz@kernel.org> <20200624195811.435857-7-maz@kernel.org> User-Agent: Roundcube Webmail/1.4.5 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: valentin.schneider@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, linux@arm.linux.org.uk, tglx@linutronix.de, jason@lakedaemon.net, sumit.garg@linaro.org, f.fainelli@gmail.com, gregory.clement@bootlin.com, andrew@lunn.ch, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sumit Garg , Florian Fainelli , Russell King , Jason Cooper , kernel-team@android.com, Andrew Lunn , Catalin Marinas , Gregory Clement , linux-kernel@vger.kernel.org, Thomas Gleixner , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-06-25 19:25, Valentin Schneider wrote: > On 24/06/20 20:58, Marc Zyngier wrote: >> Change the way we deal with GICv3 SGIs by turning them into proper >> IRQs, and calling into the arch code to register the interrupt range >> instead of a callback. >> >> Signed-off-by: Marc Zyngier >> --- >> drivers/irqchip/irq-gic-v3.c | 81 >> +++++++++++++++++++----------------- >> 1 file changed, 43 insertions(+), 38 deletions(-) >> >> diff --git a/drivers/irqchip/irq-gic-v3.c >> b/drivers/irqchip/irq-gic-v3.c >> index 19b294ed48ba..d275e9b9533d 100644 >> --- a/drivers/irqchip/irq-gic-v3.c >> +++ b/drivers/irqchip/irq-gic-v3.c >> @@ -36,6 +36,8 @@ >> #define FLAGS_WORKAROUND_GICR_WAKER_MSM8996 (1ULL << 0) >> #define FLAGS_WORKAROUND_CAVIUM_ERRATUM_38539 (1ULL << 1) >> >> +#define GIC_IRQ_TYPE_PARTITION (GIC_IRQ_TYPE_LPI + 1) >> + > > Nit: this piqued my interest but ended up being just a define shuffle; > As a > member of the git speleologists' guild, I'd be overjoyed with having a > small notion of that in the changelog. Fair enough. > >> struct redist_region { >> void __iomem *redist_base; >> phys_addr_t phys_base; >> @@ -657,38 +659,14 @@ static asmlinkage void __exception_irq_entry >> gic_handle_irq(struct pt_regs *regs >> if ((irqnr >= 1020 && irqnr <= 1023)) >> return; >> >> - /* Treat anything but SGIs in a uniform way */ >> - if (likely(irqnr > 15)) { >> - int err; >> - >> - if (static_branch_likely(&supports_deactivate_key)) >> - gic_write_eoir(irqnr); >> - else >> - isb(); >> - >> - err = handle_domain_irq(gic_data.domain, irqnr, regs); >> - if (err) { >> - WARN_ONCE(true, "Unexpected interrupt received!\n"); >> - gic_deactivate_unhandled(irqnr); >> - } >> - return; >> - } >> - if (irqnr < 16) { >> + if (static_branch_likely(&supports_deactivate_key)) >> gic_write_eoir(irqnr); >> - if (static_branch_likely(&supports_deactivate_key)) >> - gic_write_dir(irqnr); >> -#ifdef CONFIG_SMP >> - /* >> - * Unlike GICv2, we don't need an smp_rmb() here. >> - * The control dependency from gic_read_iar to >> - * the ISB in gic_write_eoir is enough to ensure >> - * that any shared data read by handle_IPI will >> - * be read after the ACK. >> - */ > > Isn't that still relevant? It is. It is just that there is no really good place to put it. I may end-up just leaving it where it is. > Also, while staring at this it dawned on me that IPI's don't need the > eoimode=0 isb(): due to how the IPI flow-handler is structured, we'll > get a > gic_eoi_irq() just before calling into the irqaction. Dunno how much we > care about it. That's interesting. This ISB is a leftover from the loop we had before the pseudo-NMI code, where we had to make sure the write to EOIR was ordered with the read from IAR. Given that we have an exception return right after the interrupt handling, I *think* we could get rid of it (but that would need mode checking on broken systems such as TX1...). I don't think this is specific to IPIs though. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel