From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756622AbcHWEJl (ORCPT ); Tue, 23 Aug 2016 00:09:41 -0400 Received: from regular1.263xmail.com ([211.150.99.138]:35679 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754130AbcHWEJj (ORCPT ); Tue, 23 Aug 2016 00:09:39 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: xf@rock-chips.com X-FST-TO: lin.huang@rock-chips.com X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: xf@rock-chips.com X-UNIQUE-TAG: <00c992e136f9af508a1497095b240028> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH v1 3/3] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs To: Rob Herring References: <1471315139-28285-1-git-send-email-finley.xiao@rock-chips.com> <1471315139-28285-4-git-send-email-finley.xiao@rock-chips.com> <20160819133636.GA26913@rob-hp-laptop> Cc: srinivas.kandagatla@linaro.org, maxime.ripard@free-electrons.com, heiko@sntech.de, frowand.list@gmail.com, sre@kernel.org, dbaryshkov@gmail.com, dwmw2@infradead.org, mark.rutland@arm.com, khilman@kernel.org, nm@ti.com, rjw@rjwysocki.net, viresh.kumar@linaro.org, sboyd@codeaurora.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, wxt@rock-chips.com, jay.xu@rock-chips.com, rocky.hao@rock-chips.com, tim.chen@rock-chips.com, tony.xie@rock-chips.com, ulysses.huang@rock-chips.com, lin.huang@rock-chips.com From: Finley Xiao Message-ID: Date: Tue, 23 Aug 2016 12:10:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160819133636.GA26913@rob-hp-laptop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2016/8/19 21:36, Rob Herring 写道: > On Tue, Aug 16, 2016 at 10:38:59AM +0800, Finlye Xiao wrote: >> From: Finley Xiao >> >> This patch supports adjusting opp's voltage according to leakage >> >> Signed-off-by: Finley Xiao >> --- >> .../devicetree/bindings/power/rockchip-cpu-avs.txt | 37 +++ >> drivers/power/avs/Kconfig | 8 + >> drivers/power/avs/Makefile | 1 + >> drivers/power/avs/rockchip-cpu-avs.c | 314 +++++++++++++++++++++ >> 4 files changed, 360 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/power/rockchip-cpu-avs.txt >> create mode 100644 drivers/power/avs/rockchip-cpu-avs.c >> >> diff --git a/Documentation/devicetree/bindings/power/rockchip-cpu-avs.txt b/Documentation/devicetree/bindings/power/rockchip-cpu-avs.txt >> new file mode 100644 >> index 0000000..90f6b08 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/power/rockchip-cpu-avs.txt >> @@ -0,0 +1,37 @@ >> +Rockchip cpu avs device tree bindings >> +------------------------------------- >> + >> +Under the same frequency, the operating voltage tends to decrease with >> +increasing leakage. so it is necessary to adjust opp's voltage according >> +to leakage for power. >> + >> + >> +Required properties: >> +- compatible: Should be one of the following. >> + - "rockchip,rk3399-cpu-avs" - for RK3399 SoCs. >> +- leakage-volt-: Named leakage-volt property. At runtime, the >> + platform can find a cpu's cluster_id according to it's cpu_id and match >> + leakage-volt- property. The property is an array of 3-tuples >> + items, and each item consists of leakage and voltage like >> + . >> + min-leakage: minimum leakage in mA. >> + max-leakage: maximum leakage in mA. >> + vol: voltage in microvolt. > How do you determine these values? When do they vary? How do you determine these values? run antutu-benchmark leakage freq min_volt 30mA 1608MHz 1025mV 40mA 1608MHz 1000mV 50mA 1608MHz 975mV From the table, we see the min_volt decrease with increasing leakage. So we can set the default opp-microvolt 1025mV for 1608MHz, and add an leakage_volt_cluster0 property as follows. leakage_volt_cluster0 = < /* min(mA) max(mA) volt(uV)*/ 0 40 0 41 50 (-25000) 51 254 (-50000) >; If the leakage is between 41mA and 50mA，the opp-microvolt will subtract 25mV。 If the leakage is between 41mA and 50mA，the opp-microvolt will subtract 50mV。 When do they vary? From the code, cpufreq_online --cpufreq_driver->init(policy); /* add new opp table */ --blocking_notifier_call_chain(&cpufreq_policy_notifier_list, CPUFREQ_START, policy); --cpufreq_init_policy ----cpufreq_set_policy --------__cpufreq_governor(policy, CPUFREQ_GOV_START); The cpu's opp table is added in the init function(cpufreq_init)，and I will register a cpufreq notifier, once the first cpu of cluster is onlined, my notifer will be called, and if the event is CPUFREQ_START，it will modify the opp-microvolt according to leakage_volt_cluster0. >> + >> +Example: >> + >> + cpu_avs: cpu-avs { >> + compatible = "rockchip,rk3399-cpu-avs"; > This isn't really a hardware block. For the same reasons we don't have > cpufreq nodes. So I don't think this belongs in DT. if I delete the compatible property like the thermal-zones node, is it allowed? cpu_avs: cpu-avs { leakage_volt_cluster0 = < /* min(mA) max(mA) volt(uV)*/ 0 40 0 41 50 (-25000) 51 254 (-50000) >; leakage_volt_cluster1 = < /* min(mA) max(mA) volt(uV)*/ 0 40 0 41 50 (-25000) 51 254 (-50000) >; } > > Rob > > > -- Finley