1. 08 Dec, 2016 2 commits
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Support for energy performance hints with HWP · 984edbdc
      Srinivas Pandruvada authored
      It is possible to provide hints to the HWP algorithms in the processor
      to be more performance centric to more energy centric. These hints are
      provided by using HWP energy performance preference (EPP) or energy
      performance bias (EPB) settings.
      
      The scope of these settings is per logical processor, which means that
      each of the logical processors in the package can be programmed with a
      different value.
      
      This change provides cpufreq sysfs interface to provide hint. For each
      policy, two additional attributes will be available to check and provide
      hint. These attributes will only be present when the intel_pstate driver
      is using HWP mode.
      
      These attributes are:
       - energy_performance_available_preferences
       - energy_performance_preference
      
      To get list of supported hints:
      $ cat energy_performance_available_preferences
      default performance balance_performance balance_power power
      
      The current preference can be read or changed via cpufreq sysfs
      attribute "energy_performance_preference". Reading from this attribute
      will display current effective setting changed via any method. User can
      write any of the valid preference string to this attribute. User can
      always restore to power-on default by writing "default".
      
      Implementation
      Since these hints can be provided by direct MSR write or using some tools
      like x86_energy_perf_policy, the driver internally doesn't maintain any
      state. The user operation will result in direct read/write of MSR: 0x774
      (HWP_REQUEST_MSR). Also driver use read modify write to update other
      fields in this MSR.
      
      Summary of changes:
       - struct cpudata field epp_saved is renamed to epp_powersave, as this
         stores the value to restore once policy is switched from performance
         to powersave to restore original powersave EPP value.
       - A new struct cpudata field epp_saved is used to store the raw MSR
         EPP/EPB value when a CPU goes offline or on suspend and restore on
         online/resume. This ensures that EPP value is restored to correct
         value irrespective of the means used to set.
       - EPP/EPB value ranges are fixed for each preference, which can be
         set for the cpufreq sysfs, so user request is mapped to/from this
         range.
       - New attributes are only added when HWP is present.
       - Since EPP value of 0 is valid the fields are initialized to
         -EINVAL when not valid. The field epp_default is read only once
         after powerup to avoid reading on subsequent CPU online operation
       - New suspend callback to store epp on suspend operation
       - Don't invalidate old epp_saved field on resume and online as now
         we can restore last epp value on suspend and this field can still
         have old EPP value sampled during switch to performance from
         powersave.
       - While here optimized setting of cpu_data->epp_powersave = epp in
         intel_pstate_hwp_set() as this was done in both true and false
         paths.
       - epp/epb set function returns error to caller on failure to pass
         on to user space for display.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      984edbdc
    • Srinivas Pandruvada's avatar
      cpufreq: intel_pstate: Add locking around HWP requests · b59fe540
      Srinivas Pandruvada authored
      To avoid race conditions from multiple threads, increase the scope
      of intel_pstate_limits_lock to include HWP requests also.
      Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [ rjw: Subject ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b59fe540
  2. 01 Dec, 2016 3 commits
  3. 30 Nov, 2016 1 commit
  4. 28 Nov, 2016 4 commits
  5. 22 Nov, 2016 2 commits
  6. 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
  7. 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
  8. 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
  9. 14 Nov, 2016 3 commits
  10. 11 Nov, 2016 6 commits
  11. 01 Nov, 2016 10 commits