From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 605E7205509 for ; Thu, 27 Mar 2025 08:25:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743063918; cv=none; b=H+ymWZV14Q4x33quyyxMEqR7y8iJuV9YlWMJOEIHsjbDTeHQgKyv9tffLbRMNVu9VbyGf11UapovZTCuWOHNhxaUQ3rCNZnrZxZjtAoav6YCmZaAMnWHmjz7KvWIs8Cn68kQ48lwjbZIObUWUEEUYDWXxztVWhvAoPBufjN5Puc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743063918; c=relaxed/simple; bh=E7zPgzfPfjWChkoZxx0xsF7whNgUH9/RUX/J5vZ4fls=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=O9PB2fEINn75+qa5LDYc1nHs1dTTM+PKo2BRrXb0cpI4LVnNSWZUEGLnc0Sh1w8Yplf4cbiu8gaAv7/swginKFG187MOco04pbZKqXzdAm7/hf3ZgnCREivrwK1wNuaAmj6ahnC38XVkVhVeUeXZsd9wgEM1tETC9sy8v9Quuco= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=puwLlFwB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="puwLlFwB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBA68C4CEDD; Thu, 27 Mar 2025 08:25:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743063917; bh=E7zPgzfPfjWChkoZxx0xsF7whNgUH9/RUX/J5vZ4fls=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=puwLlFwBVOi6sLqNrSD827/Ir7tJsswtweFGXkgdN8in4W92OBkuvqNT2c9FyI0DL Ld1X0btkcwWR5zM6TvAeLMwhdMl2YloTw2OUzJYLOgWes+8GovnVY5+SLijsIqlSm8 vvF4HJO8hgvxFUF8JpjKylQvKNFBKkXNSrSy2xVhDloMlC5XpojjmYUzlKRB+zD9Ii E0L4M4aeezLKj+zRFGGS3sgs9iXGtYWi11RImE71/nP7MAJ8t2H6C8H03+SWVhV++d 9Nxpwu0ht1dM/JeMXUoUDEqlng7pNOsXcqohVKa/CqyevAyeaii3O4w5s+o9jB7aaP SvoWDYXk0Zc8g== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1txiY7-00HYK5-5k; Thu, 27 Mar 2025 08:25:15 +0000 Date: Thu, 27 Mar 2025 08:25:14 +0000 Message-ID: <86v7rulw2d.wl-maz@kernel.org> From: Marc Zyngier To: Youngmin Nam Cc: Thomas Gleixner , Saravana Kannan , Ulf Hansson , Vincent Guittot , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com, hajun.sung@samsung.com, d7271.choe@samsung.com, joonki.min@samsung.com Subject: Re: [GICv3 ITS]S2IDLE framework does not invoke syscore_ops in GICv3 ITS driver In-Reply-To: References: <8634f0mall.wl-maz@kernel.org> 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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: youngmin.nam@samsung.com, tglx@linutronix.de, saravanak@google.com, ulf.hansson@linaro.org, vincent.guittot@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com, hajun.sung@samsung.com, d7271.choe@samsung.com, joonki.min@samsung.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 27 Mar 2025 03:22:19 +0000, Youngmin Nam wrote: >=20 > [1 ] > On Wed, Mar 26, 2025 at 08:59:02AM +0000, Marc Zyngier wrote: > > On Wed, 26 Mar 2025 03:09:37 +0000, > > Youngmin Nam wrote: > > >=20 > > > Hi. > > >=20 > > > On our SoC, we are using S2IDLE instead of S2R as a system suspend mo= de. > > > However, when I try to enable ARM GICv3 ITS driver (drivers/irqchip/i= rq-gic-v3-its.c), > > > I noticed that there is no proper way to invoke suspend/resume callba= ck, > > > because it only uses syscore_ops, which is not called in an s2idle sc= enario. > >=20 > > This is *by design*. [...] > > > How should we handle this situation ? > >=20 > > By implementing anything related to GIC power-management in your EL3 > > firmware. Only your firmware knows whether you are going into a state > > where the GIC (and the ITS) is going to lose its state (because power > > is going to be removed) or if the sleep period is short enough that > > you can come back from idle without loss of context. > >=20 > > Furthermore, there is a lot of things that non-secure cannot do when > > it comes to GIC power management (most the controls are secure only), > > so it is pretty clear that the kernel is the wrong place for this. > >=20 > > I'd suggest you look at what TF-A provides, because this is not > > exactly a new problem (it has been solved several years ago). > >=20 > > M. > >=20 > > --=20 > > Without deviation from the norm, progress is not possible. > >=20 >=20 > Hi Marc, >=20 > First of all, I=E2=80=99d like to distinguish between the GICv3 driver (i= rq-gic-v3.c) > and the ITS driver (irq-gic-v3-its.c). >=20 > I now understand why the GICv3 driver doesn=E2=80=99t implement suspend a= nd resume functions. > However, unlike the GICv3 driver, the ITS driver currently provides > suspend and resume functions via syscore_ops in the kernel. For *suspend*. The real suspend. Not a glorified WFI. And that's only for situations where we know for sure that we are going to suspend. > And AFAIK, LPIs are always treated as non-secure. (Please correct me If I= 'm wrong). >=20 > The problem is that syscore_ops is not invoked during the S2IDLE scenario, > so we cannot rely on it in that context. > We would like to use these suspend/resume functions during S2IDLE as well. Again, this is *by design*. There is no semantic difference between s2idle and normal idle. They are the same thing. Do you really want to save/restore the whole ITS state on each and every call into idle? Absolutely not. Only your firmware knows how deep you will be suspended, and how long you will be suspended for, and this is the right place for to perform save/restore of the ITS state. Not in generic code that runs on every arm64 platform on the planet. M. --=20 Without deviation from the norm, progress is not possible.