releases/4.7.1/revert-cpufreq-pcc-cpufreq-update-default-value-of-cpuinfo_transition_latency.patch

   1 From da7d3abe1c9e5ebac2cf86f97e9e89888a5e2094 Mon Sep 17 00:00:00 2001
   2 From: Andreas Herrmann <aherrmann@suse.com>
   3 Date: Fri, 22 Jul 2016 17:14:11 +0200
   4 Subject: Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency"
   5
   6 From: Andreas Herrmann <aherrmann@suse.com>
   7
   8 commit da7d3abe1c9e5ebac2cf86f97e9e89888a5e2094 upstream.
   9
  10 This reverts commit 790d849bf811a8ab5d4cd2cce0f6fda92f6aebf2.
  11
  12 Using a v4.7-rc7 kernel on a HP ProLiant triggered following messages
  13
  14  pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
  15  cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor
  16
  17 The last line was shown for each CPU in the system.
  18 Testing v4.5 (where commit 790d849b was integrated) triggered
  19 similar messages. Same behaviour on a 2nd HP Proliant system.
  20
  21 So commit 790d849bf (cpufreq: pcc-cpufreq: update default value of
  22 cpuinfo_transition_latency) causes the system to use performance
  23 governor which, I guess, was not the intention of the patch.
  24
  25 Enabling debug output in pcc-cpufreq provides following verbose output:
  26
  27  pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
  28  pcc_get_offset: for CPU 0: pcc_cpu_data input_offset: 0x44, pcc_cpu_data output_offset: 0x48
  29  init: policy->max is 2800000, policy->min is 1200000
  30  get: get_freq for CPU 0
  31  get: SUCCESS: (virtual) output_offset for cpu 0 is 0xffffc9000d7c0048, contains a value of: 0xff06. Speed is: 168000 MHz
  32  cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor
  33  target: CPU 0 should go to target freq: 2800000 (virtual) input_offset is 0xffffc9000d7c0044
  34  target: was SUCCESSFUL for cpu 0
  35
  36 I am asking to revert 790d849bf to re-enable usage of ondemand
  37 governor with pcc-cpufreq.
  38
  39 Fixes: 790d849bf (cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency)
  40 Signed-off-by: Andreas Herrmann <aherrmann@suse.com>
  41 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
  42 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  43
  44 ---
  45  Documentation/cpu-freq/pcc-cpufreq.txt |    4 ++--
  46  drivers/cpufreq/pcc-cpufreq.c          |    2 --
  47  2 files changed, 2 insertions(+), 4 deletions(-)
  48
  49 --- a/Documentation/cpu-freq/pcc-cpufreq.txt
  50 +++ b/Documentation/cpu-freq/pcc-cpufreq.txt
  51 @@ -159,8 +159,8 @@ to be strictly associated with a P-state
  52
  53  2.2 cpuinfo_transition_latency:
  54  -------------------------------
  55 -The cpuinfo_transition_latency field is CPUFREQ_ETERNAL. The PCC specification
  56 -does not include a field to expose this value currently.
  57 +The cpuinfo_transition_latency field is 0. The PCC specification does
  58 +not include a field to expose this value currently.
  59
  60  2.3 cpuinfo_cur_freq:
  61  ---------------------
  62 --- a/drivers/cpufreq/pcc-cpufreq.c
  63 +++ b/drivers/cpufreq/pcc-cpufreq.c
  64 @@ -555,8 +555,6 @@ static int pcc_cpufreq_cpu_init(struct c
  65         policy->min = policy->cpuinfo.min_freq =
  66                 ioread32(&pcch_hdr->minimum_frequency) * 1000;
  67
  68 -       policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
  69 -
  70         pr_debug("init: policy->max is %d, policy->min is %d\n",
  71                 policy->max, policy->min);
  72  out: