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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, 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 94FBAC433FE for ; Tue, 8 Dec 2020 13:07:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5AD4323AA8 for ; Tue, 8 Dec 2020 13:07:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726483AbgLHNHL (ORCPT ); Tue, 8 Dec 2020 08:07:11 -0500 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.53]:8240 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726415AbgLHNHL (ORCPT ); Tue, 8 Dec 2020 08:07:11 -0500 X-Greylist: delayed 357 seconds by postgrey-1.27 at vger.kernel.org; Tue, 08 Dec 2020 08:07:09 EST DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1607432658; s=strato-dkim-0002; d=fossekall.de; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date:From: Subject:Sender; bh=R9pAmrtgxzHV8b9qyJZRtWA5+8mvD2n+XnerwI88DtE=; b=mpBQqsCRqqRRPQtBz98b+wGCTmuTp2Sck3rby//y8k4+0YpjPLLiBs30OZghtKRxfz Z50xtJllN33oemNVSimnckmOfkCeTPyvN5WWhd0n8znaed54oIHto0zXc5f5JhU82taN R8cSHqwQ1yuntYOq1UJExR/NHdqG8I/4iReW1xLfcfiDTurFZOCZT+EFHQY1yM2DBzTn eZgYwRJTEgqKLTCQ8WSIxI34hHcQzVcZuaSUGL4lZZ9q+8b8AIhXtlNNQq2wpY92BF6u eBOlHfz9SJXLymgDe88CbhbSfvtoCgRmYfN4LxdJoqyEhH6FECd0J1+dB0eUuCFjVht1 rGpQ== X-RZG-AUTH: ":O2kGeEG7b/pS1EzgE2y7nF0STYsSLflpbjNKxx7cGrBOdI6BL9pkS3QW19mO7I+/JwRspuzJFZuRzQ==" X-RZG-CLASS-ID: mo00 Received: from aerfugl by smtp.strato.de (RZmta 47.6.2 AUTH) with ESMTPSA id e07b38wB8CqG20m (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Tue, 8 Dec 2020 13:52:16 +0100 (CET) Received: from koltrast.a98shuttle.de ([192.168.1.27] helo=a98shuttle.de) by aerfugl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kmcTX-0006UW-Jg; Tue, 08 Dec 2020 13:52:15 +0100 Date: Tue, 8 Dec 2020 13:52:14 +0100 From: Michael Klein To: Maxime Ripard Cc: Sebastian Reichel , Rob Herring , Chen-Yu Tsai , Jernej Skrabec , linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 2/3] Documentation: DT: binding documentation for regulator-poweroff Message-ID: <20201208125214.GA2785@a98shuttle.de> References: <20201128103958.q6glewhhch7vtczr@gilmour> <20201207142756.17819-1-michael@fossekall.de> <20201207142756.17819-3-michael@fossekall.de> <20201208101358.mwxmlgqonmunb2m2@gilmour> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20201208101358.mwxmlgqonmunb2m2@gilmour> Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Thanks for reviewing! On Tue, Dec 08, 2020 at 11:13:58AM +0100, Maxime Ripard wrote: >On Mon, Dec 07, 2020 at 03:27:55PM +0100, Michael Klein wrote: >> Add devicetree binding documentation for regulator-poweroff driver. >> >> Signed-off-by: Michael Klein >> --- >> .../power/reset/regulator-poweroff.yaml | 53 +++++++++++++++++++ >> 1 file changed, 53 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml >> >> diff --git a/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml >> new file mode 100644 >> index 000000000000..8c8ce6bb031a >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.yaml >> @@ -0,0 +1,53 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/power/reset/regulator-poweroff.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Force-disable power regulators to turn the power off. >> + >> +maintainers: >> + - Michael Klein >> + >> +description: | >> + When the power-off handler is called, one more regulators are disabled >> + by calling regulator_force_disable(). If the power is still on and the >> + CPU still running after a 3000ms delay, a WARN_ON(1) is emitted. >> + >> +properties: >> + compatible: >> + const: "regulator-poweroff" >> + >> + regulator-names: >> + description: >> + Array of regulator names >> + $ref: /schemas/types.yaml#/definitions/string-array >> + >> + REGULATOR-supply: > >This should be a patternProperties > >> + description: >> + For any REGULATOR listed in regulator-names, a phandle >> + to the corresponding regulator node >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + timeout-ms: >> + description: >> + Time to wait before asserting a WARN_ON(1). If nothing is >> + specified, 3000 ms is used. >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + >> +required: >> + - compatible >> + - regulator-names >> + - REGULATOR-supply >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + regulator-poweroff { >> + compatible = "regulator-poweroff"; >> + regulator-names = "vcc1v2", "vcc-dram"; >> + vcc1v2-supply = <®_vcc1v2>; >> + vcc-dram-supply = <®_vcc_dram>; >> + }; > >I'm not entirely sure how multiple regulators would work here. I guess >the ordering is board/purpose sensitive. In this particular case, I >assume that vcc1v2 would be shut down before vcc-dram? yes, the regulators are shut down from left to right. >If so, I would expect that one regulator_force_disable is run, the CPU >is disabled and you never get the chance to cut vcc-dram. I assume that any relevant regulator here has enough capacitance on the output that provides enough charge to disable any remaining regulators (my board has 3*10µF for vcc1v2 and 1*10µF for vcc-dram). But there is of course no guarantee, so I'm shutting down the most relevant (in terms of current consumption) regulator first. In any case, if it's deemed unnecessary to allow more than one regulator in the driver I could remove the regulator-names property altogether and reduce the DT node to: regulator-poweroff { compatible = "regulator-poweroff"; poweroff-supply = <®_vcc1v2>; }; -- Michael 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=-13.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, 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 C92E3C433FE for ; Tue, 8 Dec 2020 12:53:39 +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 7EA5823A31 for ; Tue, 8 Dec 2020 12:53:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EA5823A31 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fossekall.de 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=zkBiJh0YXLujCEsjh7OdL6+fqMV6DhCtttQI2379XIY=; b=X3ZPBU/xpd2eZ4R63KvTpRsJa H4hTr2AHeRcf+dkzmu9ioUN3JkwKXDofefGoyZJgDxGeDwPu8KFzvxfMwdiPr0BfxwLgzCG+muiSE dZxVGRTfaJtH0Df2jdh9q3bpqfi5TMauNeyP8RGNbRcWxZ0p/vbZG+orWamJO/tArWZeA1JXiwIkI JfIcqJFxJAtrG5MixVQycosT9wfgszMQv1ql0yta0Si9AzWz8s9mWHYEYK08BF+7NCqdonX44+Koe 2S+E5Dhflo0ekILyVQZv0NEoPx7q4JLIy8d0erDMFfW/6/JH++foHzWsq44dRnXsXKR72vGbdMgKi URfnLJvcQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmcTg-00080y-Kp; Tue, 08 Dec 2020 12:52:24 +0000 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.52]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmcTc-0007yd-TH for linux-arm-kernel@lists.infradead.org; Tue, 08 Dec 2020 12:52:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1607431937; s=strato-dkim-0002; d=fossekall.de; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date:From: Subject:Sender; bh=R9pAmrtgxzHV8b9qyJZRtWA5+8mvD2n+XnerwI88DtE=; b=UYJT/oE05w3gxykxgg2ZwQPcrzOtVzr/gSAO/1zIARA/6E6Ozn49g2ZEz89KNKhR2J 9KkjMZ1yIUjJg9d6NY7R844ha73oW0DkqryvI0rH5braeyuqVY99VcDoiACd21fSEpqZ V/O0+EZNmlZHNbiJPb5m7wj7NudRVC2BQlF9nOeaht131ZxrU45QMe6mAzLm6Ly6UoDm IWedNn4gdaz4htUx71SrbEGNduSxj8sdkFzJMXzp0qhJryWLA+H48M5KNzur4zgfYRVo W7H8mdjQqoszmuJHSi+f7RhtzOJKcSRD71CPcR7HDntzUYbhsYXa/38TuNjtaN7TCKXq bNmQ== X-RZG-AUTH: ":O2kGeEG7b/pS1EzgE2y7nF0STYsSLflpbjNKxx7cGrBOdI6BL9pkS3QW19mO7I+/JwRspuzJFZuRzQ==" X-RZG-CLASS-ID: mo00 Received: from aerfugl by smtp.strato.de (RZmta 47.6.2 AUTH) with ESMTPSA id e07b38wB8CqG20m (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Tue, 8 Dec 2020 13:52:16 +0100 (CET) Received: from koltrast.a98shuttle.de ([192.168.1.27] helo=a98shuttle.de) by aerfugl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kmcTX-0006UW-Jg; Tue, 08 Dec 2020 13:52:15 +0100 Date: Tue, 8 Dec 2020 13:52:14 +0100 From: Michael Klein To: Maxime Ripard Subject: Re: [PATCH v3 2/3] Documentation: DT: binding documentation for regulator-poweroff Message-ID: <20201208125214.GA2785@a98shuttle.de> References: <20201128103958.q6glewhhch7vtczr@gilmour> <20201207142756.17819-1-michael@fossekall.de> <20201207142756.17819-3-michael@fossekall.de> <20201208101358.mwxmlgqonmunb2m2@gilmour> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201208101358.mwxmlgqonmunb2m2@gilmour> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201208_075221_160085_EE198484 X-CRM114-Status: GOOD ( 22.31 ) 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: devicetree@vger.kernel.org, Jernej Skrabec , linux-pm@vger.kernel.org, Sebastian Reichel , linux-kernel@vger.kernel.org, Chen-Yu Tsai , Rob Herring , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Thanks for reviewing! On Tue, Dec 08, 2020 at 11:13:58AM +0100, Maxime Ripard wrote: >On Mon, Dec 07, 2020 at 03:27:55PM +0100, Michael Klein wrote: >> Add devicetree binding documentation for regulator-poweroff driver. >> >> Signed-off-by: Michael Klein >> --- >> .../power/reset/regulator-poweroff.yaml | 53 +++++++++++++++++++ >> 1 file changed, 53 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/power/reset/regula= tor-poweroff.yaml >> >> diff --git a/Documentation/devicetree/bindings/power/reset/regulator-pow= eroff.yaml b/Documentation/devicetree/bindings/power/reset/regulator-powero= ff.yaml >> new file mode 100644 >> index 000000000000..8c8ce6bb031a >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/power/reset/regulator-poweroff.y= aml >> @@ -0,0 +1,53 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/power/reset/regulator-poweroff.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Force-disable power regulators to turn the power off. >> + >> +maintainers: >> + - Michael Klein >> + >> +description: | >> + When the power-off handler is called, one more regulators are disabled >> + by calling regulator_force_disable(). If the power is still on and the >> + CPU still running after a 3000ms delay, a WARN_ON(1) is emitted. >> + >> +properties: >> + compatible: >> + const: "regulator-poweroff" >> + >> + regulator-names: >> + description: >> + Array of regulator names >> + $ref: /schemas/types.yaml#/definitions/string-array >> + >> + REGULATOR-supply: > >This should be a patternProperties > >> + description: >> + For any REGULATOR listed in regulator-names, a phandle >> + to the corresponding regulator node >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + timeout-ms: >> + description: >> + Time to wait before asserting a WARN_ON(1). If nothing is >> + specified, 3000 ms is used. >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + >> +required: >> + - compatible >> + - regulator-names >> + - REGULATOR-supply >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + regulator-poweroff { >> + compatible =3D "regulator-poweroff"; >> + regulator-names =3D "vcc1v2", "vcc-dram"; >> + vcc1v2-supply =3D <®_vcc1v2>; >> + vcc-dram-supply =3D <®_vcc_dram>; >> + }; > >I'm not entirely sure how multiple regulators would work here. I guess >the ordering is board/purpose sensitive. In this particular case, I >assume that vcc1v2 would be shut down before vcc-dram? yes, the regulators are shut down from left to right. >If so, I would expect that one regulator_force_disable is run, the CPU >is disabled and you never get the chance to cut vcc-dram. I assume that any relevant regulator here has enough capacitance on the = output that provides enough charge to disable any remaining regulators = (my board has 3*10=B5F for vcc1v2 and 1*10=B5F for vcc-dram). But there is = of course no guarantee, so I'm shutting down the most relevant (in terms = of current consumption) regulator first. In any case, if it's deemed unnecessary to allow more than one regulator = in the driver I could remove the regulator-names property altogether and = reduce the DT node to: regulator-poweroff { compatible =3D "regulator-poweroff"; poweroff-supply =3D <®_vcc1v2>; }; -- = Michael _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel