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=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 9A2BCC433E0 for ; Thu, 21 Jan 2021 12:47:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3F2A823A01 for ; Thu, 21 Jan 2021 12:47:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731183AbhAUMr4 (ORCPT ); Thu, 21 Jan 2021 07:47:56 -0500 Received: from mail.kernel.org ([198.145.29.99]:60288 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731298AbhAUMpQ (ORCPT ); Thu, 21 Jan 2021 07:45:16 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id B3E20239FF for ; Thu, 21 Jan 2021 12:44:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611233074; bh=myULDxLA57azPbQV/b8fZy9KYbD60iB/nUkEu01fjvc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TBr3PDGjSGNlQHaYgWN56fsatwC3dfS9HVIUCDgezfKgOFXzA7Db3bxB6hvWkhee2 MMArq9NgrkuINVYKQ/26jtPQxWBoyHGrIGNcFBrD8B/5xV84ADsaJ60AXLu70T4Y9y ZsD+K0SexIZZ+Nd1zHQueQOOPa6TXYZzW8Km848tMlVlmM7DHj5X9WG2JIc3d2d/OG j+g2FwSUMXqjjUbzWyv1j5ZyDFQB8tc6Sq7VJJIq+b8DTG7vw1IxQqOmGDZFIiNSQm 21ogVXjQ6EIYcz90a+N2DWVDZDhc2ft0/0ln0MuoEqzGTm+VT5biJZ+vuqq2mV6qsG XJrd/Hp6sT7lA== Received: by mail-ot1-f48.google.com with SMTP id v1so1425970ott.10 for ; Thu, 21 Jan 2021 04:44:34 -0800 (PST) X-Gm-Message-State: AOAM530PHLc4rqr5/p01Dz4iz14MUfqdBvq9DwKQKn4AHUkMOHwWStvb yEjd/p77OH3jo26gw/9AiOjRL/95NpBcz1v30iI= X-Google-Smtp-Source: ABdhPJwLKTUzkB8CP1EzpBdWoaJP4pt2eCRtFjV0UOYIXGY7x5yVsPgKDybYei9Z5/D76Lw031hliJrud2qIQjmQZto= X-Received: by 2002:a05:6830:139a:: with SMTP id d26mr10307664otq.305.1611233073918; Thu, 21 Jan 2021 04:44:33 -0800 (PST) MIME-Version: 1.0 References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-8-mohamed.mediouni@caramail.com> In-Reply-To: <20210120132717.395873-8-mohamed.mediouni@caramail.com> From: Arnd Bergmann Date: Thu, 21 Jan 2021 13:44:17 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 7/7] irqchip/apple-aic: add SMP support to the Apple AIC driver. To: Mohamed Mediouni Cc: Linux ARM , Mark Rutland , Catalin Marinas , Hector Martin , "linux-kernel@vger.kernel.org" , Marc Zyngier , Will Deacon , Stan Skowronek Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 20, 2021 at 2:27 PM Mohamed Mediouni wrote: > +#ifdef CONFIG_SMP > +static void apple_aic_ipi_send_mask(struct irq_data *d, > + const struct cpumask *mask) Not sure we care about the #ifdef here, given that arch/arm64 does not allow building a kernel without CONFIG_SMP. > + /* > + * Ensure that stores to Normal memory are visible to the > + * other CPUs before issuing the IPI. > + */ > + wmb(); > + > + for_each_cpu (cpu, mask) { > + smp_mb__before_atomic(); > + atomic_or(1u << irqnr, per_cpu_ptr(&aic_ipi_mask, cpu)); > + smp_mb__after_atomic(); > + lcpu = get_cpu(); > + if (aic.fast_ipi) { > + if ((lcpu >> 2) == (cpu >> 2)) > + write_sysreg(cpu & 3, SR_APPLE_IPI_LOCAL); > + else > + write_sysreg((cpu & 3) | ((cpu >> 2) << 16), > + SR_APPLE_IPI_REMOTE); > + } else > + writel(lcpu == cpu ? REG_IPI_FLAG_SELF : > + (REG_IPI_FLAG_OTHER << cpu), > + aic.base + REG_IPI_SET); > + put_cpu(); > + } > + > + /* Force the above writes to be executed */ > + if (aic.fast_ipi) > + isb(); > +} Since this just loops over all CPUs, I'd probably just turn it into an ipi_send_single() callback and have the caller do the loop for simplicity. I also have the feeling that splitting one hardware IPI into multiple logical interrupts, which are then all registered by the same irq handler adds a little more complexity than necessary. Changing this would of course require modifications to arch/arm64/kernel/smp.c, which is hardwired to use CONFIG_GENERIC_IRQ_IPI in smp_cross_call(), and allowing a different code path there may be worse than emulating an irqchip. > @@ -186,8 +325,11 @@ static int __init apple_aic_init(struct device_node *node, > if (WARN(!aic.base, "unable to map aic registers\n")) > return -EINVAL; > > + aic.fast_ipi = of_property_read_bool(node, "fast-ipi"); Where is this property documented, and what decides which one to use? Arnd 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=-9.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 2830FC433DB for ; Thu, 21 Jan 2021 12:46:33 +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 B1057239FF for ; Thu, 21 Jan 2021 12:46:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B1057239FF 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SzdRTv7lcP7l4T8zuOkQbhvebG5JYIPRxtA+l5eWtPI=; b=HdUl3ZS5GsWofyNV583PjpKTw dmJt3NxhJE5bpSXys7xqP3ukCPNPxncmVC9hqRNYw8et+rriDjmxhCoT3zJl6Yt2YHfs7lZM+4fA7 8raAX0n/tdjBLSBufBbHaaaWnWJ4FRzuRWx1Klw3b16KIRwnWXNiEBIaXN/IuATGsQ9Q6aBQfz8Xw ajs+qyWkjrCDryZtx15/CaL1u89ZcprsRDfjeepRaMNWL290OvbQJmJtdgk3A9qSP4FeAbtqvOz6j miDtXXZxMGrRCmfUpdSZwbb/dnot8SyBwBeTiLKdWOW+ivsbrRhZLR+DTuMRkGjQnVa12x8dnK7YT EwhkgyPjg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2ZKN-0000sT-Fn; Thu, 21 Jan 2021 12:44:44 +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 1l2ZKG-0000pu-Fc for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 12:44:37 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id BE7AC23A1C for ; Thu, 21 Jan 2021 12:44:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611233074; bh=myULDxLA57azPbQV/b8fZy9KYbD60iB/nUkEu01fjvc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=TBr3PDGjSGNlQHaYgWN56fsatwC3dfS9HVIUCDgezfKgOFXzA7Db3bxB6hvWkhee2 MMArq9NgrkuINVYKQ/26jtPQxWBoyHGrIGNcFBrD8B/5xV84ADsaJ60AXLu70T4Y9y ZsD+K0SexIZZ+Nd1zHQueQOOPa6TXYZzW8Km848tMlVlmM7DHj5X9WG2JIc3d2d/OG j+g2FwSUMXqjjUbzWyv1j5ZyDFQB8tc6Sq7VJJIq+b8DTG7vw1IxQqOmGDZFIiNSQm 21ogVXjQ6EIYcz90a+N2DWVDZDhc2ft0/0ln0MuoEqzGTm+VT5biJZ+vuqq2mV6qsG XJrd/Hp6sT7lA== Received: by mail-ot1-f46.google.com with SMTP id k8so1434779otr.8 for ; Thu, 21 Jan 2021 04:44:34 -0800 (PST) X-Gm-Message-State: AOAM530wb5eYg+9O+lQhtME51GsWlcdqoDUElh+1x6VX67i0OciU1e4l wtGAPt70csA2P7sq3QlaDnu79kH374GuzYgbFKQ= X-Google-Smtp-Source: ABdhPJwLKTUzkB8CP1EzpBdWoaJP4pt2eCRtFjV0UOYIXGY7x5yVsPgKDybYei9Z5/D76Lw031hliJrud2qIQjmQZto= X-Received: by 2002:a05:6830:139a:: with SMTP id d26mr10307664otq.305.1611233073918; Thu, 21 Jan 2021 04:44:33 -0800 (PST) MIME-Version: 1.0 References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-8-mohamed.mediouni@caramail.com> In-Reply-To: <20210120132717.395873-8-mohamed.mediouni@caramail.com> From: Arnd Bergmann Date: Thu, 21 Jan 2021 13:44:17 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 7/7] irqchip/apple-aic: add SMP support to the Apple AIC driver. To: Mohamed Mediouni X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_074436_706315_037929D2 X-CRM114-Status: GOOD ( 18.33 ) 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: Mark Rutland , Catalin Marinas , Hector Martin , "linux-kernel@vger.kernel.org" , Marc Zyngier , Will Deacon , Linux ARM , Stan Skowronek 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 Wed, Jan 20, 2021 at 2:27 PM Mohamed Mediouni wrote: > +#ifdef CONFIG_SMP > +static void apple_aic_ipi_send_mask(struct irq_data *d, > + const struct cpumask *mask) Not sure we care about the #ifdef here, given that arch/arm64 does not allow building a kernel without CONFIG_SMP. > + /* > + * Ensure that stores to Normal memory are visible to the > + * other CPUs before issuing the IPI. > + */ > + wmb(); > + > + for_each_cpu (cpu, mask) { > + smp_mb__before_atomic(); > + atomic_or(1u << irqnr, per_cpu_ptr(&aic_ipi_mask, cpu)); > + smp_mb__after_atomic(); > + lcpu = get_cpu(); > + if (aic.fast_ipi) { > + if ((lcpu >> 2) == (cpu >> 2)) > + write_sysreg(cpu & 3, SR_APPLE_IPI_LOCAL); > + else > + write_sysreg((cpu & 3) | ((cpu >> 2) << 16), > + SR_APPLE_IPI_REMOTE); > + } else > + writel(lcpu == cpu ? REG_IPI_FLAG_SELF : > + (REG_IPI_FLAG_OTHER << cpu), > + aic.base + REG_IPI_SET); > + put_cpu(); > + } > + > + /* Force the above writes to be executed */ > + if (aic.fast_ipi) > + isb(); > +} Since this just loops over all CPUs, I'd probably just turn it into an ipi_send_single() callback and have the caller do the loop for simplicity. I also have the feeling that splitting one hardware IPI into multiple logical interrupts, which are then all registered by the same irq handler adds a little more complexity than necessary. Changing this would of course require modifications to arch/arm64/kernel/smp.c, which is hardwired to use CONFIG_GENERIC_IRQ_IPI in smp_cross_call(), and allowing a different code path there may be worse than emulating an irqchip. > @@ -186,8 +325,11 @@ static int __init apple_aic_init(struct device_node *node, > if (WARN(!aic.base, "unable to map aic registers\n")) > return -EINVAL; > > + aic.fast_ipi = of_property_read_bool(node, "fast-ipi"); Where is this property documented, and what decides which one to use? Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel