1. 05 Mar, 2017 1 commit
    • Len Brown's avatar
      cpufreq: Add the "cpufreq.off=1" cmdline option · d82f2692
      Len Brown authored
      Add the "cpufreq.off=1" cmdline option.
      
      At boot-time, this allows a user to request CONFIG_CPU_FREQ=n
      behavior from a kernel built with CONFIG_CPU_FREQ=y.
      
      This is analogous to the existing "cpuidle.off=1" option
      and CONFIG_CPU_IDLE=y
      
      This capability is valuable when we need to debug end-user
      issues in the BIOS or in Linux.  It is also convenient
      for enabling comparisons, which may otherwise require a new kernel,
      or help from BIOS SETUP, which may be buggy or unavailable.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d82f2692
  2. 04 Mar, 2017 3 commits
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Avoid triggering cpu_frequency tracepoint unnecessarily · 64078299
      Rafael J. Wysocki authored
      In the passive mode the cpu_frequency trace event is already
      triggered by the cpufreq core or by scaling governors, so
      intel_pstate should not trigger it once again for the same
      P-state updates.
      
      In addition to that, the frequency returned by
      intel_cpufreq_fast_switch() and passed via freqs.new from
      intel_cpufreq_target() to cpufreq_freq_transition_end() should
      reflect the P-state actually set, so make that happen.
      
      Fixes: 001c76f0 (cpufreq: intel_pstate: Generic governors support)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      64078299
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Fix intel_cpufreq_verify_policy() · 7f17326f
      Rafael J. Wysocki authored
      The intel_pstate_update_perf_limits() called from
      intel_cpufreq_verify_policy() may cause global P-state limits
      to change which is generally confusing and unnecessary.
      
      In the passive mode the global limits are only applied to the
      frequency selected by the scaling governor (they are not taken
      into account by governors when making decisions anyway), so making
      them follow the per-policy limits serves no purpose and may go
      against user expectations (as it generally causes the global
      attributes in sysfs to change even though they have not been
      written to in some cases).
      
      Fix that by dropping the intel_pstate_update_perf_limits()
      invocation from intel_cpufreq_verify_policy() (which also
      reduces the code size by a few lines).
      
      This change does not affect the per-CPU limits case, because those
      limits allow any P-state to be set by default in the passive mode
      and it removes the only piece of code updating them in that mode,
      so the per-policy settings will be the only ones taken into account
      in that case as expected.
      
      Fixes: 001c76f0 (cpufreq: intel_pstate: Generic governors support)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7f17326f
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Do not use performance_limits in passive mode · 2bc756e7
      Rafael J. Wysocki authored
      Using performance_limits in the passive mode doesn't make
      sense, because in that mode the global limits are applied to the
      frequency selected by the scaling governor.
      
      The maximum and minimum P-state limits in performance_limits are both
      set to 100 percent which will put all CPUs into the turbo range
      regardless of what governor is used and what frequencies are
      selected by it (that is particularly undesirable on CPUs with the
      generic powersave governor attached).
      
      For this reason, make intel_pstate_register_driver() always point
      limits to powersave_limits in the passive mode.
      
      Fixes: 001c76f0 (cpufreq: intel_pstate: Generic governors support)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2bc756e7
  3. 28 Feb, 2017 1 commit
  4. 23 Feb, 2017 1 commit
  5. 18 Feb, 2017 1 commit
  6. 16 Feb, 2017 1 commit
  7. 15 Feb, 2017 2 commits
  8. 09 Feb, 2017 14 commits
  9. 07 Feb, 2017 1 commit
  10. 03 Feb, 2017 14 commits
  11. 30 Jan, 2017 1 commit