From patchwork Tue Nov 29 06:36:49 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 84504 Delivered-To: patch@linaro.org Received: by 10.182.1.168 with SMTP id 8csp2107998obn; Mon, 28 Nov 2016 22:37:35 -0800 (PST) X-Received: by 10.84.142.70 with SMTP id 64mr56993425plw.177.1480401455882; Mon, 28 Nov 2016 22:37:35 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 43si30048455pla.193.2016.11.28.22.37.35; Mon, 28 Nov 2016 22:37:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=devicetree-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755727AbcK2GhS (ORCPT + 7 others); Tue, 29 Nov 2016 01:37:18 -0500 Received: from mail-pg0-f51.google.com ([74.125.83.51]:32799 "EHLO mail-pg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755079AbcK2GhJ (ORCPT ); Tue, 29 Nov 2016 01:37:09 -0500 Received: by mail-pg0-f51.google.com with SMTP id 3so66112402pgd.0 for ; Mon, 28 Nov 2016 22:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=WPDIA+zdQT5iqTG6D37udj7somTJ2RMVlIVJ/Q04k4U=; b=R8xcTfipYydgj97EZsxOHqBGbZB+AwH35YyULJMgULlDRTCnT9/Jc0aGTMU+0M0JUj fA72BYRbfywA9b+attaiiitEv9POdcnGTF83dYDDpwk8ArSGFJ9+xWjUtEjmNalmI79v jWb228mtqQj/HSnQNunLIIEY0xOFcxhx9eSPY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=WPDIA+zdQT5iqTG6D37udj7somTJ2RMVlIVJ/Q04k4U=; b=gJskMh78dhBren3ImVmW4CCiSJODlZrlW2Tx992ISE7Lb4ocvBNQPx2pVLAAnMYbpw wHeeiNFdH9b+gcSkDErWhCb+T0PVN4T+KzW1PEP3m+AZ7kjagKNSNtknQFwVu7ABsDLp qGmQvrTgvvucengnfabMiLzf6FfSUJQbVbDactO36oecv4lIe4O86lumv/LprK1wQKZz fk+qYmUl+mvcFLmTEefQO5nReHCQsFkpGjn5hRTsrEePX4aEbv0EL2BpoJAmEJTH/RpG taRMtEsVqlS4GaB87QpoxMfCPv0Op+cYCAZj9utbe9uFb2lWsqEOuy0EoAF4TDeh4GsC bErQ== X-Gm-Message-State: AKaTC00RARgz5ktQ7753e46PkET4t4vnLkMZASsO48gd6motBlIam3GBQw9AOwSsPuLMcAz5 X-Received: by 10.98.223.25 with SMTP id u25mr25847687pfg.96.1480401428216; Mon, 28 Nov 2016 22:37:08 -0800 (PST) Received: from localhost ([122.172.89.192]) by smtp.gmail.com with ESMTPSA id z28sm74003408pgc.40.2016.11.28.22.37.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Nov 2016 22:37:07 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , nm@ti.com, sboyd@codeaurora.org, Viresh Kumar Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , robh@kernel.org, d-gerlach@ti.com, broonie@kernel.org, devicetree@vger.kernel.org, Viresh Kumar Subject: [PATCH V5 02/10] PM / OPP: Reword binding supporting multiple regulators per device Date: Tue, 29 Nov 2016 12:06:49 +0530 Message-Id: X-Mailer: git-send-email 2.7.1.410.g6faf27b In-Reply-To: References: In-Reply-To: References: Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On certain platforms (like TI), DVFS for a single device (CPU) requires configuring multiple power supplies. The OPP bindings already contains binding and example to explain this case, but it isn't sufficient. - There is no way for the code parsing these bindings to know which voltage values belong to which power supply. - It is not possible to know the order in which the supplies need to be configured while switching OPPs. This patch clarifies on those details by mentioning that such information is left for the implementation specific bindings to explain. They may want to hardcode such details or implement their own properties to get such information. All implementations using multiple regulators for their devices must provide a binding document explaining their implementation. Signed-off-by: Viresh Kumar Acked-by: Rob Herring Reviewed-by: Stephen Boyd --- Documentation/devicetree/bindings/opp/opp.txt | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) -- 2.7.1.410.g6faf27b -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index f0239f68d186..9f5ca4457b5f 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -86,8 +86,14 @@ properties. Single entry is for target voltage and three entries are for voltages. - Entries for multiple regulators must be present in the same order as - regulators are specified in device's DT node. + Entries for multiple regulators shall be provided in the same field separated + by angular brackets <>. The OPP binding doesn't provide any provisions to + relate the values to their power supplies or the order in which the supplies + need to be configured and that is left for the implementation specific + binding. + + Entries for all regulators shall be of the same size, i.e. either all use a + single value or triplets. - opp-microvolt-: Named opp-microvolt property. This is exactly similar to the above opp-microvolt property, but allows multiple voltage ranges to be @@ -104,10 +110,13 @@ properties. Should only be set if opp-microvolt is set for the OPP. - Entries for multiple regulators must be present in the same order as - regulators are specified in device's DT node. If this property isn't required - for few regulators, then this should be marked as zero for them. If it isn't - required for any regulator, then this property need not be present. + Entries for multiple regulators shall be provided in the same field separated + by angular brackets <>. If current values aren't required for a regulator, + then it shall be filled with 0. If current values aren't required for any of + the regulators, then this field is not required. The OPP binding doesn't + provide any provisions to relate the values to their power supplies or the + order in which the supplies need to be configured and that is left for the + implementation specific binding. - opp-microamp-: Named opp-microamp property. Similar to opp-microvolt- property, but for microamp instead.