From patchwork Thu Dec 1 10:58:15 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 86009 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp633388qgi; Thu, 1 Dec 2016 02:58:36 -0800 (PST) X-Received: by 10.99.9.66 with SMTP id 63mr68216191pgj.84.1480589916003; Thu, 01 Dec 2016 02:58:36 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u3si40233703plb.141.2016.12.01.02.58.35; Thu, 01 Dec 2016 02:58:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-pm-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 linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-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 S1757134AbcLAK6e (ORCPT + 13 others); Thu, 1 Dec 2016 05:58:34 -0500 Received: from mail-pf0-f169.google.com ([209.85.192.169]:33885 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757033AbcLAK6e (ORCPT ); Thu, 1 Dec 2016 05:58:34 -0500 Received: by mail-pf0-f169.google.com with SMTP id c4so45835998pfb.1 for ; Thu, 01 Dec 2016 02:58:33 -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=AJIan799a/fHvTBz8VTuJ+vaA4vtxykSTx8VcZN44K07S2jq8CHbTbVrSYOmwUtKy3 Ec/LIzZpd+2O6XHGvMJ07I//kpWvH47SfzmUS5NHoGf4Bk/mE2UfgmKIVZwWZzfkcTIk 5YCqKpiQgiAAe+cW0a5v2eC+pF6EEhEbS9R3U= 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=he6fBjAoeXlrpdc0y8A4MPRb9zF1iSg2QcDniDo4jG3X7GmsEj9sfbzvV167VeZFmo 6FUV4PXG3MiYLDfB+DpORGI1hU0NS8pTVd6d4IGZKpA7waxGMCx/ukUzi2zl/hsr0qCO CbYIxPmF4enZdw63npg+E25EyBWbNQA0B3rgwgfftU6Ck8/DhATDtXPi6TnH0P8w9zLx isf9V5QVsy7KF+ndVk6ZHie6IASbgoS940chtNJfiIuGTJbVpUuJ8l7qslV2Vk/EVSpO j8sGsYq6T9L3UukVozljm+7EgWEg2ozuBFTyTwLs7CJXNY5P9YoJiHp2keywWP/gHkaR rlWA== X-Gm-Message-State: AKaTC03xv55tuwktYyYsRWEz0DKc+BSE3yKoz8ik0XMSGBPfsb9WPPY8Xb/FPoyaf6UjY5/Q X-Received: by 10.99.209.5 with SMTP id k5mr68734947pgg.145.1480589913219; Thu, 01 Dec 2016 02:58:33 -0800 (PST) Received: from localhost ([122.172.143.30]) by smtp.gmail.com with ESMTPSA id q27sm109787325pfd.49.2016.12.01.02.58.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Dec 2016 02:58:32 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , Viresh Kumar , Nishanth Menon , Stephen Boyd Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, Vincent Guittot , robh@kernel.org, d-gerlach@ti.com, broonie@kernel.org, devicetree@vger.kernel.org, Viresh Kumar Subject: [PATCH V7 02/10] PM / OPP: Reword binding supporting multiple regulators per device Date: Thu, 1 Dec 2016 16:28:15 +0530 Message-Id: <838bd6b145f769c6531cec62b009bbec346e28d4.1480564564.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.7.1.410.g6faf27b In-Reply-To: References: In-Reply-To: References: Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@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 linux-pm" 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.