Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp359370pxb; Thu, 21 Jan 2021 08:45:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJx4F51R+Qp04kn+OUafk4WZDzY+7yadp+RkEUDu7LPovbbhsnwPOjnseJquD+Bdjz54Hsa5 X-Received: by 2002:a17:906:a011:: with SMTP id p17mr254424ejy.30.1611247547848; Thu, 21 Jan 2021 08:45:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611247547; cv=none; d=google.com; s=arc-20160816; b=PilC4zhomBP5g3GhWou0l2YQmBFZACqJ+RQ/37EVWp7HMJaU5G7aoL9GliswwhxWLL S22h22az99dPPQnbTOs9PdH9LGzbeB2lByfOxZb51Lr1QpXuXkMQ7mhoLKQTAc1Nty9c oMpZlfQm22w5kJCzsswIRzTiF/Qu4DyP0ax8YA1kKOMGqjcOJ7yxA5D7UbSpBZVIXwg6 MY8RjEc7C9gl7cKQqOwlsRErNHzc39pVwifb8TLjjLvraYY4BTz10oRPZT+U+QUaHuAU DzjeTWbkQvgaxwLU4RRGqWKQGyokq98FuSbME4jCgeXwFGnDMc0ZY13/m1MpuVJMkJ1m dR+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=0EpdrgDEmk80zucIC6GKlJcrLMiTCTWImNbcEMClT6k=; b=muwooULZ4Ds4rytV2zheh8hxXNJAcEqVop05Sq/kS8wjYsYgWQ8eWMzFIxu6vackQB mdTDz1jkBxbK8hLO3eZ5+WT3DEqoZIHc+FrrInwqIDiz4wD7PNBn8hc5ETkS8BpaZws9 AE74N2DsOfhE0MYDG5hmMmwdHEILdHHfNyu4CN1HhXYIjeXCbNzWfy+9UOybULnlalDn cGQTzomU3PN+fv5lnRW8fg2gSWm2mBWM/jYS5gkWTCLLSaXy6Gjjws2B4mK6BXOcgTfJ PyDJsUqXXbrHxa1mE/x0ExHa1UVGG78kK7sFDWgt/3wTnbOaa14GcHlEftW3xQHCYpbS zU1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RKPz+W5d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v24si2356293edx.601.2021.01.21.08.45.21; Thu, 21 Jan 2021 08:45:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RKPz+W5d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388192AbhAUQne (ORCPT + 99 others); Thu, 21 Jan 2021 11:43:34 -0500 Received: from mail.kernel.org ([198.145.29.99]:34274 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733096AbhAUQlP (ORCPT ); Thu, 21 Jan 2021 11:41:15 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2A09523A54 for ; Thu, 21 Jan 2021 16:40:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611247233; bh=puSY6uhE0WSvNJj3Ra4/jrZiRTQj5xzHz1Mnh6amjVA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=RKPz+W5dnwEknFMKsoy4SzAS4BJvarJlMokvPGn5I3ULtVf6wtfIV3pY6x5zaXtyf Zs1OEGM08q88qQIR0u6zo1QjnDsFfdx8dzq4SrDVCw+3lErDLAWwOgWb7LLQFJD6UG dr+/hDcChz/YFYQmNhXr9Z2ZLLh0XQnlDtO68kevFT2DwW0osXriBljLxmGmCTZ5s7 Sy+2ZOSgjekIvoTHGa+4rCg4n+UgzmHP6Y0xdOv1r93LdquilGRyyQyxNlAZ65Vbw+ kv8QoIfxAQJTPj4UwLzKwXL9/kblg2zVymsNbHmJ9O8T3pxMBQtcLhV64Hbmtwp7/j GrvTJiPsP/E7A== Received: by mail-ed1-f49.google.com with SMTP id b2so3267497edm.3 for ; Thu, 21 Jan 2021 08:40:33 -0800 (PST) X-Gm-Message-State: AOAM5335ERds/WRXJru3LyXcHsCKuPxYwQ0HJ4buj+/R8GjShJ+VSnuj CXLtM7Ep/LsNPYOLFYgcuYSkcRWhx/lF6ppxUQ== X-Received: by 2002:a50:e78b:: with SMTP id b11mr11884224edn.165.1611247231619; Thu, 21 Jan 2021 08:40:31 -0800 (PST) MIME-Version: 1.0 References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-8-mohamed.mediouni@caramail.com> In-Reply-To: From: Rob Herring Date: Thu, 21 Jan 2021 10:40:17 -0600 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: Arnd Bergmann , Mark Rutland , Catalin Marinas , Hector Martin , "linux-kernel@vger.kernel.org" , Marc Zyngier , Will Deacon , Linux ARM , Stan Skowronek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 21, 2021 at 6:52 AM Mohamed Mediouni wrote: > > > > > On 21 Jan 2021, at 13:44, Arnd Bergmann wrote: > > > > 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 =3D get_cpu(); > >> + if (aic.fast_ipi) { > >> + if ((lcpu >> 2) =3D=3D (cpu >> 2)) > >> + write_sysreg(cpu & 3, SR_APPLE_IPI_LOC= AL); > >> + else > >> + write_sysreg((cpu & 3) | ((cpu >> 2) <= < 16), > >> + SR_APPLE_IPI_REMOTE); > >> + } else > >> + writel(lcpu =3D=3D 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_no= de *node, > >> if (WARN(!aic.base, "unable to map aic registers\n")) > >> return -EINVAL; > >> > >> + aic.fast_ipi =3D of_property_read_bool(node, "fast-ipi"); > > > > Where is this property documented, and what decides which one to use? > It=E2=80=99s getting documented in the next patch set. > > This property is there to enable support for older iPhone processors > later on, some of which do not have fast IPI support. > > On Apple M1, fast-ipi is always on. This should be implied by the compatible string which needs to be more specific and include the SoC name. Rob