1. 08 Nov, 2017 1 commit
  2. 28 Sep, 2017 1 commit
  3. 14 May, 2017 1 commit
  4. 13 Mar, 2017 1 commit
  5. 09 Mar, 2017 1 commit
  6. 03 Feb, 2017 3 commits
  7. 04 Jan, 2017 1 commit
  8. 08 Dec, 2016 1 commit
  9. 11 Nov, 2016 1 commit
  10. 01 Nov, 2016 1 commit
  11. 21 Oct, 2016 1 commit
  12. 08 Sep, 2016 1 commit
  13. 22 Jul, 2016 1 commit
    • Andreas Herrmann's avatar
      Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency" · da7d3abe
      Andreas Herrmann authored
      This reverts commit 790d849b.
      Using a v4.7-rc7 kernel on a HP ProLiant triggered following messages
       pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
       cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor
      The last line was shown for each CPU in the system.
      Testing v4.5 (where commit 790d849b was integrated) triggered
      similar messages. Same behaviour on a 2nd HP Proliant system.
      So commit 790d849b (cpufreq: pcc-cpufreq: update default value of
      cpuinfo_transition_latency) causes the system to use performance
      governor which, I guess, was not the intention of the patch.
      Enabling debug output in pcc-cpufreq provides following verbose output:
       pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
       pcc_get_offset: for CPU 0: pcc_cpu_data input_offset: 0x44, pcc_cpu_data output_offset: 0x48
       init: policy->max is 2800000, policy->min is 1200000
       get: get_freq for CPU 0
       get: SUCCESS: (virtual) output_offset for cpu 0 is 0xffffc9000d7c0048, contains a value of: 0xff06. Speed is: 168000 MHz
       cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor
       target: CPU 0 should go to target freq: 2800000 (virtual) input_offset is 0xffffc9000d7c0044
       target: was SUCCESSFUL for cpu 0
      I am asking to revert 790d849b to re-enable usage of ondemand
      governor with pcc-cpufreq.
      Fixes: 790d849b (cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency)
      CC: <stable@vger.kernel.org> # 4.5+
      Signed-off-by: default avatarAndreas Herrmann <aherrmann@suse.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  14. 08 Jun, 2016 2 commits
  15. 02 Jun, 2016 1 commit
  16. 18 Feb, 2016 1 commit
  17. 05 Jan, 2016 1 commit
  18. 09 Dec, 2015 1 commit
  19. 01 Sep, 2015 1 commit
  20. 04 Jun, 2015 1 commit
  21. 05 May, 2015 1 commit
  22. 30 Jan, 2015 2 commits
  23. 11 Nov, 2014 1 commit
    • Dirk Brandewie's avatar
      intel_pstate: Add support for HWP · 2f86dc4c
      Dirk Brandewie authored
      Add support of Hardware Managed Performance States (HWP) described in Volume 3
      section 14.4 of the SDM.
      With HWP enbaled intel_pstate will no longer be responsible for selecting P
      states for the processor. intel_pstate will continue to register to
      the cpufreq core as the scaling driver for CPUs implementing
      HWP. In HWP mode intel_pstate provides three functions reporting
      frequency to the cpufreq core, support for the set_policy() interface
      from the core and maintaining the intel_pstate sysfs interface in
      /sys/devices/system/cpu/intel_pstate.  User preferences expressed via
      the set_policy() interface or the sysfs interface are forwared to the
      CPU via the HWP MSR interface.
      Signed-off-by: default avatarDirk Brandewie <dirk.j.brandewie@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  24. 06 Jul, 2014 1 commit
  25. 05 Jun, 2014 1 commit
    • Viresh Kumar's avatar
      cpufreq: add support for intermediate (stable) frequencies · 1c03a2d0
      Viresh Kumar authored
      Douglas Anderson, recently pointed out an interesting problem due to which
      udelay() was expiring earlier than it should.
      While transitioning between frequencies few platforms may temporarily switch to
      a stable frequency, waiting for the main PLL to stabilize.
      For example: When we transition between very low frequencies on exynos, like
      between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz.
      No CPUFREQ notification is sent for that. That means there's a period of time
      when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz
      and 300MHz. And so udelay behaves badly.
      To get this fixed in a generic way, introduce another set of callbacks
      get_intermediate() and target_intermediate(), only for drivers with
      target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.
      get_intermediate() should return a stable intermediate frequency platform wants
      to switch to, and target_intermediate() should set CPU to that frequency,
      before jumping to the frequency corresponding to 'index'. Core will take care of
      sending notifications and driver doesn't have to handle them in
      target_intermediate() or target_index().
      NOTE: ->target_index() should restore to policy->restore_freq in case of
      failures as core would send notifications for that.
      Tested-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarDoug Anderson <dianders@chromium.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  26. 06 May, 2014 1 commit
  27. 30 Apr, 2014 1 commit
  28. 29 Apr, 2014 1 commit
  29. 20 Mar, 2014 1 commit
  30. 19 Mar, 2014 1 commit
  31. 17 Jan, 2014 1 commit
  32. 06 Jan, 2014 1 commit
  33. 25 Oct, 2013 1 commit
    • Viresh Kumar's avatar
      cpufreq: Implement light weight ->target_index() routine · 9c0ebcf7
      Viresh Kumar authored
      Currently, the prototype of cpufreq_drivers target routines is:
      int target(struct cpufreq_policy *policy, unsigned int target_freq,
      		unsigned int relation);
      And most of the drivers call cpufreq_frequency_table_target() to get a valid
      index of their frequency table which is closest to the target_freq. And they
      don't use target_freq and relation after that.
      So, it makes sense to just do this work in cpufreq core before calling
      cpufreq_frequency_table_target() and simply pass index instead. But this can be
      done only with drivers which expose their frequency table with cpufreq core. For
      others we need to stick with the old prototype of target() until those drivers
      are converted to expose frequency tables.
      This patch implements the new light weight prototype for target_index() routine.
      It looks like this:
      int target_index(struct cpufreq_policy *policy, unsigned int index);
      CPUFreq core will call cpufreq_frequency_table_target() before calling this
      routine and pass index to it. Because CPUFreq core now requires to call routines
      present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.
      This also marks target() interface as deprecated. So, that new drivers avoid
      using it. And Documentation is updated accordingly.
      It also converts existing .target() to newly defined light weight
      .target_index() routine for many driver.
      Acked-by: default avatarHans-Christian Egtvedt <egtvedt@samfundet.no>
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarRussell King <linux@arm.linux.org.uk>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Tested-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@rjwysocki.net>
  34. 10 Aug, 2013 1 commit
  35. 04 Jun, 2013 1 commit
  36. 10 Apr, 2013 1 commit