From patchwork Mon Dec 12 10:56:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 87650 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp1569911qgi; Mon, 12 Dec 2016 02:57:01 -0800 (PST) X-Received: by 10.84.218.3 with SMTP id q3mr184713761pli.80.1481540221662; Mon, 12 Dec 2016 02:57:01 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 77si42843098pgc.335.2016.12.12.02.57.01; Mon, 12 Dec 2016 02:57:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932646AbcLLK4j (ORCPT + 25 others); Mon, 12 Dec 2016 05:56:39 -0500 Received: from mail-pg0-f52.google.com ([74.125.83.52]:33238 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754192AbcLLK4g (ORCPT ); Mon, 12 Dec 2016 05:56:36 -0500 Received: by mail-pg0-f52.google.com with SMTP id 3so34395219pgd.0 for ; Mon, 12 Dec 2016 02:56:35 -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=zdJyQaUxVhuA+JESERT/EZ678WKfN6OMn1WnsQc6a44=; b=dcygWtXh6OIVDNRMUBVSRsRjRgjXjcYupsMJoVQR8435jAIi37s9PDRUBtsWjEoXNv QRb4rBe/cUbOpl9LEoGi5BEsoajitpZfduYGhpA11JZyOeg7Q2pePMhsE+vE631sbx+x CeJokdFhg3tLgxBR4GiWyufUVVJz6af4esbw0= 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=zdJyQaUxVhuA+JESERT/EZ678WKfN6OMn1WnsQc6a44=; b=NugELjewAveqYje4nziuTGGlGIQCN6a/LUdg153DIhwDObw/50jDJ6mh250XGyExSY fgG5Ag47CQRnFV3kpiaaWw6lY6kCKEvDEfMCn8i2KxgyirelVhJQC9YPMmj2Yf9xwRBn Etlp22X3qsb+1knhlUsLgJseCFtpD+gotrtj6I35FAaVSNH96iz2CnxHFD5bp5P1U+5S 640OHQuueeMhqxf6pRm7xdtVdzfElPqajKv3u20ecRrYIddv+dsTJ2jEqF4Ip60tgZ2k N68hprkivpeApvkGu9/NDqeGVN/ZXYMJ49cbEkHlO1exrush/+LFXC8adUBx6KSe+8ht mUvg== X-Gm-Message-State: AKaTC01jRriQt8BWOBG3aw3VtZRMJvDBOzJHp34niFQAJG2wgNb8Ne9VhX7uskS/Q59JTn0A X-Received: by 10.99.226.3 with SMTP id q3mr166988407pgh.37.1481540195154; Mon, 12 Dec 2016 02:56:35 -0800 (PST) Received: from localhost ([122.172.43.83]) by smtp.gmail.com with ESMTPSA id 64sm75560685pfu.17.2016.12.12.02.56.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Dec 2016 02:56:34 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Stephen Boyd , Nishanth Menon , Vincent Guittot , Rob Herring , Mark Rutland , Kevin Hilman , Ulf Hansson , Lina Iyer , devicetree@vger.kernel.org, Nayak Rajendra , Viresh Kumar Subject: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding Date: Mon, 12 Dec 2016 16:26:18 +0530 Message-Id: X-Mailer: git-send-email 2.7.1.410.g6faf27b In-Reply-To: References: In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Some platforms have the capability to configure the performance state of their Power Domains. The performance levels are represented by positive integer values, a lower value represents lower performance state. The power-domains until now were only concentrating on the idle state management of the device and this needs to change in order to reuse the infrastructure of power domains for active state management. This patch adds binding to describe the performance states of a power domain. If the consumers don't need the capability of switching to different domain performance states at runtime, then they can simply define their required domain performance state in their node directly. Otherwise the consumers can define their requirements with help of other infrastructure, for example the OPP table. Signed-off-by: Viresh Kumar --- .../devicetree/bindings/power/power_domain.txt | 69 ++++++++++++++++++++++ 1 file changed, 69 insertions(+) -- 2.7.1.410.g6faf27b diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt index 723e1ad937da..a456e0dc04e0 100644 --- a/Documentation/devicetree/bindings/power/power_domain.txt +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -38,6 +38,40 @@ phandle arguments (so called PM domain specifiers) of length specified by the domain's idle states. In the absence of this property, the domain would be considered as capable of being powered-on or powered-off. +- domain-performance-states : A phandle of the performance states node, which + defines all the performance states associated with a power + domain. + The domain-performance-states property reflects the performance states of this + PM domain and not the performance states of the devices or sub-domains in the + PM domain. Devices and sub-domains have their own performance states, which + are dependent on the performance state of the PM domain. + +* PM domain performance states node + +This describes the performance states of a PM domain. + +Required properties: +- compatible: Allow performance states to express their compatibility. It should + be: "domain-performance-state". + +- Performance state nodes: This node shall have one or more "Performance State" + nodes. + +* Performance state node + +Required properties: +- performance-level: A positive integer value representing the performance level + associated with a performance state. The integer value '1' represents the + lowest performance level and the highest value represents the highest + performance level. + +Optional properties: +- domain-microvolt: voltage in micro Volts. + + A single regulator's voltage is specified with an array of size one or three. + Single entry is for target voltage and three entries are for + voltages. + Example: power: power-controller@12340000 { @@ -118,4 +152,39 @@ The node above defines a typical PM domain consumer device, which is located inside a PM domain with index 0 of a power controller represented by a node with the label "power". +Optional properties: +- domain-performance-state: A phandle of a Performance state node. + +Example: + + parent: power-controller@12340000 { + compatible = "foo,power-controller"; + reg = <0x12340000 0x1000>; + #power-domain-cells = <0>; + domain-performance-states = <&domain_perf_states>; + }; + + domain_perf_states: performance_states { + compatible = "domain-performance-state"; + domain_perf_state1: pstate@1 { + performance-level = <1>; + domain-microvolt = <970000 975000 985000>; + }; + domain_perf_state2: pstate@2 { + performance-level = <2>; + domain-microvolt = <1000000 1075000 1085000>; + }; + domain_perf_state3: pstate@3 { + performance-level = <3>; + domain-microvolt = <1100000 1175000 1185000>; + }; + } + + leaky-device@12350000 { + compatible = "foo,i-leak-current"; + reg = <0x12350000 0x1000>; + power-domains = <&power 0>; + domain-performance-state = <&domain_perf_state2>; + }; + [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt