Linux Power Management development
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Huaisheng HS1 Ye <yehs1@lenovo.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	NingTing Cheng <chengnt@lenovo.com>
Subject: Re: [PATCH] cpufreq: intel_pstate: Fix cpuinfo_cur_freq after performance governor changes
Date: Tue, 25 Jul 2017 23:46:34 +0200	[thread overview]
Message-ID: <6482077.jWgIauTCtV@aspire.rjw.lan> (raw)
In-Reply-To: <KL1PR0302MB2502B85BBFF7B8BB79BE40D692B80@KL1PR0302MB2502.apcprd03.prod.outlook.com>

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

  parent reply	other threads:[~2017-07-25 21:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24  5:43 [PATCH] cpufreq: intel_pstate: Fix cpuinfo_cur_freq after performance governor changes Huaisheng HS1 Ye
2017-07-24 11:36 ` Rafael J. Wysocki
2017-07-24 15:32   ` Huaisheng HS1 Ye
2017-07-24 23:51     ` Rafael J. Wysocki
2017-07-25  1:46       ` Huaisheng HS1 Ye
2017-07-25  2:57         ` Srinivas Pandruvada
2017-07-25  7:03           ` Huaisheng HS1 Ye
2017-07-25 14:37             ` Srinivas Pandruvada
2017-07-25 15:22               ` Huaisheng HS1 Ye
2017-07-25 21:46             ` Rafael J. Wysocki [this message]
2017-07-25 15:35           ` Rafael J. Wysocki
2017-07-25 22:42             ` [PATCH] cpufreq: intel_pstate: Drop ->get from intel_pstate structure Rafael J. Wysocki
2017-07-27  3:47               ` Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6482077.jWgIauTCtV@aspire.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=chengnt@lenovo.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=viresh.kumar@linaro.org \
    --cc=yehs1@lenovo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox