From patchwork Wed Oct 26 06:32:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 9395965 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 858BE60477 for ; Wed, 26 Oct 2016 06:33:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 52F072985E for ; Wed, 26 Oct 2016 06:33:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4788A2985F; Wed, 26 Oct 2016 06:33:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BE8AF29860 for ; Wed, 26 Oct 2016 06:33:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753191AbcJZGdq (ORCPT ); Wed, 26 Oct 2016 02:33:46 -0400 Received: from mail-pf0-f180.google.com ([209.85.192.180]:33666 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753099AbcJZGdp (ORCPT ); Wed, 26 Oct 2016 02:33:45 -0400 Received: by mail-pf0-f180.google.com with SMTP id 197so10028048pfu.0 for ; Tue, 25 Oct 2016 23:33:44 -0700 (PDT) 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=7oCji+z9J0Szwq64577mrpgSLt+vZlwlqXXDY6HjvWc=; b=EEyn7W44dJ7X32wtU+1fsxpzFJItgHkNBdZLZAcx1Zt0PDo3IoMrvWWMCqfSqt0kMx SnFYvcl+KSOT24/VuKI3GYonPw6wfOEx6BaL829gLPCraF5+UrtzEsFcSdYwO32EqlFl QT7KiH2ImFt0Ct0+zDbnZa+wynPDrOR++/OqE= 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=7oCji+z9J0Szwq64577mrpgSLt+vZlwlqXXDY6HjvWc=; b=L/NvFXPAxergC4pyFikV7UluKH/dJfw8L13IAtfwgSzkVxYEtncKrHdtIiTLZTtNXV Sa3GJf+53PVPuVZF9b3CcdjARxzSq6xokfOxeMqWYD78ZJk/orwdYLQ0c9oxfH517Vlk 6BenWdfZchYuCQtJw5IM5yKs1HJw2TikAYJY6gclCnT8t0myZ8VKctNmlN/RV43qjjS2 PSbHFRtcDH/wtuwr5rcDBJIE1wa9pJ5EEGffUwmHGdS4JM2Pr2PyDHcqtf0AqgyOicfj 6lhiNVUVGNgJswQtxfEpivQuPoO1jLlO1rigSoQUuT3EiyIj++6ke0yTrYoQnPOGy/mF YZcw== X-Gm-Message-State: ABUngvcTeCLT/LCfJUzKtsAk8qMjGscjG0jDCDWQYLGKS9Mb4mSyfmHx43AlbmqrlQ/P9ubp X-Received: by 10.98.56.15 with SMTP id f15mr705514pfa.106.1477463624263; Tue, 25 Oct 2016 23:33:44 -0700 (PDT) Received: from localhost ([171.61.116.10]) by smtp.gmail.com with ESMTPSA id bu8sm1283545pab.46.2016.10.25.23.33.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 23:33:43 -0700 (PDT) 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, Viresh Kumar , devicetree@vger.kernel.org Subject: [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device Date: Wed, 26 Oct 2016 12:02:56 +0530 Message-Id: <28119b44689921f3c3cc00be49bff2bb99b32162.1477463128.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 X-Virus-Scanned: ClamAV using ClamSMTP 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. For example, there is no way for the code parsing these bindings to know which voltage values belong to which power supply. Also its not possible to know the order in which the supplies need to be configured while switching OPPs. This patch tries to clarify on those details and does some minor changes as well. Note that the bindings do not specify the order in which the regulators need to be programmed and the order in which the entries are added for the supplies. The user of the bindings (like the kernel) shall know these details already and the DT is responsible to supply only the readings for the regulators. Cc: Mark Brown Cc: devicetree@vger.kernel.org Signed-off-by: Viresh Kumar Acked-by: Rob Herring Reviewed-by: Stephen Boyd --- Documentation/devicetree/bindings/opp/opp.txt | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index ee91cbdd95ee..af476df510f1 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -86,8 +86,13 @@ 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. + + 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 +109,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 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. - opp-microamp-: Named opp-microamp property. Similar to opp-microvolt- property, but for microamp instead. @@ -386,10 +393,12 @@ Example 4: Handling multiple regulators / { cpus { cpu@0 { - compatible = "arm,cortex-a7"; + compatible = "vendor,cpu-type"; ... - 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>; }; };