i.MX8MM shares same cpu-freq driver with i.MX8MQ, but
its EVK board has a PMIC which can scale VDD_ARM voltage
according to voltage defined in dtb, add support for it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
According to datasheet Rev-D, on B0 part, below CPU
freq needs to be supported:
500MHz for RUN mode;
720MHz for HSRUN mode.
To achieve best accurate frequency for CPU, adjust
SPLL's frequency for SPLL_PFD0 which is CPU's
clock source:
SPLL 528MHz -> SPLL_PFD0 500.2MHz;
SPLL 480MHz -> SPLL_PFD0 720MHz;
Remove CPU RUN/HSRUN mode switch, since it is implemented
as clock mux, whenever clock parent is switched, the
RUN/HSRUN mode will be changed accordingly.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
On i.MX8MQ, since the OPP table is initialized in cpu-freq platform
device register according to chip type, so no need to redo the OPP
table initialization in cpu-freq driver, this patch adds check for
OPP table initialization to avoid below warning during boot up:
[ 1.468378] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 1501
[ 1.468388] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 1301
[ 1.468417] cpu cpu0: _of_add_opp_table_v1: Failed to add OPP 1300000000
[ 1.468425] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 1001
[ 1.468434] cpu cpu0: _opp_add: duplicate OPPs detected. Existing: freq: 8001
[ 1.468443] cpu cpu0: _of_add_opp_table_v1: Failed to add OPP 800000000
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Bai Ping <ping.bai@nxp.com>
For multi-cluster platforms like i.MX8QM, the best cpufreq
governor is schedutil, as common cpufreq framework decides
default cpufreq governor in static compile, so this patch
adds dynamic switch of cpufreq governor according to cluster
number, changing it via sysfs interface, although it is
ugly, but it realizes dynamic cpufreq governor select for
users.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
On i.MX6ULL EVK board, when the overdrive mode(900MHz/800MHz) is
enable, the DC regulator voltage should not be changed. Keep the
DC regulator to default 1.4V.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
Register cpu-freq cooling device if device tree
supports cooling-cells, different cluster can
have its own cooling device settings.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
For i.MX8MQ, suspend freq can use policy->max after cpu freq
table is validated, so no need to get OPP number and MAX
frequency for suspend freq now, also add necessary resource free
when probe failed.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
For i.MX8QM/8QXP, suspend freq can use policy->max after cpu
freq table is validated, so no need to get OPP number and MAX
frequency for suspend freq now, also add necessary resource free
when probe failed.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Add SIP cpu-freq support, the CPU hardware frequency
scale will be performed by ARM Trusted Firmware,
and add cpu-freq suspend support, MAX frequency will
be used during suspend.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
i.MX8MQ can run at over-drive mode which needs
increasing VDD_ARM voltage, add gpio regulator support
for over-drive mode.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Add i.MX8MQ cooling device support, when temperature
exceeds passive threshold, cpu-freq will drop to lowest
set-point, and once temperature drops below passive
threshold, cpu-freq will restore.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Add i.MX8MQ cpufreq support, current version of
EVK board does NOT support voltage scale, but next
version will add this support, so this driver only
supports cpu frequency scale, voltage scale will
be added later once new board available.
A53 CPU clock normally is from ARM_PLL, but during
ARM_PLL relock window, it will be switched to
SYS1_PLL_800M to avoid clock missing, and after
arm pll relock done, it will be switched back.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
According to the i.MX7ULP RM & datasheet, when A7 is in RUN mode,
the max CPU frequency it can run at is 500MHz, if we want to increase
the A7 CPU frequency to 800MHz, we need to change the A7 from RUN mode
to HSRUN mode. And only when A7 is in RUN mode, we can enter STOP mode
and VLLS mode.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
On i.MX6SLL, if all PLLs is bypassed in low power run mode, we can decrease
the VDD_ARM_IN and VDD_SOC_IN voltage to 0.925V to save power. a 25mV margin
is added to cover IR drop and board tolerance.
Add low power run voltage change support for i.MX6SLL.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
On i.MX6ULL, when the CPU freq is running at 198MHz or 396MHz, the system will
enter low bus mode if no device need high bus mode. The first time the system
entering low bus mode, CPU freq will be set to 24MHz, if cpufreq change the CPU
freq from 198MHz(396MHz) to 396MHz(198MHz), the CPU freq will be set to 198MHz or
396 MHz. At this time, if the CPU enter low power idle, system will hang.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
When VPU runs at 396MHz, VDDSOC_CAP's voltage
should be set to 1.275V for all set-points,
add VPU clock rate check to support this case.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
According the the latest datasheet, we updated the lowest
OPP to 198MHz. So we need to update the cpufreq code to fix
the syttem hang issue when run 'cpufreq-info' in low bus mode
on i.MX6ULL.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
On i.MX6ULL, when the system entering the low bus mode, system will enter
low power run mode in which the cpufreq is at 24MHz. If we run
'cpufreq-info' until, the cpu frequency will be change from 24MHz to 99MHz,
this will lead to system enter low power idle wrong, and system will hang
in low power idle.
Add the ARM core clock handling code to fix this issue.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
On i.MX6UL EVK board, we use a external GPIO DC regulator to control
the VDD_ARM_SOC_IN voltage, if default voltage is 1.4V when the system
is bootup. Per design team, when the highest setpoint freq is not
bigger than 528MHz, we can decrease this regulator voltage to 1.3V.
On i.MX6UL TO1.1, we add a 700MHz setpoint. When the highest setpoint
freq is 700MHz, the DC regulator should be at 1.4V to to cover the IR
drop.
Signed-off-by: Bai Ping <ping.bai@nxp.com>
Interactive governor has lived in Android sources for a very long time
and this commit is based on the code present in following branch:
https://android.googlesource.com/kernel/common android-4.4
The Interactive governor is designed for latency-sensitive workloads,
such as interactive user interfaces like the mobile phones and tablets.
The interactive governor aims to be significantly more responsive to
ramp CPU quickly up when CPU-intensive activity begins.
Existing governors sample CPU load at a particular rate, typically every
X ms and then update the frequency from a work-handler. This can lead
to under-powering UI threads for the period of time during which the
user begins interacting with a previously-idle system until the next
sample period happens.
The 'interactive' governor uses a different approach.
A real-time thread is used for scaling up, giving the remaining tasks
the CPU performance benefit, unlike existing governors which are more
likely to schedule ramp-up work to occur after your performance starved
tasks have completed.
The Android version of interactive governor also checks whether to scale
the CPU frequency up soon after coming out of idle. When the CPU comes
out of idle, the governor check if the CPU sampling is overdue or not.
If yes, it immediately starts the sampling. Otherwise, the utilization
hooks from the scheduler handle the sampling later. If the CPU is very
busy from exiting idle to when the evaluation happens, then it assumes
that the CPU is under-powered and ramps it to MAX speed.
If the CPU was not sufficiently busy to immediately ramp to MAX speed,
then the governor evaluates the CPU load since the last speed
adjustment, choosing the highest value between that longer-term load or
the short-term load since idle exit to determine the CPU speed to ramp
to.
Idle notifiers will be be handled later and are not included for now.
The core of this code is written and maintained (in Android
repositories) by Mike Chan and Todd Poyner over a long period of time.
Vireshk has made changes to to the governor to align it with the current
practices followed with mainline governors, like using utilization hooks
from the scheduler and handling kobject (for governor's sysfs directory)
in a race free manner. And of course this included general cleanup of
the governor as well.
Signed-off-by: Mike Chan <mike@android.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
These macros can be reused by governors which don't use the common
governor code present in cpufreq_governor.c and should be moved to the
relevant header.
Now that they are getting moved to the right header file, reuse them in
schedutil governor as well (that required rename of show/store
routines).
Also create gov_attr_wo() macro for write-only sysfs files, this will be
used by Interactive governor in a later patch.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
In some i.MX6 board (i.MX6UL EVK), it will have a additional
GPIO controlled DC-DC regulator. we need to change this regulator's
voltage According the maximum frequency that CPU can run at.
At present, we only need to set the voltage to minimum one, we need
to set the voltage to the maximum before suspend, resume back to the
minimum voltage after suspend.
Signed-off-by: Bai Ping <b51503@freescale.com>
(cherry picked from commit 31f0773ee7d6ba5715486a221857f2ceccb434b4)
for i.MX6SX, according to the latest datasheet, added a 198MHz setpoint in cpufreq driver.
The 198MHz setpoint is NOT enough to support playing mp3,the system will stay at a higher
setpoint and high_bus_mode. So when having a setpoint lower than 396MHz, make sure when
the cpufreq is at 396MHz or lower, the busfreq is always in low_bus_mode to save more power.
Signed-off-by: Bai Ping <b51503@freescale.com>
(cherry picked from commit 3ba9548200)
Normally, the system is booting up with higher cpufreq. In the
cpufreq set_target_index we will release the high bus mode if
the target cpu frequency is the lowest. It will release the high
bus mode and dcrease the high_bus_count.This will lead to a wrong
release of high bus mode. So, in the cpufreq_init function, if the
original frequency is not the lowest, we need request high busfreq.
Signed-off-by: Bai Ping <b51503@freescale.com>
Request high bus frequency before scaling up the CPU frequency
and release high bus frequency after scaling down the CPU frequency
Doing so makes a balance between high performance and lower power
consumption.
Signed-off-by: Bai Ping <b51503@freescale.com>
(cherry picked from commit 35c91da259)
Pfuze200 only provide one power supply for VDDARM_IN and VDDSOC_IN,
for ldo-bypass mode, we have to pretend they are different regulators
otherwise regulator famework will refuse update voltage.
Signed-off-by: Robin Gong <b38343@freescale.com>
Also squashed: MLK-10123: cpufreq: imx6q-cpufreq: initialize local variable 'i'
Signed-off-by: Robin Gong <b38343@freescale.com>
This fixes hangs on imx6sl when attempting to change cpufreq
Also make sure we reparent pll1_sys to pll1_bypass before changing it's
rate. Otherwise, it may happen that pll1_sys is "parented" to
pll1_bypass_src.
Signed-off-by: Octavian Purdila <octavian.purdila@nxp.com>
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
When VPU is running at 352MHz, SOC/PU voltage need to be
at 1.25V for 396/792MHz setpoint, as 396M setpoint is
removed, so only increase 792M setpoint's voltage.
Signed-off-by: Anson Huang <b20788@freescale.com>
This patch adds pll1, pll_bypass and pll1_bypass_src that
will be used in ARM clock switching code.
Signed-off-by: Bai Ping <b51503@freescale.com>
Updated during 4.14 rebase
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
[ Upstream commit 51c99dd2c0 ]
We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore
since the latest OPP core updates as that uses reference counting to
free resources. There are cases where no static OPPs are added (using
DT) for a platform and trying to remove the OPP table may end up
decrementing refcount which is already zero and hence generating
warnings.
Lets track if we were able to add static OPPs or not and then only
remove the table based on that. Some reshuffling of code is also done to
do that.
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit da5e79bc70 upstream.
If the policy limits change between invocations of cs_dbs_update(),
the requested frequency value stored in dbs_info may not be updated
and the function may use a stale value of it next time. Moreover, if
idle periods are takem into account by cs_dbs_update(), the requested
frequency value stored in dbs_info may be below the min policy limit,
which is incorrect.
To fix these problems, always update the requested frequency value
in dbs_info along with the local copy of it when the previous
requested frequency is beyond the policy limits and avoid decreasing
the requested frequency below the min policy limit when taking
idle periods into account.
Fixes: abb6627910 (cpufreq: conservative: Fix next frequency selection)
Fixes: 00bfe05889 (cpufreq: conservative: Decrease frequency faster for deferred updates)
Reported-by: Waldemar Rymarkiewicz <waldemarx.rymarkiewicz@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Waldemar Rymarkiewicz <waldemarx.rymarkiewicz@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2a3eb51e30 upstream.
If cppc_cpufreq.ko is deleted at the same time that tuned-adm is
changing profiles, there is a small chance that a race can occur
between cpufreq_dbs_governor_exit() and cpufreq_dbs_governor_limits()
resulting in a system failure when the latter tries to use
policy->governor_data that has been freed by the former.
This patch uses gov_dbs_data_mutex to synchronize access.
Fixes: e788892ba3 (cpufreq: governor: Get rid of governor events)
Signed-off-by: Henry Willard <henry.willard@oracle.com>
[ rjw: Subject, minor white space adjustment ]
Cc: 4.8+ <stable@vger.kernel.org> # 4.8+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 95d6c0857e upstream.
Currently, intel_pstate doesn't register if _PSS is not present on
HP Proliant systems, because it expects the firmware to take over
CPU performance scaling in that case. However, if ACPI PCCH is
present, the firmware expects the kernel to use it for CPU
performance scaling and the pcc-cpufreq driver is loaded for that.
Unfortunately, the firmware interface used by that driver is not
scalable for fundamental reasons, so pcc-cpufreq is way suboptimal
on systems with more than just a few CPUs. In fact, it is better to
avoid using it at all.
For this reason, modify intel_pstate to look for ACPI PCCH if _PSS
is not present and register if it is there. Also prevent the
pcc-cpufreq driver from trying to initialize itself if intel_pstate
has been registered already.
Fixes: fbbcdc0744 (intel_pstate: skip the driver if ACPI has power mgmt option)
Reported-by: Andreas Herrmann <aherrmann@suse.com>
Reviewed-by: Andreas Herrmann <aherrmann@suse.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Tested-by: Andreas Herrmann <aherrmann@suse.com>
Cc: 4.16+ <stable@vger.kernel.org> # 4.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d4f3388afd upstream.
Add support to specify platform specific transition_delay_us instead
of using the transition delay derived from PCC.
With commit 3d41386d55 (cpufreq: CPPC: Use transition_delay_us
depending transition_latency) we are setting transition_delay_us
directly and not applying the LATENCY_MULTIPLIER. Because of that,
on Qualcomm Centriq we can end up with a very high rate of frequency
change requests when using the schedutil governor (default
rate_limit_us=10 compared to an earlier value of 10000).
The PCC subspace describes the rate at which the platform can accept
commands on the CPPC's PCC channel. This includes read and write
command on the PCC channel that can be used for reasons other than
frequency transitions. Moreover the same PCC subspace can be used by
multiple freq domains and deriving transition_delay_us from it as we
do now can be sub-optimal.
Moreover if a platform does not use PCC for desired_perf register then
there is no way to compute the transition latency or the delay_us.
CPPC does not have a standard defined mechanism to get the transition
rate or the latency at the moment.
Given the above limitations, it is simpler to have a platform specific
transition_delay_us and rely on PCC derived value only if a platform
specific value is not available.
Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
Fixes: 3d41386d55 (cpufreq: CPPC: Use transition_delay_us depending transition_latency)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ff7c991714 upstream.
When scaling max/min settings are changed, internally they are converted
to a ratio using the max turbo 1 core turbo frequency. This works fine
when 1 core max is same irrespective of the core. But under Turbo 3.0,
this will not be the case. For example:
Core 0: max turbo pstate: 43 (4.3GHz)
Core 1: max turbo pstate: 45 (4.5GHz)
In this case 1 core turbo ratio will be maximum of all, so it will be
45 (4.5GHz). Suppose scaling max is set to 4GHz (ratio 40) for all cores
,then on core one it will be
= max_state * policy->max / max_freq;
= 43 * (4000000/4500000) = 38 (3.8GHz)
= 38
which is 200MHz less than the desired.
On core2, it will be correctly set to ratio 40 (4GHz). Same holds true
for scaling min frequency limit. So this requires usage of correct turbo
max frequency for core one, which in this case is 4.3GHz. So we need to
adjust per CPU cpu->pstate.turbo_freq using the maximum HWP ratio of that
core.
This change uses the HWP capability of a core to adjust max turbo
frequency. But since Broadwell HWP doesn't use ratios in the HWP
capabilities, we have to use legacy max 1 core turbo ratio. This is not
a problem as the HWP capabilities don't differ among cores in Broadwell.
We need to check for non Broadwell CPU model for applying this change,
though.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: 4.6+ <stable@vger.kernel.org> # 4.6+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7592019634 upstream.
According to current code implementation, detecting the long
idle period is done by checking if the interval between two
adjacent utilization update handlers is long enough. Although
this mechanism can detect if the idle period is long enough
(no utilization hooks invoked during idle period), it might
not cover a corner case: if the task has occupied the CPU
for too long which causes no context switches during that
period, then no utilization handler will be launched until this
high prio task is scheduled out. As a result, the idle_periods
field might be calculated incorrectly because it regards the
100% load as 0% and makes the conservative governor who uses
this field confusing.
Change the detection to compare the idle_time with sampling_rate
directly.
Reported-by: Artem S. Tashkinov <t.artem@mailcity.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c7d1f119c4 upstream.
If the policy limits are updated via cpufreq_update_policy() and
subsequently via sysfs, the limits stored in user_policy may be
set incorrectly.
For example, if both min and max are set via sysfs to the maximum
available frequency, user_policy.min and user_policy.max will also
be the maximum. If a policy notifier triggered by
cpufreq_update_policy() lowers both the min and the max at this
point, that change is not reflected by the user_policy limits, so
if the max is updated again via sysfs to the same lower value,
then user_policy.max will be lower than user_policy.min which
shouldn't happen. In particular, if one of the policy CPUs is
then taken offline and back online, cpufreq_set_policy() will
fail for it due to a failing limits check.
To prevent that from happening, initialize the min and max fields
of the new_policy object to the ones stored in user_policy that
were previously set via sysfs.
Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
[ rjw: Subject & changelog ]
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit b24b6478e6 ]
Ideally the de-allocation of resources should happen in the exact
opposite order in which they were allocated. It helps maintain the code
in long term, even if nothing really breaks with incorrect ordering.
That wasn't followed in cpufreq_online() and it has some
inconsistencies. For example, the symlinks were created from within
the locked region while they are removed only after putting the locks.
Also ->exit() should have been called only after the symlinks are
removed and the lock is dropped, as that was the case when ->init()
was first called.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 8913315e94 ]
When multiple CPUs are related in one cpufreq policy, the first online
CPU will be chosen by default to handle cpufreq operations. Let's take
cpu0 and cpu1 as an example.
When cpu0 is offline, policy->cpu will be shifted to cpu1. cpu1's perf
capabilities should be initialized. Otherwise, perf capabilities are 0s
and speed change can not take effect.
This patch copies perf capabilities of the first online CPU to other
shared CPUs when policy shared type is CPUFREQ_SHARED_TYPE_ANY.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Shunyong Yang <shunyong.yang@hxt-semitech.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c0f7f5b6c6 upstream.
gpstate_timer_handler() uses synchronous smp_call to set the pstate
on the requested core. This causes the below hard lockup:
smp_call_function_single+0x110/0x180 (unreliable)
smp_call_function_any+0x180/0x250
gpstate_timer_handler+0x1e8/0x580
call_timer_fn+0x50/0x1c0
expire_timers+0x138/0x1f0
run_timer_softirq+0x1e8/0x270
__do_softirq+0x158/0x3e4
irq_exit+0xe8/0x120
timer_interrupt+0x9c/0xe0
decrementer_common+0x114/0x120
-- interrupt: 901 at doorbell_global_ipi+0x34/0x50
LR = arch_send_call_function_ipi_mask+0x120/0x130
arch_send_call_function_ipi_mask+0x4c/0x130
smp_call_function_many+0x340/0x450
pmdp_invalidate+0x98/0xe0
change_huge_pmd+0xe0/0x270
change_protection_range+0xb88/0xe40
mprotect_fixup+0x140/0x340
SyS_mprotect+0x1b4/0x350
system_call+0x58/0x6c
One way to avoid this is removing the smp-call. We can ensure that the
timer always runs on one of the policy-cpus. If the timer gets
migrated to a cpu outside the policy then re-queue it back on the
policy->cpus. This way we can get rid of the smp-call which was being
used to set the pstate on the policy->cpus.
Fixes: 7bc54b652f ("timers, cpufreq/powernv: Initialize the gpstate timer as pinned")
Cc: stable@vger.kernel.org # v4.8+
Reported-by: Nicholas Piggin <npiggin@gmail.com>
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 70f6bf2a3b ]
When maxcpus=1 is in the kernel command line, the BP is responsible
for re-enabling the HWP - because currently only the APs invoke
intel_pstate_hwp_enable() during their online process - which might
put the system into unstable state after resume.
Fix this by enabling the HWP explicitly on BP during resume.
Reported-by: Doug Smythies <dsmythies@telus.net>
Suggested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Yu Chen <yu.c.chen@intel.com>
[ rjw: Subject/changelog, minor modifications ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d41386d55 upstream.
With commit e948bc8fbe (cpufreq: Cap the default transition delay
value to 10 ms) the cpufreq was not honouring the delay passed via
ACPI (PCCT). Due to which on ARM based platforms using CPPC the
cpufreq governor tries to change the frequency of CPUs faster than
expected.
This leads to continuous error messages like the following.
" ACPI CPPC: PCC check channel failed. Status=0 "
Earlier (without above commit) the default transition delay was
taken form the value passed from PCCT. Use the same value provided
by PCCT to set the transition_delay_us.
Fixes: e948bc8fbe (cpufreq: Cap the default transition delay value to 10 ms)
Signed-off-by: George Cherian <george.cherian@cavium.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit ee1f4a7daf ]
On POWERNV platform, the fields for pstates in the Power Management
Status Register (PMSR) and the Power Management Control Register
(PMCR) are 8-bits wide. On POWER8 the pstates are negatively numbered
while on POWER9 they are positively numbered.
The device-tree exports pstates as 32-bit entries. The device-tree
implementation sign-extends the 8-bit pstate values to obtain the
corresponding 32-bit entry.
Eg: On POWER8, a pstate value 0x82 [-126] is represented in the
device-tree as 0xfffffff82 while on POWER9, the same value 0x82 [130]
is represented in the device-tree as 0x00000082.
The powernv-cpufreq driver implementation represents pstates using the
integer type. In multiple places in the driver, the code interprets
the pstates extracted from the PMSR as a signed byte and assigns it to
a integer variable to get the sign-extention.
On POWER9 platforms which have greater than 128 pstates, this results
in the driver performing incorrect sign-extention, and thereby
treating a legitimate pstate (say 130) as an invalid pstates (since it
is interpreted as -126).
This patch fixes the issue by implementing a helper function to
extract Pstates from PMSR register, and correctly sign-extend it to be
consistent with the values provided by the device-tree.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
