1. 19 Jun, 2019 1 commit
  2. 25 Jul, 2017 1 commit
    • Viresh Kumar's avatar
      cpufreq: Add CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING cpufreq driver flag · fe829ed8
      Viresh Kumar authored
      The policy->transition_latency field is used for multiple purposes
      today and its not straight forward at all. This is how it is used:
      
      A. Set the correct transition_latency value.
      
      B. Set it to CPUFREQ_ETERNAL because:
         1. We don't want automatic dynamic switching (with
            ondemand/conservative) to happen at all.
         2. We don't know the transition latency.
      
      This patch handles the B.1. case in a more readable way. A new flag for
      the cpufreq drivers is added to disallow use of cpufreq governors which
      have dynamic_switching flag set.
      
      All the current cpufreq drivers which are setting transition_latency
      unconditionally to CPUFREQ_ETERNAL are updated to use it. They don't
      need to set transition_latency anymore.
      
      There shouldn't be any functional change after this patch.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fe829ed8
  3. 21 Apr, 2014 1 commit
  4. 07 Apr, 2014 1 commit
    • Chen Gang's avatar
      cpufreq: unicore32: fix typo issue for 'clk' · b4ddad95
      Chen Gang authored
      Need use 'clk' instead of 'mclk', which is the original removed local
      variable.
      
      The related original commit:
      
        "652ed95d cpufreq: introduce cpufreq_generic_get() routine"
      
      The related error with allmodconfig for unicore32:
      
          CC      drivers/cpufreq/unicore2-cpufreq.o
        drivers/cpufreq/unicore2-cpufreq.c: In function ‘ucv2_target’:
        drivers/cpufreq/unicore2-cpufreq.c:48: error: ‘struct cpufreq_policy’ has no member named ‘mclk’
        make[2]: *** [drivers/cpufreq/unicore2-cpufreq.o] Error 1
        make[1]: *** [drivers/cpufreq] Error 2
        make: *** [drivers] Error 2
      
      Fixes: 652ed95d (cpufreq: introduce cpufreq_generic_get() routine)
      Signed-off-by: default avatarChen Gang <gang.chen.5i5j@gmail.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b4ddad95
  5. 26 Mar, 2014 1 commit
  6. 17 Jan, 2014 1 commit
  7. 06 Jan, 2014 1 commit
    • Viresh Kumar's avatar
      cpufreq: send new set of notification for transition failures · ab1b1c4e
      Viresh Kumar authored
      In the current code, if we fail during a frequency transition, we
      simply send the POSTCHANGE notification with the old frequency. This
      isn't enough.
      
      One of the core users of these notifications is the code responsible
      for keeping loops_per_jiffy aligned with frequency changes. And mostly
      it is written as:
      
      	if ((val == CPUFREQ_PRECHANGE  && freq->old < freq->new) ||
      	    (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
      		update-loops-per-jiffy...
      	}
      
      So, suppose we are changing to a higher frequency and failed during
      transition, then following will happen:
      - CPUFREQ_PRECHANGE notification with freq-new > freq-old
      - CPUFREQ_POSTCHANGE notification with freq-new == freq-old
      
      The first one will update loops_per_jiffy and second one will do
      nothing. Even if we send the 2nd notification by exchanging values of
      freq-new and old, some users of these notifications might get
      unstable.
      
      This can be fixed by simply calling cpufreq_notify_post_transition()
      with error code and this routine will take care of sending
      notifications in the correct order.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      [rjw: Folded 3 patches into one, rebased unicore2 changes]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ab1b1c4e
  8. 15 Oct, 2013 2 commits
  9. 14 Aug, 2013 1 commit
  10. 10 Apr, 2013 1 commit
  11. 02 Apr, 2013 1 commit
  12. 17 Mar, 2011 1 commit