Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751607AbdGYVyf (ORCPT ); Tue, 25 Jul 2017 17:54:35 -0400 Received: from cloudserver094114.home.net.pl ([79.96.170.134]:50169 "EHLO cloudserver094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750989AbdGYVyd (ORCPT ); Tue, 25 Jul 2017 17:54:33 -0400 From: "Rafael J. Wysocki" To: Huaisheng HS1 Ye Cc: Srinivas Pandruvada , "lenb@kernel.org" , "viresh.kumar@linaro.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , NingTing Cheng Subject: Re: [PATCH] cpufreq: intel_pstate: Fix cpuinfo_cur_freq after performance governor changes Date: Tue, 25 Jul 2017 23:46:34 +0200 Message-ID: <6482077.jWgIauTCtV@aspire.rjw.lan> User-Agent: KMail/4.14.10 (Linux/4.12.0-rc1+; KDE/4.14.9; x86_64; ; ) In-Reply-To: References: <1500875013-123321-1-git-send-email-yehs1@lenovo.com> <1500951465.4920.2.camel@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1144 Lines: 27 On Tuesday, July 25, 2017 07:03:36 AM Huaisheng HS1 Ye wrote: > Hi Srinivas, > Your idea is great, but your patch at cpufreq.c will force all platforms to use scaling_cur_freq as first choice when userspace wants to access cpuinfo_cur_freq. It is ok for intel x86 platfrom but hard to say with other platforms. > I modified it like that, it looks more reasonable. How about that? > > Hi Rafael, > Deleting "get" function pointer within intel_pstate would lead to sysfs > interface cpuinfo_cur_freq disappearing, because of > cpufreq_add_dev_interface will check "cpufreq_driver->get" for it. Which is exactly what I want. cpuinfo_cur_freq is bogus for intel_pstate and it should have never been exported for this driver. > Perhaps just return 0 with in intel_pstate_get would be a workaround for this > issue, how about it? > > I have tested this patch based on Purley platform, both Hardware and Software > P-states works correct, we could get accurate and same frequency from > cpuinfo_cur_freq and scaling_cur_freq. But this is not correct. These two attributes should not be expected to always return the same value. Thanks, Rafael