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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 86025C433F5 for ; Mon, 20 Sep 2021 08:10:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6873D610A3 for ; Mon, 20 Sep 2021 08:10:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235388AbhITILu (ORCPT ); Mon, 20 Sep 2021 04:11:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235380AbhITILp (ORCPT ); Mon, 20 Sep 2021 04:11:45 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3A79C061574 for ; Mon, 20 Sep 2021 01:10:17 -0700 (PDT) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mSENM-0008In-7n; Mon, 20 Sep 2021 10:10:08 +0200 Message-ID: <9fae7a66f4d9c709897586fcf8f26e5863d01bf4.camel@pengutronix.de> Subject: Re: [PATCH] arm64: dts: imx8mm-kontron-n801x-som: do not allow to switch off buck2 From: Lucas Stach To: Michael Walle , Frieder Schrempf , Heiko Thiery Cc: devicetree@vger.kernel.org, Guido =?ISO-8859-1?Q?G=FCnther?= , Fabio Estevam , Shengjiu Wang , "Angus Ainslie (Purism)" , linux-kernel@vger.kernel.org, Krzysztof Kozlowski , Joakim Zhang , Rob Herring , NXP Linux Team , Pengutronix Kernel Team , Shawn Guo , Sascha Hauer , linux-arm-kernel@lists.infradead.org Date: Mon, 20 Sep 2021 10:10:05 +0200 In-Reply-To: <447B96FA-2B75-4C72-A72B-1C1D29137B2C@walle.cc> References: <20210915120325.20248-1-heiko.thiery@gmail.com> <7e7ee4244ababc0a46e0875222c7e37d@walle.cc> <898fd5e0-2073-3689-89b6-2c5071773786@kontron.de> <9bcf7b749dca57d42aa2e7afd88b5a26f3eeff2a.camel@pengutronix.de> <447B96FA-2B75-4C72-A72B-1C1D29137B2C@walle.cc> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Montag, dem 20.09.2021 um 09:43 +0200 schrieb Michael Walle: > Am 20. September 2021 09:31:20 MESZ schrieb Frieder Schrempf : > > On 17.09.21 18:10, Heiko Thiery wrote: > > > Hi Lucas, > > > > > > Am Fr., 17. Sept. 2021 um 13:44 Uhr schrieb Lucas Stach > > > : > > > > > > > > Am Freitag, dem 17.09.2021 um 09:28 +0200 schrieb Heiko Thiery: > > > > > Hi Frieder, > > > > > > > > > > Am Mi., 15. Sept. 2021 um 14:09 Uhr schrieb Frieder Schrempf > > > > > : > > > > > > > > > > > > On 15.09.21 14:05, Michael Walle wrote: > > > > > > > Am 2021-09-15 14:03, schrieb Heiko Thiery: > > > > > > > > The buck2 output of the PMIC is the VDD core voltage of the cpu. > > > > > > > > Switching off this will poweroff the CPU. Add the 'regulator-always-on' > > > > > > > > property to avoid this. > > > > > > > > > > > > > > Mh, have this ever worked? Is there a commit which introduced a regression? > > > > > > > > > > > > Yes, this did work before, even without 'regulator-always-on'. I > > > > > > currently don't understand why this is needed. The regulator is > > > > > > referenced in the CPU nodes as 'cpu-supply'. This should be enough to > > > > > > not disable it as long as the CPU is up. > > > > > > > > > > I rechecked that with 5.11, 5.10 and 5.9 and I see on all of them the > > > > > same issue: > > > > > > > > > > [ 31.716031] vdd-5v: disabling > > > > > [ 31.719032] rst-usb-eth2: disabling > > > > > [ 31.722553] buck2: disabling > > > > > > > > > > While on that I tried to compare with other boards and see that they > > > > > also have the cpu-voltage marked as "regulator-always-on". The only > > > > > exception in dts/freescale is in imx8mq-librem5-devkit.dts [1] that > > > > > has not set this property. > > > > > > > > > > I agree with you and don't understand why this is happening. Has > > > > > anyone else an explanation? > > > > > > > > > > [1] https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Farch%2Farm64%2Fboot%2Fdts%2Ffreescale%2Fimx8mq-librem5-devkit.dts%23L319&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7Cce9d266ad78a4d06721008d979f5aeed%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637674918380815550%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PsTKX4MXGwvvP6WxmQ1OWc8e32YI6Nsu%2FEkcNR4V8is%3D&reserved=0 > > > > > > > > > Maybe your kernel config is missing the cpufreq driver, so you don't > > > > have a consumer of the regulator? > > > > > > > > Marking the regulator as always-on seems like the right thing to do, > > > > you don't want to depend on a consumer showing up to make sure that > > > > your CPU voltage isn't cut... > > > > > > shouldn't it be that the node cpu-supply here is a consumer of the > > > referenced voltage? > > > > Yes, but as Michael and Lucas noted, the consumer is only active if the > > cpufreq driver is loaded and we don't want to depend on this. In my > > config I always had this compiled into the kernel so I didn't notice > > that the always-on property is missing. > > Hm. So any cpu core voltage has to have the "always-on" property? On > any SoC? Shouldn't there be some code to prevent the disabling of the > voltage if the cpu nodes have a cpu-supply phandle? Yes, all regulators that must not be shut down for proper system operation must be marked as always-on. Just because it is a CPU supply doesn't make it special in any way. Otherwise where would you stop with adding special code to keep supplies enabled without a consumer? Have code to keep the DDR memory regulators on when no DDR controller driver is loaded? Code to keep 3.3V for the board level peripherals enabled? Just mark those as always-on. Regards, Lucas 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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 3AD6CC433EF for ; Mon, 20 Sep 2021 08:12:27 +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 0178E60462 for ; Mon, 20 Sep 2021 08:12:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0178E60462 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=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: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=YzHT8NpMNWn7ciCC7p4nDtrBezXjy0iAPvWqP49DTMo=; b=tNDZ5IecQQrDHq re/v8LT/78S0VCAr9/mjaZI4zexbWRrXkB4apshCRnkZAcewJYRs3sZteCRhTUHlFwSE8qKbibmBv OV3qcLxd+O9IGg7rKptPqKUqtqdq4+h97jUseE+A9UxNOCknrGPXbwDjYUK4iX2P9G6DEBHGvggFI /r3C+vgZ9qFoTagoJaWTWqUAj0fPTUs7gLYPRugJE3Kj1o7PSKHP46udEHn/Johh2ZcblotFApMGA +Oxj5YcYikfCyI9MezUFRi+4QNIkm68FKpGybsGL7k9P2Vr4y/LpxG/8LJNjtjNQDFiwR9Sh65LsF x4V+4lp9KhYi9dtP4a6g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSENh-000seR-Sx; Mon, 20 Sep 2021 08:10:30 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mSENd-000scv-6v for linux-arm-kernel@lists.infradead.org; Mon, 20 Sep 2021 08:10:26 +0000 Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mSENM-0008In-7n; Mon, 20 Sep 2021 10:10:08 +0200 Message-ID: <9fae7a66f4d9c709897586fcf8f26e5863d01bf4.camel@pengutronix.de> Subject: Re: [PATCH] arm64: dts: imx8mm-kontron-n801x-som: do not allow to switch off buck2 From: Lucas Stach To: Michael Walle , Frieder Schrempf , Heiko Thiery Cc: devicetree@vger.kernel.org, Guido =?ISO-8859-1?Q?G=FCnther?= , Fabio Estevam , Shengjiu Wang , "Angus Ainslie (Purism)" , linux-kernel@vger.kernel.org, Krzysztof Kozlowski , Joakim Zhang , Rob Herring , NXP Linux Team , Pengutronix Kernel Team , Shawn Guo , Sascha Hauer , linux-arm-kernel@lists.infradead.org Date: Mon, 20 Sep 2021 10:10:05 +0200 In-Reply-To: <447B96FA-2B75-4C72-A72B-1C1D29137B2C@walle.cc> References: <20210915120325.20248-1-heiko.thiery@gmail.com> <7e7ee4244ababc0a46e0875222c7e37d@walle.cc> <898fd5e0-2073-3689-89b6-2c5071773786@kontron.de> <9bcf7b749dca57d42aa2e7afd88b5a26f3eeff2a.camel@pengutronix.de> <447B96FA-2B75-4C72-A72B-1C1D29137B2C@walle.cc> User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210920_011025_312449_64F874D1 X-CRM114-Status: GOOD ( 34.52 ) 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 Am Montag, dem 20.09.2021 um 09:43 +0200 schrieb Michael Walle: > Am 20. September 2021 09:31:20 MESZ schrieb Frieder Schrempf : > > On 17.09.21 18:10, Heiko Thiery wrote: > > > Hi Lucas, > > > > > > Am Fr., 17. Sept. 2021 um 13:44 Uhr schrieb Lucas Stach > > > : > > > > > > > > Am Freitag, dem 17.09.2021 um 09:28 +0200 schrieb Heiko Thiery: > > > > > Hi Frieder, > > > > > > > > > > Am Mi., 15. Sept. 2021 um 14:09 Uhr schrieb Frieder Schrempf > > > > > : > > > > > > > > > > > > On 15.09.21 14:05, Michael Walle wrote: > > > > > > > Am 2021-09-15 14:03, schrieb Heiko Thiery: > > > > > > > > The buck2 output of the PMIC is the VDD core voltage of the cpu. > > > > > > > > Switching off this will poweroff the CPU. Add the 'regulator-always-on' > > > > > > > > property to avoid this. > > > > > > > > > > > > > > Mh, have this ever worked? Is there a commit which introduced a regression? > > > > > > > > > > > > Yes, this did work before, even without 'regulator-always-on'. I > > > > > > currently don't understand why this is needed. The regulator is > > > > > > referenced in the CPU nodes as 'cpu-supply'. This should be enough to > > > > > > not disable it as long as the CPU is up. > > > > > > > > > > I rechecked that with 5.11, 5.10 and 5.9 and I see on all of them the > > > > > same issue: > > > > > > > > > > [ 31.716031] vdd-5v: disabling > > > > > [ 31.719032] rst-usb-eth2: disabling > > > > > [ 31.722553] buck2: disabling > > > > > > > > > > While on that I tried to compare with other boards and see that they > > > > > also have the cpu-voltage marked as "regulator-always-on". The only > > > > > exception in dts/freescale is in imx8mq-librem5-devkit.dts [1] that > > > > > has not set this property. > > > > > > > > > > I agree with you and don't understand why this is happening. Has > > > > > anyone else an explanation? > > > > > > > > > > [1] https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Farch%2Farm64%2Fboot%2Fdts%2Ffreescale%2Fimx8mq-librem5-devkit.dts%23L319&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7Cce9d266ad78a4d06721008d979f5aeed%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637674918380815550%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PsTKX4MXGwvvP6WxmQ1OWc8e32YI6Nsu%2FEkcNR4V8is%3D&reserved=0 > > > > > > > > > Maybe your kernel config is missing the cpufreq driver, so you don't > > > > have a consumer of the regulator? > > > > > > > > Marking the regulator as always-on seems like the right thing to do, > > > > you don't want to depend on a consumer showing up to make sure that > > > > your CPU voltage isn't cut... > > > > > > shouldn't it be that the node cpu-supply here is a consumer of the > > > referenced voltage? > > > > Yes, but as Michael and Lucas noted, the consumer is only active if the > > cpufreq driver is loaded and we don't want to depend on this. In my > > config I always had this compiled into the kernel so I didn't notice > > that the always-on property is missing. > > Hm. So any cpu core voltage has to have the "always-on" property? On > any SoC? Shouldn't there be some code to prevent the disabling of the > voltage if the cpu nodes have a cpu-supply phandle? Yes, all regulators that must not be shut down for proper system operation must be marked as always-on. Just because it is a CPU supply doesn't make it special in any way. Otherwise where would you stop with adding special code to keep supplies enabled without a consumer? Have code to keep the DDR memory regulators on when no DDR controller driver is loaded? Code to keep 3.3V for the board level peripherals enabled? Just mark those as always-on. Regards, Lucas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel