1. 01 Dec, 2016 2 commits
  2. 30 Nov, 2016 1 commit
  3. 28 Nov, 2016 4 commits
  4. 22 Nov, 2016 2 commits
  5. 21 Nov, 2016 4 commits
    • Rafael J. Wysocki's avatar
      cpufreq: Make cpufreq_update_policy() void · 30248fef
      Rafael J. Wysocki authored
      The return value of cpufreq_update_policy() is never used, so make
      it void.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      30248fef
    • Rafael J. Wysocki's avatar
      ACPI / processor: Make acpi_processor_ppc_has_changed() void · bca5f557
      Rafael J. Wysocki authored
      The return value of acpi_processor_ppc_has_changed() is never used,
      so make it void.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      bca5f557
    • Rafael J. Wysocki's avatar
      cpufreq: Avoid using inactive policies · 182e36af
      Rafael J. Wysocki authored
      There are two places in the cpufreq core in which low-level driver
      callbacks may be invoked for an inactive cpufreq policy, which isn't
      guaranteed to work in general.  Both are due to possible races with
      CPU offline.
      
      First, in cpufreq_get(), the policy may become inactive after
      the check against policy->cpus in cpufreq_cpu_get() and before
      policy->rwsem is acquired, in which case using it going forward may
      not be correct.
      
      Second, an analogous situation is possible in cpufreq_update_policy().
      
      Avoid using inactive policies by adding policy_is_inactive() checks
      to the code in the above places.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      182e36af
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Generic governors support · 001c76f0
      Rafael J. Wysocki authored
      There may be reasons to use generic cpufreq governors (eg. schedutil)
      on Intel platforms instead of the intel_pstate driver's internal
      governor.  However, that currently can only be done by disabling
      intel_pstate altogether and using the acpi-cpufreq driver instead
      of it, which is subject to limitations.
      
      First of all, acpi-cpufreq only works on systems where the _PSS
      object is present in the ACPI tables for all logical CPUs.  Second,
      on those systems acpi-cpufreq will only use frequencies listed by
      _PSS which may be suboptimal.  In particular, by convention, the
      whole turbo range is represented in _PSS as a single P-state and
      the frequency assigned to it is greater by 1 MHz than the greatest
      non-turbo frequency listed by _PSS.  That may confuse governors to
      use turbo frequencies less frequently which may lead to suboptimal
      performance.
      
      For this reason, make it possible to use the intel_pstate driver
      with generic cpufreq governors as a "normal" cpufreq driver.  That
      mode is enforced by adding intel_pstate=passive to the kernel
      command line and cannot be disabled at run time.  In that mode,
      intel_pstate provides a cpufreq driver interface including
      the ->target() and ->fast_switch() callbacks and is listed in
      scaling_driver as "intel_cpufreq".
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: default avatarDoug Smythies <dsmythies@telus.net>
      001c76f0
  6. 17 Nov, 2016 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Request P-states control from SMM if needed · d0ea59e1
      Rafael J. Wysocki authored
      Currently, intel_pstate is unable to control P-states on my
      IvyBridge-based Acer Aspire S5, because they are controlled by SMM
      on that machine by default and it is necessary to request OS control
      of P-states from it via the SMI Command register exposed in the ACPI
      FADT.  intel_pstate doesn't do that now, but acpi-cpufreq and other
      cpufreq drivers for x86 platforms do.
      
      Address this problem by making intel_pstate use the ACPI-defined
      mechanism as well.  However, intel_pstate is not modular and it
      doesn't need the module refcount tricks played by
      acpi_processor_notify_smm(), so export the core of this function
      to it as acpi_processor_pstate_control() and make it call that.
      [The changes in processor_perflib.c related to this should not
      make any functional difference for the acpi_processor_notify_smm()
      users].
      
      To be safe, only call acpi_processor_notify_smm() from intel_pstate
      if ACPI _PPC support is enabled in it.
      Suggested-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      d0ea59e1
  7. 16 Nov, 2016 4 commits
    • Geert Uytterhoeven's avatar
      cpufreq: dt: Add support for r8a7743 and r8a7745 · f0da898b
      Geert Uytterhoeven authored
      Add the compatible strings for supporting the generic cpufreq driver on
      the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f0da898b
    • Denis Kirjanov's avatar
      cpufreq: powernv: Disable preemption while checking CPU throttling state · 8a10c06a
      Denis Kirjanov authored
      With preemption turned on we can read incorrect throttling state
      while being switched to CPU on a different chip.
      
       BUG: using smp_processor_id() in preemptible [00000000] code: cat/7343
       caller is .powernv_cpufreq_throttle_check+0x2c/0x710
       CPU: 13 PID: 7343 Comm: cat Not tainted 4.8.0-rc5-dirty #1
       Call Trace:
       [c0000007d25b75b0] [c000000000971378] .dump_stack+0xe4/0x150 (unreliable)
       [c0000007d25b7640] [c0000000005162e4] .check_preemption_disabled+0x134/0x150
       [c0000007d25b76e0] [c0000000007b63ac] .powernv_cpufreq_throttle_check+0x2c/0x710
       [c0000007d25b7790] [c0000000007b6d18] .powernv_cpufreq_target_index+0x288/0x360
       [c0000007d25b7870] [c0000000007acee4] .__cpufreq_driver_target+0x394/0x8c0
       [c0000007d25b7920] [c0000000007b22ac] .cpufreq_set+0x7c/0xd0
       [c0000007d25b79b0] [c0000000007adf50] .store_scaling_setspeed+0x80/0xc0
       [c0000007d25b7a40] [c0000000007ae270] .store+0xa0/0x100
       [c0000007d25b7ae0] [c0000000003566e8] .sysfs_kf_write+0x88/0xb0
       [c0000007d25b7b70] [c0000000003553b8] .kernfs_fop_write+0x178/0x260
       [c0000007d25b7c10] [c0000000002ac3cc] .__vfs_write+0x3c/0x1c0
       [c0000007d25b7cf0] [c0000000002ad584] .vfs_write+0xc4/0x230
       [c0000007d25b7d90] [c0000000002aeef8] .SyS_write+0x58/0x100
       [c0000007d25b7e30] [c00000000000bfec] system_call+0x38/0xfc
      
      Fixes: 09a972d1 (cpufreq: powernv: Report cpu frequency throttling)
      Reviewed-by: default avatarGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8a10c06a
    • Stratos Karafotis's avatar
      cpufreq: conservative: Fix comment explaining frequency updates · 42d951c8
      Stratos Karafotis authored
      The original comment about the frequency increase to maximum is wrong.
      
      Both increase and decrease happen at steps.
      Signed-off-by: default avatarStratos Karafotis <stratosk@semaphore.gr>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      42d951c8
    • Stratos Karafotis's avatar
      cpufreq: conservative: Decrease frequency faster for deferred updates · 00bfe058
      Stratos Karafotis authored
      Conservative governor changes the CPU frequency in steps.
      That means that if a CPU runs at max frequency, it will need several
      sampling periods to return to min frequency when the workload
      is finished.
      
      If the update function that calculates the load and target frequency
      is deferred, the governor might need even more time to decrease the
      frequency.
      
      This may have impact to power consumption and after all conservative
      should decrease the frequency if there is no workload at every sampling
      rate.
      
      To resolve the above issue calculate the number of sampling periods
      that the update is deferred. Considering that for each sampling period
      conservative should drop the frequency by a freq_step because the
      CPU was idle apply the proper subtraction to requested frequency.
      
      Below, the kernel trace with and without this patch. First an
      intensive workload is applied on a specific CPU. Then the workload
      is removed and the CPU goes to idle.
      
      WITHOUT
      
           <idle>-0     [007] dN..   620.329153: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   620.350857: cpu_frequency: state=1700000 cpu_id=7
      kworker/7:2-556   [007] ....   620.370856: cpu_frequency: state=1900000 cpu_id=7
      kworker/7:2-556   [007] ....   620.390854: cpu_frequency: state=2100000 cpu_id=7
      kworker/7:2-556   [007] ....   620.411853: cpu_frequency: state=2200000 cpu_id=7
      kworker/7:2-556   [007] ....   620.432854: cpu_frequency: state=2400000 cpu_id=7
      kworker/7:2-556   [007] ....   620.453854: cpu_frequency: state=2600000 cpu_id=7
      kworker/7:2-556   [007] ....   620.494856: cpu_frequency: state=2900000 cpu_id=7
      kworker/7:2-556   [007] ....   620.515856: cpu_frequency: state=3100000 cpu_id=7
      kworker/7:2-556   [007] ....   620.536858: cpu_frequency: state=3300000 cpu_id=7
      kworker/7:2-556   [007] ....   620.557857: cpu_frequency: state=3401000 cpu_id=7
           <idle>-0     [007] d...   669.591363: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   669.591939: cpu_idle: state=4294967295 cpu_id=7
           <idle>-0     [007] d...   669.591980: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] dN..   669.591989: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   670.201224: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   670.221975: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   670.222016: cpu_frequency: state=3300000 cpu_id=7
           <idle>-0     [007] d...   670.222026: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   670.234964: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   670.801251: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.236046: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   671.236073: cpu_frequency: state=3100000 cpu_id=7
           <idle>-0     [007] d...   671.236112: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.393437: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   671.401277: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.404083: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   671.404111: cpu_frequency: state=2900000 cpu_id=7
           <idle>-0     [007] d...   671.404125: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.404974: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   671.501180: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.995414: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   671.995459: cpu_frequency: state=2800000 cpu_id=7
           <idle>-0     [007] d...   671.995469: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.996287: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.001305: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.078374: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.078410: cpu_frequency: state=2600000 cpu_id=7
           <idle>-0     [007] d...   672.078419: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.158020: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.158040: cpu_frequency: state=2400000 cpu_id=7
           <idle>-0     [007] d...   672.158044: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.160038: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.234557: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.237121: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.237174: cpu_frequency: state=2100000 cpu_id=7
           <idle>-0     [007] d...   672.237186: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.237778: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.267902: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.269860: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.269906: cpu_frequency: state=1900000 cpu_id=7
           <idle>-0     [007] d...   672.269914: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.271902: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.751342: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.823056: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.823095: cpu_frequency: state=1600000 cpu_id=7
      
      WITH
      
           <idle>-0     [007] dN..  4380.928009: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4380.949767: cpu_frequency: state=2000000 cpu_id=7
      kworker/7:2-399   [007] ....  4380.969765: cpu_frequency: state=2200000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.009766: cpu_frequency: state=2500000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.029767: cpu_frequency: state=2600000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.049769: cpu_frequency: state=2800000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.069769: cpu_frequency: state=3000000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.089771: cpu_frequency: state=3100000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.109772: cpu_frequency: state=3400000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.129773: cpu_frequency: state=3401000 cpu_id=7
           <idle>-0     [007] d...  4428.226159: cpu_idle: state=1 cpu_id=7
           <idle>-0     [007] d...  4428.226176: cpu_idle: state=4294967295 cpu_id=7
           <idle>-0     [007] d...  4428.226181: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.227177: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...  4428.551640: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.649239: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4428.649268: cpu_frequency: state=2800000 cpu_id=7
           <idle>-0     [007] d...  4428.649278: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.689856: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...  4428.799542: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.801683: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4428.801748: cpu_frequency: state=1700000 cpu_id=7
           <idle>-0     [007] d...  4428.801761: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.806545: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...  4429.051880: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4429.086240: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4429.086293: cpu_frequency: state=1600000 cpu_id=7
      
      Without the patch the CPU dropped to min frequency after 3.2s
      With the patch applied the CPU dropped to min frequency after 0.86s
      Signed-off-by: default avatarStratos Karafotis <stratosk@semaphore.gr>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      00bfe058
  8. 14 Nov, 2016 3 commits
  9. 11 Nov, 2016 6 commits
  10. 01 Nov, 2016 11 commits
  11. 30 Oct, 2016 1 commit
  12. 24 Oct, 2016 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Always set max P-state in performance mode · 2f1d407a
      Rafael J. Wysocki authored
      The only times at which intel_pstate checks the policy set for
      a given CPU is the initialization of that CPU and updates of its
      policy settings from cpufreq when intel_pstate_set_policy() is
      invoked.
      
      That is insufficient, however, because intel_pstate uses the same
      P-state selection function for all CPUs regardless of the policy
      setting for each of them and the P-state limits are shared between
      them.  Thus if the policy is set to "performance" for a particular
      CPU, it may not behave as expected if the cpufreq settings are
      changed subsequently for another CPU.
      
      That can be easily demonstrated by writing "performance" to
      scaling_governor for all CPUs and then switching it to "powersave"
      for one of them in which case all of the CPUs will behave as though
      their scaling_governor were all "powersave" (even though the policy
      still appears to be "performance" for the remaining CPUs).
      
      Fix this problem by modifying intel_pstate_adjust_busy_pstate() to
      always set the P-state to the maximum allowed by the current limits
      for all CPUs whose policy is set to "performance".
      
      Note that it still is recommended to always change the policy setting
      in the same way for all CPUs even with this fix applied to avoid
      confusion.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2f1d407a