#
17ffd358 |
| 05-Jan-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Use HWP capabilities in intel_cpufreq_adjust_perf()
If turbo P-states cannot be used, either due to the configuration of the processor, or because intel_pstate is not allowed
cpufreq: intel_pstate: Use HWP capabilities in intel_cpufreq_adjust_perf()
If turbo P-states cannot be used, either due to the configuration of the processor, or because intel_pstate is not allowed to used them, the maximum available P-state with HWP enabled corresponds to the HWP_CAP.GUARANTEED value which is not static. It can be adjusted by an out-of-band agent or during an Intel Speed Select performance level change, so long as it remains less than or equal to HWP_CAP.MAX.
However, if turbo P-states cannot be used, intel_cpufreq_adjust_perf() always uses pstate.max_pstate (set during the initialization of the driver only) as the maximum available P-state, so it may miss a change of the HWP_CAP.GUARANTEED value.
Prevent that from happening by modifyig intel_cpufreq_adjust_perf() to always read the "guaranteed" and "maximum turbo" performance levels from the cached HWP_CAP value.
Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
show more ...
|
#
be128345 |
| 29-Dec-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Fix fast-switch fallback path
When sugov_update_single_perf() falls back to the "frequency" path due to the missing scale-invariance, it will call cpufreq_driver_fast_switch()
cpufreq: intel_pstate: Fix fast-switch fallback path
When sugov_update_single_perf() falls back to the "frequency" path due to the missing scale-invariance, it will call cpufreq_driver_fast_switch() via sugov_fast_switch() and the driver's ->fast_switch() callback will be invoked, so it must not be NULL.
However, after commit a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") intel_pstate sets ->fast_switch() to NULL when it is going to use intel_cpufreq_adjust_perf(), which is a mistake, because on x86 the scale-invariance may be turned off dynamically, so modify it to retain the original ->adjust_perf() callback pointer.
Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") Reported-by: Kenneth R. Crudup <kenny@panix.com> Tested-by: Kenneth R. Crudup <kenny@panix.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
e40ad84c |
| 17-Dec-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Use most recent guaranteed performance values
When turbo has been disabled by the BIOS, but HWP_CAP.GUARANTEED is changed later, user space may want to take advantage of this
cpufreq: intel_pstate: Use most recent guaranteed performance values
When turbo has been disabled by the BIOS, but HWP_CAP.GUARANTEED is changed later, user space may want to take advantage of this increased guaranteed performance.
HWP_CAP.GUARANTEED is not a static value. It can be adjusted by an out-of-band agent or during an Intel Speed Select performance level change. The HWP_CAP.MAX is still the maximum achievable performance with turbo disabled by the BIOS, so HWP_CAP.GUARANTEED can still change as long as it remains less than or equal to HWP_CAP.MAX.
When HWP_CAP.GUARANTEED is changed, the sysfs base_frequency attribute shows the most recent guaranteed frequency value. This attribute can be used by user space software to update the scaling min/max limits of the CPU.
Currently, the ->setpolicy() callback already uses the latest HWP_CAP values when setting HWP_REQ, but the ->verify() callback will restrict the user settings to the to old guaranteed performance value which prevents user space from making use of the extra CPU capacity theoretically available to it after increasing HWP_CAP.GUARANTEED.
To address this, read HWP_CAP in intel_pstate_verify_cpu_policy() to obtain the maximum P-state that can be used and use that to confine the policy max limit instead of using the cached and possibly stale pstate.max_freq value for this purpose.
For consistency, update intel_pstate_update_perf_limits() to use the maximum available P-state returned by intel_pstate_get_hwp_max() to compute the maximum frequency instead of using the return value of intel_pstate_get_max_freq() which, again, may be stale.
This issue is a side-effect of fixing the scaling frequency limits in commit eacc9c5a927e ("cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled") which corrected the setting of the reduced scaling frequency values, but caused stale HWP_CAP.GUARANTEED to be used in the case at hand.
Fixes: eacc9c5a927e ("cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled") Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 5.8+ <stable@vger.kernel.org> # 5.8+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
a365ab6b |
| 14-Dec-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Implement the ->adjust_perf() callback
Make intel_pstate expose the ->adjust_perf() callback when it operates in the passive mode with HWP enabled which causes the schedutil g
cpufreq: intel_pstate: Implement the ->adjust_perf() callback
Make intel_pstate expose the ->adjust_perf() callback when it operates in the passive mode with HWP enabled which causes the schedutil governor to use that callback instead of ->fast_switch().
The minimum and target performance-level values passed by the governor to ->adjust_perf() are converted to HWP.REQ.MIN and HWP.REQ.DESIRED, respectively, which allows the processor to adjust its configuration to maximize energy-efficiency while providing sufficient capacity.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
2554c32f |
| 12-Nov-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Simplify intel_cpufreq_update_pstate()
Avoid doing the same assignment in both branches of a conditional, do it after the whole conditional instead.
Signed-off-by: Rafael J.
cpufreq: intel_pstate: Simplify intel_cpufreq_update_pstate()
Avoid doing the same assignment in both branches of a conditional, do it after the whole conditional instead.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
fcb3a1ab |
| 10-Nov-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Take CPUFREQ_GOV_STRICT_TARGET into account
Make intel_pstate take the new CPUFREQ_GOV_STRICT_TARGET governor flag into account when it operates in the passive mode with HWP e
cpufreq: intel_pstate: Take CPUFREQ_GOV_STRICT_TARGET into account
Make intel_pstate take the new CPUFREQ_GOV_STRICT_TARGET governor flag into account when it operates in the passive mode with HWP enabled, so as to fix the "powersave" governor behavior in that case (currently, HWP is allowed to scale the performance all the way up to the policy max limit when the "powersave" governor is used, but it should be constrained to the policy min limit then).
Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 5.9+ <stable@vger.kernel.org> # 5.9+: 9a2a9ebc0a75 cpufreq: Introduce governor flags Cc: 5.9+ <stable@vger.kernel.org> # 5.9+: 218f66870181 cpufreq: Introduce CPUFREQ_GOV_STRICT_TARGET Cc: 5.9+ <stable@vger.kernel.org> # 5.9+: ea9364bbadf1 cpufreq: Add strict_target to struct cpufreq_policy
show more ...
|
#
e0be38ed |
| 23-Oct-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Avoid missing HWP max updates in passive mode
If the cpufreq policy max limit is changed when intel_pstate operates in the passive mode with HWP enabled and the "powersave" go
cpufreq: intel_pstate: Avoid missing HWP max updates in passive mode
If the cpufreq policy max limit is changed when intel_pstate operates in the passive mode with HWP enabled and the "powersave" governor is used on top of it, the HWP max limit is not updated as appropriate.
Namely, in the "powersave" governor case, the target P-state is always equal to the policy min limit, so if the latter does not change, intel_cpufreq_adjust_hwp() is not invoked to update the HWP Request MSR due to the "target_pstate != old_pstate" check in intel_cpufreq_update_pstate(), so the HWP max limit is not updated as a result.
Also, if the CPUFREQ_NEED_UPDATE_LIMITS flag is not set for the driver and the target frequency does not change along with the policy max limit, the "target_freq == policy->cur" check in __cpufreq_driver_target() prevents the driver's ->target() callback from being invoked at all, so the HWP max limit is not updated.
To prevent that occurring, set the CPUFREQ_NEED_UPDATE_LIMITS flag in the intel_cpufreq driver structure if HWP is enabled and modify intel_cpufreq_update_pstate() to do the "target_pstate != old_pstate" check only in the non-HWP case and let intel_cpufreq_adjust_hwp() always run in the HWP case (it will update HWP Request only if the cached value of the register is different from the new one including the limits, so if neither the target P-state value nor the max limit changes, the register write will still be avoided).
Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Reported-by: Zhang Rui <rui.zhang@intel.com> Cc: 5.9+ <stable@vger.kernel.org> # 5.9+: 1c534352f47f cpufreq: Introduce CPUFREQ_NEED_UPDATE_LIMITS ... Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Zhang Rui <rui.zhang@intel.com>
show more ...
|
#
cdc1719c |
| 08-Oct-2020 |
Chen Yu <yu.c.chen@intel.com> |
cpufreq: intel_pstate: Delete intel_pstate sysfs if failed to register the driver
There is a corner case that if the intel_pstate driver fails to be registered (might be due to invalid MSR access) a
cpufreq: intel_pstate: Delete intel_pstate sysfs if failed to register the driver
There is a corner case that if the intel_pstate driver fails to be registered (might be due to invalid MSR access) and acpi_cpufreq takse over, the intel_pstate sysfs interface is still populated which may confuse user space (turbostat for example):
grep . /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver acpi-cpufreq
grep . /sys/devices/system/cpu/intel_pstate/* /sys/devices/system/cpu/intel_pstate/max_perf_pct:0 /sys/devices/system/cpu/intel_pstate/min_perf_pct:0 grep: /sys/devices/system/cpu/intel_pstate/no_turbo: Resource temporarily unavailable grep: /sys/devices/system/cpu/intel_pstate/num_pstates: Resource temporarily unavailable /sys/devices/system/cpu/intel_pstate/status:off grep: /sys/devices/system/cpu/intel_pstate/turbo_pct: Resource temporarily unavailable
The mere presence of the intel_pstate sysfs interface does not mean that intel_pstate is in use (for example, echo "off" to "status"), but it should not be created in the failing case.
Fix this issue by deleting the intel_pstate sysfs if the driver registration fails.
Reported-by: Wendy Wang <wendy.wang@intel.com> Suggested-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com [ rjw: Refactor code to avoid jumps, change function name, changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
fc7d1755 |
| 27-Sep-2020 |
Zhang Rui <rui.zhang@intel.com> |
cpufreq: intel_pstate: Fix missing return statement
Fix missing return statement when writing "off" to intel_pstate status sysfs I/F.
Fixes: 55671ea3257a ("cpufreq: intel_pstate: Free memory only w
cpufreq: intel_pstate: Fix missing return statement
Fix missing return statement when writing "off" to intel_pstate status sysfs I/F.
Fixes: 55671ea3257a ("cpufreq: intel_pstate: Free memory only when turning off") Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
eacc9c5a |
| 31-Aug-2020 |
Francisco Jerez <currojerez@riseup.net> |
cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled
This fixes the behavior of the scaling_max_freq and scaling_min_freq sysfs files in systems which had turbo disabled by the B
cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled
This fixes the behavior of the scaling_max_freq and scaling_min_freq sysfs files in systems which had turbo disabled by the BIOS.
Caleb noticed that the HWP is programmed to operate in the wrong P-state range on his system when the CPUFREQ policy min/max frequency is set via sysfs. This seems to be because in his system intel_pstate_get_hwp_max() is returning the maximum turbo P-state even though turbo was disabled by the BIOS, which causes intel_pstate to scale kHz frequencies incorrectly e.g. setting the maximum turbo frequency whenever the maximum guaranteed frequency is requested via sysfs.
Tested-by: Caleb Callaway <caleb.callaway@intel.com> Signed-off-by: Francisco Jerez <currojerez@riseup.net> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> [ rjw: Minor subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
55671ea3 |
| 01-Sep-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Free memory only when turning off
When intel_pstate switches the operation mode from "active" to "passive" or the other way around, freeing its data structures representing CP
cpufreq: intel_pstate: Free memory only when turning off
When intel_pstate switches the operation mode from "active" to "passive" or the other way around, freeing its data structures representing CPUs and allocating them again from scratch is not necessary and wasteful. Moreover, if these data structures are preserved, the cached HWP Request MSR value from there may be written to the MSR to start with to reinitialize it and help to restore the EPP value set previously (it is set to 0xFF when CPUs go offline to allow their SMT siblings to use the full range of EPP values and that also happens when the driver gets unregistered).
Accordingly, modify the driver to only do a full cleanup on driver object registration errors and when its status is changed to "off" via sysfs and to write the cached HWP Request MSR value back to the MSR on CPU init if the data structure representing the given CPU is still there.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
show more ...
|
#
4adcf2e5 |
| 01-Sep-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Add ->offline and ->online callbacks
Add ->offline and ->online driver callbacks to prepare for taking a CPU offline and to restore its working configuration when it goes back
cpufreq: intel_pstate: Add ->offline and ->online callbacks
Add ->offline and ->online driver callbacks to prepare for taking a CPU offline and to restore its working configuration when it goes back online, respectively, to avoid invoking the ->init callback on every CPU online which is quite a bit of unnecessary overhead.
Define ->offline and ->online so that they can be used in the passive mode as well as in the active mode and because ->offline will do the majority of ->stop_cpu work, the passive mode does not need that callback any more, so drop it from there.
Also modify the active mode ->suspend and ->resume callbacks to prevent them from interfering with the new ->offline and ->online ones in case the latter are invoked withing the system-wide suspend and resume code flow and make the passive mode use them too.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
show more ...
|
#
b388eb58 |
| 27-Aug-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Tweak the EPP sysfs interface
Modify the EPP sysfs interface to reject attempts to change the EPP to values different from 0 ("performance") in the active mode with the "perfo
cpufreq: intel_pstate: Tweak the EPP sysfs interface
Modify the EPP sysfs interface to reject attempts to change the EPP to values different from 0 ("performance") in the active mode with the "performance" policy (ie. scaling_governor set to "performance"), to avoid situations in which the kernel appears to discard data passed to it via the EPP sysfs attribute.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
show more ...
|
#
c27a0ccc |
| 27-Aug-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Update cached EPP in the active mode
Make intel_pstate update the cached EPP value when setting the EPP via sysfs in the active mode just like it is the case in the passive mo
cpufreq: intel_pstate: Update cached EPP in the active mode
Make intel_pstate update the cached EPP value when setting the EPP via sysfs in the active mode just like it is the case in the passive mode, for consistency, but also for the benefit of subsequent changes.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
show more ...
|
#
43298db3 |
| 20-Aug-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Refuse to turn off with HWP enabled
After commit f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") it is possible to change the driver status to
cpufreq: intel_pstate: Refuse to turn off with HWP enabled
After commit f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") it is possible to change the driver status to "off" via sysfs with HWP enabled, which effectively causes the driver to unregister itself, but HWP remains active and it forces the minimum performance, so even if another cpufreq driver is loaded, it will not be able to control the CPU frequency.
For this reason, make the driver refuse to change the status to "off" with HWP enabled.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
show more ...
|
#
f6ebbcf0 |
| 06-Aug-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Implement passive mode with HWP enabled
Allow intel_pstate to work in the passive mode with HWP enabled and make it set the HWP minimum performance limit (HWP floor) to the P-
cpufreq: intel_pstate: Implement passive mode with HWP enabled
Allow intel_pstate to work in the passive mode with HWP enabled and make it set the HWP minimum performance limit (HWP floor) to the P-state value given by the target frequency supplied by the cpufreq governor, so as to prevent the HWP algorithm and the CPU scheduler from working against each other, at least when the schedutil governor is in use, and update the intel_pstate documentation accordingly.
Among other things, this allows utilization clamps to be taken into account, at least to a certain extent, when intel_pstate is in use and makes it more likely that sufficient capacity for deadline tasks will be provided.
After this change, the resulting behavior of an HWP system with intel_pstate in the passive mode should be close to the behavior of the analogous non-HWP system with intel_pstate in the passive mode, except that the HWP algorithm is generally allowed to make the CPU run at a frequency above the floor P-state set by intel_pstate in the entire available range of P-states, while without HWP a CPU can run in a P-state above the requested one if the latter falls into the range of turbo P-states (referred to as the turbo range) or if the P-states of all CPUs in one package are coordinated with each other at the hardware level.
[Note that in principle the HWP floor may not be taken into account by the processor if it falls into the turbo range, in which case the processor has a license to choose any P-state, either below or above the HWP floor, just like a non-HWP processor in the case when the target P-state falls into the turbo range.]
With this change applied, intel_pstate in the passive mode assumes complete control over the HWP request MSR and concurrent changes of that MSR (eg. via the direct MSR access interface) are overridden by it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net>
show more ...
|
#
4daca379 |
| 03-Aug-2020 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
cpufreq: intel_pstate: Fix cpuinfo_max_freq when MSR_TURBO_RATIO_LIMIT is 0
The MSR_TURBO_RATIO_LIMIT can be 0. This is not an error. User can update this MSR via BIOS settings on some systems or ca
cpufreq: intel_pstate: Fix cpuinfo_max_freq when MSR_TURBO_RATIO_LIMIT is 0
The MSR_TURBO_RATIO_LIMIT can be 0. This is not an error. User can update this MSR via BIOS settings on some systems or can use msr tools to update. Also some systems boot with value = 0.
This results in display of cpufreq/cpuinfo_max_freq wrong. This value will be equal to cpufreq/base_frequency, even though turbo is enabled.
But platform will still function normally in HWP mode as we get max 1-core frequency from the MSR_HWP_CAPABILITIES. This MSR is already used to calculate cpu->pstate.turbo_freq, which is used for to set policy->cpuinfo.max_freq. But some other places cpu->pstate.turbo_pstate is used. For example to set policy->max.
To fix this, also update cpu->pstate.turbo_pstate when updating cpu->pstate.turbo_freq.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
de002c55 |
| 28-Jul-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Fix EPP setting via sysfs in active mode
Because intel_pstate_set_energy_pref_index() reads and writes the MSR_HWP_REQUEST register without using the cached value of it used b
cpufreq: intel_pstate: Fix EPP setting via sysfs in active mode
Because intel_pstate_set_energy_pref_index() reads and writes the MSR_HWP_REQUEST register without using the cached value of it used by intel_pstate_hwp_boost_up() and intel_pstate_hwp_boost_down(), those functions may overwrite the value written by it and so the EPP value set via sysfs may be lost.
To avoid that, make intel_pstate_set_energy_pref_index() take the cached value of MSR_HWP_REQUEST just like the other two routines mentioned above and update it with the new EPP value coming from user space in addition to updating the MSR.
Note that the MSR itself still needs to be updated too in case hwp_boost is unset or the boosting mechanism is not active at the EPP change time.
Fixes: e0efd5be63e8 ("cpufreq: intel_pstate: Add HWP boost utility and sched util hooks") Reported-by: Francisco Jerez <currojerez@riseup.net> Cc: 4.18+ <stable@vger.kernel.org> # 4.18+: 3da97d4db8ee cpufreq: intel_pstate: Rearrange ... Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net>
show more ...
|
#
3a957176 |
| 27-Jul-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Rearrange the storing of new EPP values
Move the locking away from intel_pstate_set_energy_pref_index() into its only caller and drop the (now redundant) return_pref label fro
cpufreq: intel_pstate: Rearrange the storing of new EPP values
Move the locking away from intel_pstate_set_energy_pref_index() into its only caller and drop the (now redundant) return_pref label from it.
Also move the "raw" EPP value check into the caller of that function, so as to do it before acquiring the mutex, and reduce code duplication related to the "raw" EPP values processing somewhat.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net>
show more ...
|
#
7aa10312 |
| 14-Jul-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Avoid enabling HWP if EPP is not supported
Although there are processors supporting hardware-managed P-states (HWP) without the energy-performance preference (EPP) feature, th
cpufreq: intel_pstate: Avoid enabling HWP if EPP is not supported
Although there are processors supporting hardware-managed P-states (HWP) without the energy-performance preference (EPP) feature, they are not expected to be run with HWP enabled (the BIOS should disable HWP on those systems). Missing EPP support generally indicates an incomplete HWP implementation and so it is better to avoid using HWP on those systems in production.
However, intel_pstate currently enables HWP on such systems, which is questionable, so prevent it from doing that by making it check EPP support before enabling HWP and avoid enabling it if EPP is not supported by the processor at hand.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
23a522e3 |
| 15-Jul-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Clean up aperf_mperf_shift description
The kerneldoc description of the aperf_mperf_shift field in struct global_params is unclear and there is a typo in it, so simplify it an
cpufreq: intel_pstate: Clean up aperf_mperf_shift description
The kerneldoc description of the aperf_mperf_shift field in struct global_params is unclear and there is a typo in it, so simplify it and clean it up.
Reported-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Lee Jones <lee.jones@linaro.org>
show more ...
|
#
8f23d1f1 |
| 15-Jul-2020 |
Lee Jones <lee.jones@linaro.org> |
cpufreq: intel_pstate: Supply struct attribute description for get_aperf_mperf_shift()
Fixes the following W=1 kernel build warning(s):
drivers/cpufreq/intel_pstate.c:293: warning: Function parame
cpufreq: intel_pstate: Supply struct attribute description for get_aperf_mperf_shift()
Fixes the following W=1 kernel build warning(s):
drivers/cpufreq/intel_pstate.c:293: warning: Function parameter or member 'get_aperf_mperf_shift' not described in 'pstate_funcs'
Suggested-by: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Remove line break ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
39a188b8 |
| 13-Jul-2020 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: intel_pstate: Fix active mode setting from command line
If intel_pstate starts in the passive mode by default (that happens when the processor in the system doesn't support HWP), passing in
cpufreq: intel_pstate: Fix active mode setting from command line
If intel_pstate starts in the passive mode by default (that happens when the processor in the system doesn't support HWP), passing intel_pstate=active in the kernel command line doesn't work, so fix that.
Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default without HWP") Reported-by: Doug Smythies <dsmythies@telus.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Doug Smythies <dsmythies@telus.net>
show more ...
|
#
3ff79754 |
| 09-Jul-2020 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
cpufreq: intel_pstate: Fix static checker warning for epp variable
Fix warning for: drivers/cpufreq/intel_pstate.c:731 store_energy_performance_preference() error: uninitialized symbol 'epp'.
This
cpufreq: intel_pstate: Fix static checker warning for epp variable
Fix warning for: drivers/cpufreq/intel_pstate.c:731 store_energy_performance_preference() error: uninitialized symbol 'epp'.
This warning is for a case, when energy_performance_preference attribute matches pre defined strings. In this case the value of raw epp will not be used to set EPP bits in MSR_HWP_REQUEST. So initializing with any value is fine.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
f473bf39 |
| 26-Jun-2020 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
cpufreq: intel_pstate: Allow raw energy performance preference value
Currently using attribute "energy_performance_preference", user space can write one of the four per-defined preference string. Th
cpufreq: intel_pstate: Allow raw energy performance preference value
Currently using attribute "energy_performance_preference", user space can write one of the four per-defined preference string. These preference strings gets mapped to a hard-coded Energy-Performance Preference (EPP) or Energy-Performance Bias (EPB) knob.
These four values are supposed to cover broad spectrum of use cases, but are not uniformly distributed in the range. There are number of cases, where this is not enough. For example:
Suppose user wants more performance when connected to AC. Instead of using default "balance performance", the "performance" setting can be used. This changes EPP value from 0x80 to 0x00. But setting EPP to 0, results in electrical and thermal issues on some platforms. This results in aggressive throttling, which causes a drop in performance. But some value between 0x80 and 0x00 results in better performance. But that value can't be fixed as the power curve is not linear. In some cases just changing EPP from 0x80 to 0x75 is enough to get significant performance gain.
Similarly on battery the default "balance_performance" mode can be aggressive in power consumption. But picking up the next choice "balance power" results in too much loss of performance, which results in bad user experience in use cases like "Google Hangout". It was observed that some value between these two EPP is optimal.
This change allows fine grain EPP tuning for platform like Chromebook or for users who wants to fine tune power and performance. Here based on the product and use cases, different EPP values can be set. This change is similar to the change done for: /sys/devices/system/cpu/cpu*/power/energy_perf_bias where user has choice to write a predefined string or raw value.
The change itself is trivial. When user preference doesn't match predefined string preferences and value is an unsigned integer and in range, use that value for EPP. When the EPP feature is not present writing raw value is not supported.
Suggested-by: Len Brown <lenb@kernel.org> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|