From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7465DC46470 for ; Wed, 8 Aug 2018 08:48:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1FF2B2089F for ; Wed, 8 Aug 2018 08:48:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1FF2B2089F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727431AbeHHLGm (ORCPT ); Wed, 8 Aug 2018 07:06:42 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:35890 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727169AbeHHLGl (ORCPT ); Wed, 8 Aug 2018 07:06:41 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 940C118A; Wed, 8 Aug 2018 01:47:59 -0700 (PDT) Received: from e107155-lin (e107155-lin.emea.arm.com [10.4.12.116]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3C1F73F2EA; Wed, 8 Aug 2018 01:47:57 -0700 (PDT) Date: Wed, 8 Aug 2018 09:47:54 +0100 From: Sudeep Holla To: skannan@codeaurora.org Cc: Rob Herring , MyungJoo Ham , Kyungmin Park , Chanwoo Choi , Mark Rutland , georgi.djakov@linaro.org, vincent.guittot@linaro.org, daidavid1@codeaurora.org, bjorn.andersson@linaro.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Sudeep Holla Subject: Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor Message-ID: <20180808084754.GB25416@e107155-lin> References: <1533171465-25508-1-git-send-email-skannan@codeaurora.org> <20180807164114.GA12587@rob-hp-laptop> <496ac47a3c78f37655b60841fba7494c@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <496ac47a3c78f37655b60841fba7494c@codeaurora.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 07, 2018 at 12:37:07PM -0700, skannan@codeaurora.org wrote: > On 2018-08-07 09:41, Rob Herring wrote: > >On Wed, Aug 01, 2018 at 05:57:41PM -0700, Saravana Kannan wrote: > >>Many CPU architectures have caches that can scale independent of the > >>CPUs. > >>Frequency scaling of the caches is necessary to make sure the cache is > >>not > >>a performance bottleneck that leads to poor performance and power. The > >>same > >>idea applies for RAM/DDR. > >> > >>To achieve this, this patch adds a generic devfreq governor that takes > >>the > >>current frequency of each CPU frequency domain and then adjusts the > >>frequency of the cache (or any devfreq device) based on the frequency of > >>the CPUs. It listens to CPU frequency transition notifiers to keep > >>itself > >>up to date on the current CPU frequency. > >> > >>To decide the frequency of the device, the governor does one of the > >>following: > >> > >>* Uses a CPU frequency to device frequency mapping table > >> - Either one mapping table used for all CPU freq policies (typically > >>used > >> for system with homogeneous cores/clusters that have the same OPPs). > >> - One mapping table per CPU freq policy (typically used for ASMP > >>systems > >> with heterogeneous CPUs with different OPPs) > >> > >>OR > >> > >>* Scales the device frequency in proportion to the CPU frequency. So, if > >> the CPUs are running at their max frequency, the device runs at its > >>max > >> frequency. If the CPUs are running at their min frequency, the device > >> runs at its min frequency. And interpolated for frequencies in > >>between. > >> > >>Signed-off-by: Saravana Kannan > >>--- > >> .../bindings/devfreq/devfreq-cpufreq-map.txt | 53 ++ > > > >Bindings should be a separate patch. > > > >> drivers/devfreq/Kconfig | 8 + > >> drivers/devfreq/Makefile | 1 + > >> drivers/devfreq/governor_cpufreq_map.c | 583 > >>+++++++++++++++++++++ > >> 4 files changed, 645 insertions(+) > >> create mode 100644 > >>Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt > >> create mode 100644 drivers/devfreq/governor_cpufreq_map.c > >> > >>diff --git > >>a/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt > >>b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt > >>new file mode 100644 > >>index 0000000..982a30b > >>--- /dev/null > >>+++ b/Documentation/devicetree/bindings/devfreq/devfreq-cpufreq-map.txt > >>@@ -0,0 +1,53 @@ > >>+Devfreq CPUfreq governor > >>+ > >>+devfreq-cpufreq-map is a parent device that contains one or more child > >>devices. > >>+Each child device provides CPU frequency to device frequency mapping > >>for a > >>+specific device. Examples of devices that could use this are: DDR, > >>cache and > >>+CCI. > >>+ > >>+Parent device name shall be "devfreq-cpufreq-map". > >>+ > >>+Required child device properties: > >>+- cpu-to-dev-map, or cpu-to-dev-map-: > >>+ A list of tuples where each tuple consists of a > >>+ CPU frequency (KHz) and the corresponding device > >>+ frequency. CPU frequencies not listed in the table > >>+ will use the device frequency that corresponds to the > >>+ next rounded up CPU frequency. > >>+ Use "cpu-to-dev-map" if all CPUs in the system should > >>+ share same mapping. > >>+ Use cpu-to-dev-map- to describe different > >>+ mappings for different CPUs. The property should be > >>+ listed only for the first CPU if multiple CPUs are > >>+ synchronous. > >>+- target-dev: Phandle to device that this mapping applies to. > >>+ > >>+Example: > >>+ devfreq-cpufreq-map { > >>+ cpubw-cpufreq { > >>+ target-dev = <&cpubw>; > >>+ cpu-to-dev-map = > >>+ < 300000 1144000 >, > >>+ < 422400 2288000 >, > >>+ < 652800 3051000 >, > >>+ < 883200 5996000 >, > >>+ < 1190400 8056000 >, > >>+ < 1497600 10101000 >, > >>+ < 1728000 12145000 >, > >>+ < 2649600 16250000 >; > > > >Now we have frequencies listed in multiple places, the OPP tables and > >here? Perhaps it is grouping OPPs that should be done. > > This doesn't list all OPPs (it can if necessary). This is listing the > minimum frequency needed to give good performance/power for a > device/product. > Shouldn't the "status" property be used to disable OPPs you don't need on a particular platform ? Duplicating values is highly prone to errors and should be avoided. > AFAIK, OPP grouping isn't something that's supported in OPP framework or in > DT. Is there something specific you had in mind? Also, I'd like for this to > work even with devices that don't have OPPs listed in DT. > Also what's the solution you have for platforms with new *QCom FW Cpufreq* ? IIUC the frequency is obtained from the firmware. TBH this should ideally be handled in firmware if cpufreq is also handled by the firmware. I guess this platform doesn't have that ? -- Regards, Sudeep