1. 18 Nov, 2015 6 commits
  2. 05 Nov, 2015 2 commits
  3. 02 Nov, 2015 3 commits
    • Viresh Kumar's avatar
      cpufreq: governor: Quit work-handlers early if governor is stopped · 3a91b069
      Viresh Kumar authored
      gov_queue_work() acquires cpufreq_governor_lock to allow
      cpufreq_governor_stop() to drain delayed work items possibly scheduled
      on CPUs that share the policy with a CPU being taken offline.
      
      However, the same goal may be achieved in a more straightforward way if
      the policy pointer in the struct cpu_dbs_info matching the policy CPU is
      reset upfront by cpufreq_governor_stop() under the timer_mutex belonging
      to it and checked against NULL, under the same lock, at the beginning of
      dbs_timer().
      
      In that case every instance of dbs_timer() run for a struct cpu_dbs_info
      sharing the policy pointer in question after cpufreq_governor_stop() has
      started will notice that that pointer is NULL and bail out immediately
      without queuing up any new work items.  In turn, gov_cancel_work()
      called by cpufreq_governor_stop() before destroying timer_mutex will
      wait for all of the delayed work items currently running on the CPUs
      sharing the policy to drop the mutex, so it may be destroyed safely.
      
      Make cpufreq_governor_stop() and dbs_timer() work as described and
      modify gov_queue_work() so it does not acquire cpufreq_governor_lock any
      more.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3a91b069
    • Prarit Bhargava's avatar
      intel_pstate: decrease number of "HWP enabled" messages · 539342f6
      Prarit Bhargava authored
      When booting an HWP enabled system the kernel displays one "HWP enabled"
      message for each cpu.  The messages are superfluous since HWP is globally
      enabled across all CPUs. This patch also adds an informational message
      when HWP is disabled via intel_pstate=no_hwp.
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      539342f6
    • Jon Medhurst \(Tixy\)'s avatar
      cpufreq: arm_big_little: fix frequency check when bL switcher is active · 14f1ba3a
      Jon Medhurst \(Tixy\) authored
      The check for correct frequency being set in bL_cpufreq_set_rate is
      broken when the big.LITTLE switcher is active, for two reasons.
      
       1. The 'new_rate' variable gets overwritten before the test by the
       code calculating the frequency of the old cluster.
      
       2. The frequency returned by bL_cpufreq_get_rate will be the virtual
       frequency, not the actual one the intended version of new_rate contains.
      
      This means the function always returns an error causing an endless
      stream of: "cpufreq: __target_index: Failed to change cpu frequency: -5"
      
      As the intent is to check for errors that clk_set_rate doesn't report
      lets move the check to immediately after that and directly use
      clk_get_rate, rather than the arm_big_little helpers which only confuse
      matters. Also, update the comment to be hopefully clearer about the
      purpose of the code.
      
      Fixes: 0a95e630 (cpufreq: arm_big_little: check if the frequency is set correctly)
      Signed-off-by: default avatarJon Medhurst <tixy@linaro.org>
      Acked-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarMichael Turquette <mturquette@baylibre.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      14f1ba3a
  4. 28 Oct, 2015 6 commits
  5. 16 Oct, 2015 2 commits
    • Prarit Bhargava's avatar
      cpufreq: intel_pstate: Fix intel_pstate powersave min_perf_pct value · 51443fbf
      Prarit Bhargava authored
      On systems that initialize the intel_pstate driver with the performance
      governor, and then switch to the powersave governor will not transition to
      lower cpu frequencies until /sys/devices/system/cpu/intel_pstate/min_perf_pct
      is set to a low value.
      
      The behavior of governor switching changed after commit a0475992
      ("[cpufreq] intel_pstate: honor user space min_perf_pct override on
       resume").  The commit introduced tracking of performance percentage
      changes via sysfs in order to restore userspace changes during
      suspend/resume.  The problem occurs because the global values of the newly
      introduced max_sysfs_pct and min_sysfs_pct are not lowered on the governor
      change and this causes the powersave governor to inherit the performance
      governor's settings.
      
      A simple change would have been to reset max_sysfs_pct to 100 and
      min_sysfs_pct to 0 on a governor change, which fixes the problem with
      governor switching.  However, since we cannot break userspace[1] the fix
      is now to give each governor its own limits storage area so that governor
      specific changes are tracked.
      
      I successfully tested this by booting with both the performance governor
      and the powersave governor by default, and switching between the two
      governors (while monitoring /sys/devices/system/cpu/intel_pstate/ values,
      and looking at the output of cpupower frequency-info).  Suspend/Resume
      testing was performed by Doug Smythies.
      
      [1] Systems which suspend/resume using the unmaintained pm-utils package
      will always transition to the performance governor before the suspend and
      after the resume.  This means a system using the powersave governor will
      go from powersave to performance, then suspend/resume, performance to
      powersave.  The simple change during governor changes would have been
      overwritten when the governor changed before and after the suspend/resume.
      I have submitted https://bugzilla.redhat.com/show_bug.cgi?id=1271225
      against Fedora to remove the 94cpufreq file that causes the problem.  It
      should be noted that pm-utils is obsoleted with newer versions of systemd.
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Acked-by: default avatarKristen Carlson Accardi <kristen@linux.intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      51443fbf
    • Rafael J. Wysocki's avatar
      7855e102
  6. 15 Oct, 2015 1 commit
  7. 14 Oct, 2015 6 commits
  8. 12 Oct, 2015 1 commit
  9. 11 Oct, 2015 8 commits
  10. 10 Oct, 2015 5 commits