linux-stable.git/drivers/cpufreq, branch v4.17.3

cpufreq: governors: Fix long idle detection logic in load calculation

2018-06-25T23:51:27+00:00

commit 7592019634f8473f0b0973ce79297183077bdbc2 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 
Signed-off-by: Chen Yu 
Acked-by: Viresh Kumar 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: ti-cpufreq: Fix an incorrect error return value

2018-06-25T23:51:27+00:00

commit e5d295b06d69a1924665a16a4987be475addd00f upstream.

Commit 05829d9431df (cpufreq: ti-cpufreq: kfree opp_data when
failure) has fixed a memory leak in the failure path, however
the patch returned a positive value on get_cpu_device() failure
instead of the previous negative value. Fix this incorrect error
return value properly.

Fixes: 05829d9431df (cpufreq: ti-cpufreq: kfree opp_data when failure)
Cc: 4.14+  # v4.14+
Signed-off-by: Suman Anna 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: Fix new policy initialization during limits updates via sysfs

2018-06-25T23:51:27+00:00

commit c7d1f119c48f64bebf0fa1e326af577c6152fe30 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 
Acked-by: Viresh Kumar 
[ rjw: Subject & changelog ]
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: armada-37xx: driver relies on cpufreq-dt

2018-05-14T20:25:56+00:00

Armada-37xx driver registers a cpufreq-dt driver. Not having
CONFIG_CPUFREQ_DT selected leads to a silent abort during the probe.
Prevent that situation by having the former depending on the latter.

Fixes: 92ce45fb875d7 (cpufreq: Add DVFS support for Armada 37xx)
Cc: 4.16+  # 4.16+
Signed-off-by: Miquel Raynal 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq / CPPC: Set platform specific transition_delay_us

2018-04-30T08:14:08+00:00

Add support to specify platform specific transition_delay_us instead
of using the transition delay derived from PCC.

With commit 3d41386d556d (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 
Cc: 4.14+  # 4.14+
Fixes: 3d41386d556d (cpufreq: CPPC: Use transition_delay_us depending transition_latency)
Signed-off-by: Rafael J. Wysocki

Merge tag 'powerpc-4.17-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

2018-04-28T16:45:34+00:00

Pull powerpc fixes from Michael Ellerman:
 "A bunch of fixes, mostly for existing code and going to stable.

  Our memory hot-unplug path wasn't flushing the cache before removing
  memory. That is a problem now that we are doing memory hotplug on bare
  metal.

  Three fixes for the NPU code that supports devices connected via
  NVLink (ie. GPUs). The main one tweaks the TLB flush algorithm to
  avoid soft lockups for large flushes.

  A fix for our memory error handling where we would loop infinitely,
  returning back to the bad access and hard lockup the CPU.

  Fixes for the OPAL RTC driver, which wasn't handling some error cases
  correctly.

  A fix for a hardlockup in the powernv cpufreq driver.

  And finally two fixes to our smp_send_stop(), required due to a recent
  change to use it on shutdown.

  Thanks to: Alistair Popple, Balbir Singh, Laurentiu Tudor, Mahesh
  Salgaonkar, Mark Hairgrove, Nicholas Piggin, Rashmica Gupta, Shilpasri
  G Bhat"

* tag 'powerpc-4.17-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/kvm/booke: Fix altivec related build break
  powerpc: Fix deadlock with multiple calls to smp_send_stop
  cpufreq: powernv: Fix hardlockup due to synchronous smp_call in timer interrupt
  powerpc: Fix smp_send_stop NMI IPI handling
  rtc: opal: Fix OPAL RTC driver OPAL_BUSY loops
  powerpc/mce: Fix a bug where mce loops on memory UE.
  powerpc/powernv/npu: Do a PID GPU TLB flush when invalidating a large address range
  powerpc/powernv/npu: Prevent overwriting of pnv_npu2_init_contex() callback parameters
  powerpc/powernv/npu: Add lock to prevent race in concurrent context init/destroy
  powerpc/powernv/memtrace: Let the arch hotunplug code flush cache
  powerpc/mm: Flush cache on memory hot(un)plug

cpufreq: powernv: Fix hardlockup due to synchronous smp_call in timer interrupt

2018-04-27T06:16:10+00:00

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: 7bc54b652f13 ("timers, cpufreq/powernv: Initialize the gpstate timer as pinned")
Cc: stable@vger.kernel.org # v4.8+
Reported-by: Nicholas Piggin 
Reported-by: Pridhiviraj Paidipeddi 
Signed-off-by: Shilpasri G Bhat 
Acked-by: Nicholas Piggin 
Acked-by: Viresh Kumar 
Acked-by: Vaidyanathan Srinivasan 
Signed-off-by: Michael Ellerman

cpufreq: brcmstb-avs-cpufreq: remove development debug support

2018-04-24T09:34:57+00:00

This debug code was helpful while developing the driver, but it isn't
being used for anything anymore.

Signed-off-by: Markus Mayer 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Drop cpufreq_table_validate_and_show()

2018-04-10T06:40:45+00:00

This isn't used anymore. Remove the helper and update documentation
accordingly.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: SCMI: Don't validate the frequency table twice

2018-04-10T06:39:55+00:00

The cpufreq core is already validating the CPU frequency table after
calling the ->init() callback of the cpufreq drivers and the drivers
don't need to do the same anymore. Though they need to set the
policy->freq_table field directly from the ->init() callback now.

Stop validating the frequency table from SCMI driver.

Signed-off-by: Viresh Kumar 
Acked-by: Sudeep Holla 
Signed-off-by: Rafael J. Wysocki