From patchwork Fri Feb 24 09:06:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 94423 Delivered-To: patch@linaro.org Received: by 10.140.20.99 with SMTP id 90csp601434qgi; Fri, 24 Feb 2017 01:14:23 -0800 (PST) X-Received: by 10.84.141.129 with SMTP id 1mr2468597plv.166.1487927663674; Fri, 24 Feb 2017 01:14:23 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e1si6807633pga.366.2017.02.24.01.14.23; Fri, 24 Feb 2017 01:14:23 -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 sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751425AbdBXJOR (ORCPT + 7 others); Fri, 24 Feb 2017 04:14:17 -0500 Received: from mail-pg0-f42.google.com ([74.125.83.42]:35792 "EHLO mail-pg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750964AbdBXJOO (ORCPT ); Fri, 24 Feb 2017 04:14:14 -0500 Received: by mail-pg0-f42.google.com with SMTP id b129so9350114pgc.2 for ; Fri, 24 Feb 2017 01:14:13 -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=wuAyO15d/t1bsNq8tTU9o+3mL4gPaTQ/ndr2TIpA3q4=; b=F4noKwWYCaLHTqJifPfX22WLyb/XfgzI/3K9yU+d0EV87J13F72rDBvShTfNr2tc1L 1Jnn8R4fpLGbJCZidgXoe2xSjfopfsfrO4suLdYYKHiD23a0jkV7Dk2FjKroLnmJGdHO +cS4ypIeswDvsKO0hO2bBskG39aJ5GajZWesY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to:references; bh=wuAyO15d/t1bsNq8tTU9o+3mL4gPaTQ/ndr2TIpA3q4=; b=UyS5HDrTMEiczzdctZmP9ggEyJH5T7eC4N7Vsvunw1kC/5+1SQ25nSiDfFFacJMfSW VbNPDFnBYL+3j72u0bRDcoA30EmAUuEKPmLv0PS3cbexbB8RHprCQObDOdYLBgbwD7gm enf7xdVlXPJMnlFiyr3hNbfFshOXpGaF2wAjm6jCrpB4oR+jOcM+xiLe/XQp6+LGi4kv ETq4Kkc+Dmbf5WnuXhhcrCAPWRylEh++Mof4NHmLrMYoq9dW3n33KIetupU3fjt+wXDE p6W8bW6afJGrrmGJvo90Tzd6yEj/bCKApLx/t5k6X9c8tEOAccq8AjA1oOmjXA5SJ8UG IARQ== X-Gm-Message-State: AMke39l3+tWVAo6sr6RmuLPWvrnCFTVTCr7zL5s4M9TqYHov/qLQHKArMsGZ8t8cGsT8AfdA X-Received: by 10.98.61.209 with SMTP id x78mr2116813pfj.88.1487927208712; Fri, 24 Feb 2017 01:06:48 -0800 (PST) Received: from localhost ([122.172.165.189]) by smtp.gmail.com with ESMTPSA id z4sm13965607pge.49.2017.02.24.01.06.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 01:06:48 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , ulf.hansson@linaro.org, Kevin Hilman Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Stephen Boyd , Nishanth Menon , Vincent Guittot , robh+dt@kernel.org, lina.iyer@linaro.org, rnayak@codeaurora.org, Viresh Kumar , devicetree@vger.kernel.org Subject: [PATCH V3 1/7] PM / Domains: Introduce "performance-states" binding Date: Fri, 24 Feb 2017 14:36:33 +0530 Message-Id: <132e9200102bf2f1175567f0862596d098363d9e.1487926924.git.viresh.kumar@linaro.org> 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 Some platforms have the capability to configure the performance state of their power domains. The process of configuring the performance state is pretty much platform dependent and we may need to work with a wide range of configurables. For some platforms, like Qcom, it can be a positive integer value alone, while in other cases it can be voltage levels, etc. The power-domain framework until now was only designed for the idle state management of the device and this needs to change in order to reuse the power-domain framework for active state management of the devices. This patch adds DT bindings to describe the performance states of a power domain. The power domain node needs to contain a "performance-states" node, which itself is an array of per-state nodes. Each per-state node represents individual performance state of a device. Individual nodes are identified by their (mandatory) "reg" field. These nodes can also contain an optional "domain-microvolt" property. More properties can be added later on once we have more platforms using it. 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 using the "domain-performance-state" property. Otherwise the consumers can define their requirements with help of other infrastructure, for example the OPP table (added in a later commit). Signed-off-by: Viresh Kumar Tested-by: Rajendra Nayak --- .../devicetree/bindings/power/power_domain.txt | 67 ++++++++++++++++++++++ 1 file changed, 67 insertions(+) -- 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 Acked-by: Rob Herring diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt index 723e1ad937da..9be09e576f68 100644 --- a/Documentation/devicetree/bindings/power/power_domain.txt +++ b/Documentation/devicetree/bindings/power/power_domain.txt @@ -38,6 +38,33 @@ 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. +- performance-states : This describes the performance states of a PM domain. + The performance-states node reflects the performance states of this PM domain + and not the performance states of the devices or sub-domains in the PM domain. + Sub domains can have their own performance states. Sub domains without their + own performance states are governed by the performance states of the parent + domain and the "domain-performance-state" properties of their consumers refer + to the "reg" properties of the nodes in the parent domain. + + Required properties of the performance-states node: + - compatible: Allow performance states to express their compatibility. It + should be: "domain-performance-state". + + - nodes: The performance-states node should contain one or + more nodes, each representing a supported performance state. + + Required properties of the performance state nodes: + - reg: A positive integer value representing the performance level + associated with a performance state. The integer value '0' represents the + lowest performance level and the highest value represents the highest + performance level. The exact meaning and performance implications of + individual values is left to be defined by the user platform. + + Optional properties of performance state nodes: + - 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 +145,44 @@ 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 positive integer value representing the minimum + performance level (of the parent domain) required by the consumer for its + working. The integer value '0' represents the lowest performance level and the + highest value represents the highest performance level. The value of + domain-performance-state field should match one of the "reg" fields in the + "performance-states" table of the parent power domain. + + +Example: + + parent: power-controller@12340000 { + compatible = "foo,power-controller"; + reg = <0x12340000 0x1000>; + #power-domain-cells = <0>; + + performance-states { + compatible = "domain-performance-state"; + pstate@1 { + reg = <1>; + domain-microvolt = <970000 975000 985000>; + }; + pstate@2 { + reg = <2>; + domain-microvolt = <1000000 1075000 1085000>; + }; + pstate@3 { + reg = <3>; + domain-microvolt = <1100000 1175000 1185000>; + }; + }; + }; + + leaky-device@12350000 { + compatible = "foo,i-leak-current"; + reg = <0x12350000 0x1000>; + power-domains = <&power 0>; + domain-performance-state = <2>; + }; + [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt