Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3154037pxu; Tue, 8 Dec 2020 05:05:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNNVFdWxiX6HeQeuGNE0pfoJXt7fpnOg3EoeBGmP/Zyp54raP+DqcjS+ev92WQcjMsbSru X-Received: by 2002:a17:906:c04d:: with SMTP id bm13mr22730229ejb.519.1607432731900; Tue, 08 Dec 2020 05:05:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607432731; cv=none; d=google.com; s=arc-20160816; b=Xxdr+digjLCTm1w7zRJ8jxnWcVG93iWX3x65ozzfeCtydIAj9EA2tCvYkxcGGtm1Uh 4teq5zNqzUTJyLfgE9vmRDTEurT7+GVtmiyIVQudWPav2MukusUQV9qTwPHcCTauwQCr AQXtqnM8dlOnl1g1qH1HBk3lx6y8AJrTm1zL7HS/sj57PKldLiMtX75STVKpq1xBtO1P /VXKZmsG+7G3AZzo5rNO0JUmvIAsnSA/+PXJ6RypyGZD5v7wNTh0C3iNwBC8LgVSaWWB sTM2bOb3S2vrD/7qEEv7zor7MC8fi7X3eK1kRDK45w6X+dsVr9Bl4Dgruwjwj84t+c+V aJIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=R9pAmrtgxzHV8b9qyJZRtWA5+8mvD2n+XnerwI88DtE=; b=jTW3njT5mBal6iFvp4/n0yM2v5cxgayGHJR5WH3nf4RQEvrInX8hszT5Q4a431GuD+ bjtrnML8j0ymewEchfKThebEziTo9zk6kOcyc0LgnGgie6rwLB9j2nF1Nba8DwJ6mLwB 8WSaz4WIdZh5HXxUFCWdonfcFRrKphHzD0uBLX8ZSTFQNLxYTWCBs0+hXA7ybyCm1NTh +zT9exOYSz2GQeLIBX8TQrcVSJuBEfw8YYb/lq3cvBNh7sqWFvIYUxNuTbggCfEZAvKk ohNr4IpANquMEIkYSnK7DAXStl5HQ8c4GuGmfJTe6woDZQzdSgjB/jt6keXaYmX09EeZ BLew== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r27si8841753edx.124.2020.12.08.05.05.07; Tue, 08 Dec 2020 05:05:31 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728318AbgLHNBO (ORCPT + 99 others); Tue, 8 Dec 2020 08:01:14 -0500 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.54]:12657 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727554AbgLHNBO (ORCPT ); Tue, 8 Dec 2020 08:01:14 -0500 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-kernel@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