1. 22 Nov, 2016 2 commits
  2. 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
  3. 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
  4. 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
  5. 14 Nov, 2016 3 commits
  6. 11 Nov, 2016 6 commits
  7. 01 Nov, 2016 11 commits
  8. 30 Oct, 2016 1 commit
  9. 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
  10. 21 Oct, 2016 5 commits
  11. 20 Oct, 2016 1 commit
    • Sergey Senozhatsky's avatar
      cpufreq: fix overflow in cpufreq_table_find_index_dl() · c6fe46a7
      Sergey Senozhatsky authored
      'best' is always less or equals to 'pos', so `best - pos' returns
      a negative value which is then getting casted to `unsigned int'
      and passed to __cpufreq_driver_target()->acpi_cpufreq_target()
      for policy->freq_table selection. This results in
      
       BUG: unable to handle kernel paging request at ffff881019b469f8
       IP: [<ffffffffa00356c1>] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq]
       PGD 267f067
       PUD 0
      
       Oops: 0000 [#1] PREEMPT SMP
       CPU: 6 PID: 70 Comm: kworker/6:1 Not tainted 4.9.0-rc1-next-20161017-dbg-dirty
       Workqueue: events dbs_work_handler
       task: ffff88041b808000 task.stack: ffff88041b810000
       RIP: 0010:[<ffffffffa00356c1>]  [<ffffffffa00356c1>] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq]
       RSP: 0018:ffff88041b813c60  EFLAGS: 00010282
       RAX: ffff880419b46a00 RBX: ffff88041b848400 RCX: ffff880419b20f80
       RDX: 00000000001dff38 RSI: 00000000ffffffff RDI: ffff88041b848400
       RBP: ffff88041b813cb0 R08: 0000000000000006 R09: 0000000000000040
       R10: ffffffff8207f9e0 R11: ffffffff8173595b R12: 0000000000000000
       R13: ffff88041f1dff38 R14: 0000000000262900 R15: 0000000bfffffff4
       FS:  0000000000000000(0000) GS:ffff88041f000000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: ffff881019b469f8 CR3: 000000041a2d3000 CR4: 00000000001406e0
       Stack:
        ffff88041b813cb0 ffffffff813347f9 ffff88041b813ca0 ffffffff81334663
        ffff88041f1d4bc0 ffff88041b848400 0000000000000000 0000000000000000
        0000000000262900 0000000000000000 ffff88041b813d00 ffffffff813355dc
       Call Trace:
        [<ffffffff813347f9>] ? cpufreq_freq_transition_begin+0xf1/0xfc
        [<ffffffff81334663>] ? get_cpu_idle_time+0x97/0xa6
        [<ffffffff813355dc>] __cpufreq_driver_target+0x3b6/0x44e
        [<ffffffff81336ca3>] cs_dbs_timer+0x11a/0x135
        [<ffffffff81336fda>] dbs_work_handler+0x39/0x62
        [<ffffffff81057823>] process_one_work+0x280/0x4a5
        [<ffffffff81058719>] worker_thread+0x24f/0x397
        [<ffffffff810584ca>] ? rescuer_thread+0x30b/0x30b
        [<ffffffff81418380>] ? nl80211_get_key+0x29/0x36a
        [<ffffffff8105d2b7>] kthread+0xfc/0x104
        [<ffffffff8107ceea>] ? put_lock_stats.isra.9+0xe/0x20
        [<ffffffff8105d1bb>] ? kthread_create_on_node+0x3f/0x3f
        [<ffffffff814b2092>] ret_from_fork+0x22/0x30
       Code: 56 4d 6b ff 0c 41 55 41 54 53 48 83 ec 28 48 8b 15 ad 1e 00 00 44 8b 41
       08 48 8b 87 c8 00 00 00 49 89 d5 4e 03 2c c5 80 b2 78 81 <46> 8b 74 38 04 45
       3b 75 00 75 11 31 c0 83 39 00 0f 84 1c 01 00
       RIP  [<ffffffffa00356c1>] acpi_cpufreq_target+0x4f/0x190 [acpi_cpufreq]
        RSP <ffff88041b813c60>
       CR2: ffff881019b469f8
       ---[ end trace 16d9fc7a17897d37 ]---
      
      [ rjw: In some cases this bug may also cause incorrect frequencies to
        be selected by cpufreq governors. ]
      
      Fixes: 899bb664 (cpufreq: skip invalid entries when searching the frequency)
      Link: http://marc.info/?l=linux-kernel&m=147672030714331&w=2Reported-and-tested-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Reported-and-tested-by: default avatarJörg Otte <jrg.otte@gmail.com>
      Signed-off-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: 4.8+ <stable@vger.kernel.org> # 4.8+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c6fe46a7
  12. 15 Oct, 2016 1 commit