From patchwork Fri Sep 11 12:01:57 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 516754 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 79783140323 for ; Fri, 11 Sep 2015 22:02:27 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752043AbbIKMC0 (ORCPT ); Fri, 11 Sep 2015 08:02:26 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:34053 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751986AbbIKMCZ (ORCPT ); Fri, 11 Sep 2015 08:02:25 -0400 Received: by padhy16 with SMTP id hy16so73613481pad.1 for ; Fri, 11 Sep 2015 05:02:24 -0700 (PDT) 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=Sgee47vcXIJ1mHL3Dcaup/lCUh07BMDX6nPxaN1who8=; b=Qi2LMEHdnz5iixJab/F6dj06YXuu0lA/6VbN18b1Av2+SfjYPibTQZ/YQ738JzqL/y dekt/WbV+murGnT0p/0MhA7PmAT2xjNl9VwTyyuzAIiBD5otAPh1x7fFOFgT4ChVtFKV OWHKckjNMinKv2qKUVj+pgdIb+Q98hyhYXcPO4sACl9VwEdv+safCjOhJbpV1Hppvj8N Yj2GUOcv5EVwytXmkoMC/qhXwoRHQlPtgL9BAWcvqDKALspvlQGmGAvKsyUWwxaDULc6 uwlYX2cj6Dr/z14LBGgDaelWFLyMmje6ABreKKUjLtmFGbFcwcIOrUq1DI74L8xO+KdG MY+A== X-Gm-Message-State: ALoCoQmBoV0O3stsHea4nfnoieecqqKtVRHKEBGhc4oNfMqV2xDLsHRlxpuud0NGVfmDFos0dFow X-Received: by 10.66.157.137 with SMTP id wm9mr37075451pab.30.1441972944445; Fri, 11 Sep 2015 05:02:24 -0700 (PDT) Received: from localhost ([122.171.186.190]) by smtp.gmail.com with ESMTPSA id xi1sm2013909pac.48.2015.09.11.05.02.23 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 11 Sep 2015 05:02:23 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki , nm@ti.com, sboyd@codeaurora.org Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, rob.herring@linaro.org, lee.jones@linaro.org, Viresh Kumar , Mark Brown , devicetree@vger.kernel.org, Ian Campbell , Kumar Gala , linux-kernel@vger.kernel.org (open list), Mark Rutland , Pawel Moll , "Rafael J. Wysocki" , Rob Herring Subject: [PATCH 01/16] PM / OPP: Add 'supply-names' binding Date: Fri, 11 Sep 2015 17:31:57 +0530 Message-Id: <2b87b162eabd1570ae2311e1ef8655acda72f678.1441972771.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.4.0 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 Regulators already have stable DT bindings, wherein the consumer (of supplies) will have following for each regulator/supply. -supply: ; Current OPP bindings extend above, by transforming it into a list of phandles. But we missed the string, which is used to identify the regulator. And looking from regulators perspective, having two different ways of specifying regulators doesn't seem like a step forward, it also means we have to update every single device binding. And things will become complex. Another way to support multiple regulators per device (in OPP V2 bindings) is to leave regulator consumer bindings as is, and create a 'supply-names' property in the opp-table node, which will contain a list of strings. The names in this list shall match 'name' from the '-supply' strings present in the device node. The strings in this list also specify the order in which values must be present in 'opp-microvolt' and 'opp-microamp' properties. Cc: Mark Brown Cc: devicetree@vger.kernel.org Signed-off-by: Viresh Kumar --- Documentation/devicetree/bindings/opp/opp.txt | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index 0cb44dc21f97..8759bc4783ed 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -69,6 +69,13 @@ This describes the OPPs belonging to a device. This node can have following - compatible: Allow OPPs to express their compatibility. It should be: "operating-points-v2". +- supply-names: This is a required property, only if multiple supplies are + available for the device. Otherwise it is optional. + + This list is used to pass names of all the device supplies. The order of names + present here is important, as that should match the order in which values are + present in 'opp-microvolt' and 'opp-microamp' properties. + - OPP nodes: One or more OPP nodes describing voltage-current-frequency combinations. Their name isn't significant but their phandle can be used to reference an OPP. @@ -97,8 +104,8 @@ 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 must be present in the same order as their + names are present in 'supply-names' property of the opp-table. - opp-microamp: The maximum current drawn by the device in microamperes considering system specific parameters (such as transients, process, aging, @@ -107,10 +114,12 @@ 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 must be present in the same order as their + names are present in 'supply-names' property of the opp-table. + + 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. - clock-latency-ns: Specifies the maximum possible transition latency (in nanoseconds) for switching to this OPP from any other OPP. @@ -369,13 +378,16 @@ Example 4: Handling multiple regulators compatible = "arm,cortex-a7"; ... - cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>; + vcc0-supply = <&cpu_supply0>; + vcc1-supply = <&cpu_supply1>; + vcc2-supply = <&cpu_supply2>; operating-points-v2 = <&cpu0_opp_table>; }; }; cpu0_opp_table: opp_table0 { compatible = "operating-points-v2"; + supply-names = "vcc0", "vcc1", "vcc2"; opp-shared; opp00 {