From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757158AbcHYWQW (ORCPT ); Thu, 25 Aug 2016 18:16:22 -0400 Received: from mga11.intel.com ([192.55.52.93]:11227 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752054AbcHYWQU (ORCPT ); Thu, 25 Aug 2016 18:16:20 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,577,1464678000"; d="scan'208";a="753561685" From: "Pandruvada, Srinivas" To: "ahs3@redhat.com" , "ashwinch@google.com" CC: "pprakash@codeaurora.org" , "linux-kernel@vger.kernel.org" , "viresh.kumar@linaro.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" Subject: Re: [PATCH v5] Force cppc_cpufreq to report values in KHz to fix user space reporting Thread-Topic: [PATCH v5] Force cppc_cpufreq to report values in KHz to fix user space reporting Thread-Index: AQHR/Pc2aM7bz4wRxE2gaEoGL6yFfqBXLkwAgAOFVQA= Date: Thu, 25 Aug 2016 22:00:41 +0000 Message-ID: <1472162436.13076.21.camel@intel.com> References: <1469049004-19069-1-git-send-email-ahs3@redhat.com> <20160801203156.GV4605@ubuntu> <872a4dd4-a752-507b-e720-ec2e6003bd8c@redhat.com> <406534f5-5e45-237e-cc68-2b57631e26d1@redhat.com> <6a0079da-2f81-a58b-0a71-3564d79ad61b@redhat.com> <1471926684.5747.13.camel@intel.com> <8012e614-885a-0445-44aa-63d92de5cd1f@redhat.com> In-Reply-To: <8012e614-885a-0445-44aa-63d92de5cd1f@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.182.198] Content-Type: text/plain; charset="utf-8" Content-ID: <87A4ECFC17C7BF4FB5FC928DB35F9C80@intel.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u7PMGRbH007474 On Tue, 2016-08-23 at 10:14 -0600, Al Stone wrote: > > > [...] > > In x86 when CPPC is used, the unit is really unit-less in CPPC > > tables. > > This means that cpu->perf_caps.highest_perf can be just 0xff, > > instead > > of some scaled cppc max performance corresponding to max MHZ the > > processor can support. This allows the processor to cap at max > > which it > > can deliver. > > Is this case not possible for ARM SoCs? > > [...] > If I understand the question properly, I don't think it matters, and > I don't > think that will work for x86 either. > > This patch is meant to allow CPPC to continue operating solely based > on the > abstract scale provided by the ACPI tables; this should be true > regardless > of architecture.  Any actual processor performance changes are still > guided > solely by the CPPC scale provided in the tables, and not the values > in the > cpu->perf_caps struct. > > Assuming I understand the kernel code, the values in cpu->perf_caps > -- in this > case -- are really just for reporting to user space via sysfs, which > is the > root of the problem: user space expects frequencies, and we have none > when using > CPPC so we have to provide an approximation.  In those circumstances, > I think a > value of 0xff would be kind of confusing in sysfs, since it's > basically saying > the CPU is operating at a frequency equal to the largest integer > value. > > To be fair, this is how the ARM processor implements CPPC; I have not > examined > in detail the newly submitted x86 patches to use CPPC so I cannot > comment on > those.  This patch was written well before those showed up. Currently we are not using cppc-cpufreq driver, so not will not directly impact (you are  not changing acpi-cpufreq source, which we are using). x86 has other way to get max/min cpufreq policy frequencies using MSRs. So you may choose to ignore my comments here, as long as your changes are limited to drivers/cpufreq/cppc_cpufreq.c When you are doing: policy->min = cpu->perf_caps.lowest_perf * cppc_dmi_max_khz / cpu- >perf_caps.highest_perf; Aren't you assuming that scale from max to min performance is only related to frequency? It is possible that many points in between can be same frequency with multiple voltages. As per spec " The platform may choose to use a single metric such as processor frequency, or it may choose to blend multiple hardware metrics to create a synthetic measure of performance". Thanks, Srinivas  >