From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux PM <linux-pm@vger.kernel.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Doug Smythies <dsmythies@telus.net>
Subject: [PATCH 1/5] cpufreq: intel_pstate: Support HWP processors in all operation modes
Date: Wed, 22 Mar 2017 23:52:18 +0100 [thread overview]
Message-ID: <1516950.NJ47SGUCpy@aspire.rjw.lan> (raw)
In-Reply-To: <2025489.DxMTzKos7o@aspire.rjw.lan>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently, some processors supporting HWP are only supported by
intel_pstate if HWP is actually going to be used and not supported
otherwise which is confusing.
Specifically, they are not supported if "intel_pstate=no_hwp" is
passed to the kernel in the command line or if the driver is started
in the passive mode ("intel_pstate=passive").
There is no real reason for that, because everything about those
processor is known anyway and the driver can work with them in all
modes, so make that happen, but use the load-based P-state selection
algorithm for the active mode "powersave" policy with them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/cpufreq/intel_pstate.c | 35 ++++++++++++++++++++---------------
1 file changed, 20 insertions(+), 15 deletions(-)
Index: linux-pm/drivers/cpufreq/intel_pstate.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -2627,28 +2627,33 @@ static const struct x86_cpu_id hwp_suppo
static int __init intel_pstate_init(void)
{
- const struct x86_cpu_id *id;
- struct cpu_defaults *cpu_def;
- int rc = 0;
+ int rc;
if (no_load)
return -ENODEV;
- if (x86_match_cpu(hwp_support_ids) && !no_hwp) {
+ if (x86_match_cpu(hwp_support_ids)) {
copy_cpu_funcs(&core_params.funcs);
- hwp_active++;
- intel_pstate.attr = hwp_cpufreq_attrs;
- goto hwp_cpu_matched;
- }
-
- id = x86_match_cpu(intel_pstate_cpu_ids);
- if (!id)
- return -ENODEV;
+ if (no_hwp) {
+ pstate_funcs.get_target_pstate = get_target_pstate_use_cpu_load;
+ } else {
+ hwp_active++;
+ intel_pstate.attr = hwp_cpufreq_attrs;
+ goto hwp_cpu_matched;
+ }
+ } else {
+ const struct x86_cpu_id *id;
+ struct cpu_defaults *cpu_def;
+
+ id = x86_match_cpu(intel_pstate_cpu_ids);
+ if (!id)
+ return -ENODEV;
- cpu_def = (struct cpu_defaults *)id->driver_data;
+ cpu_def = (struct cpu_defaults *)id->driver_data;
- copy_pid_params(&cpu_def->pid_policy);
- copy_cpu_funcs(&cpu_def->funcs);
+ copy_pid_params(&cpu_def->pid_policy);
+ copy_cpu_funcs(&cpu_def->funcs);
+ }
if (intel_pstate_msrs_not_valid())
return -ENODEV;
next prev parent reply other threads:[~2017-03-22 23:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 22:50 [PATCH 0/5] cpufreq: intel_pstate: HW support changes, limits rework and documentation Rafael J. Wysocki
2017-03-22 22:52 ` Rafael J. Wysocki [this message]
2017-03-22 22:53 ` [PATCH 2/5] cpufreq: intel_pstate: Use load-based P-state selection more widely Rafael J. Wysocki
2017-03-22 22:58 ` [PATCH 3/5] cpufreq: intel_pstate: Active mode P-state limits rework Rafael J. Wysocki
2017-03-22 23:00 ` [PATCH 4/5] cpufreq: intel_pstate: Avoid transient updates of cpuinfo.max_freq Rafael J. Wysocki
2017-03-22 23:32 ` [PATCH 5/5] cpufreq: intel_pstate: Document the current behavior and user interface Rafael J. Wysocki
2017-03-30 21:01 ` [Update][PATCH v2 " Rafael J. Wysocki
2017-04-18 14:24 ` Rafael J. Wysocki
2017-05-05 21:38 ` [Resend][PATCH] " Rafael J. Wysocki
2017-05-12 20:47 ` Rafael J. Wysocki
2017-05-12 21:20 ` Jonathan Corbet
2017-05-12 21:42 ` Rafael J. Wysocki
2017-03-27 6:32 ` [PATCH 5/5] " Doug Smythies
2017-03-30 0:19 ` Rafael J. Wysocki
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=1516950.NJ47SGUCpy@aspire.rjw.lan \
--to=rjw@rjwysocki.net \
--cc=corbet@lwn.net \
--cc=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=srinivas.pandruvada@linux.intel.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
all inboxes | Powered by JetHome®