1. 05 5月, 2016 1 次提交
    • S
      cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table · d9975b0b
      Sudeep Holla 提交于
      Currently when performing random CPU hot-plugs and suspend-to-ram(S2R)
      on systems using arm_big_little cpufreq driver, we get warnings similar
      to something like below:
      
      cpu cpu1: _opp_add: duplicate OPPs detected. Existing: freq: 600000000,
      	volt: 800000, enabled: 1. New: freq: 600000000, volt: 800000, enabled: 1
      
      This is mainly because the OPPs for the shared cpus are not set. We can
      just use dev_pm_opp_of_cpumask_add_table in case the OPPs are obtained
      from DT(arm_big_little_dt.c) or use dev_pm_opp_set_sharing_cpus if the
      OPPs are obtained by other means like firmware(e.g. scpi-cpufreq.c)
      
      Also now that the generic dev_pm_opp{,_of}_cpumask_remove_table can
      handle removal of opp table and entries for all associated CPUs, we can
      re-use dev_pm_opp{,_of}_cpumask_remove_table as free_opp_table in
      cpufreq_arm_bL_ops.
      
      This patch makes necessary changes to reuse the generic OPP functions for
      {init,free}_opp_table and thereby eliminating the warnings.
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d9975b0b
  2. 10 12月, 2015 1 次提交
  3. 02 11月, 2015 1 次提交
  4. 15 5月, 2015 1 次提交
  5. 05 5月, 2015 2 次提交
  6. 02 12月, 2014 1 次提交
  7. 09 8月, 2014 1 次提交
  8. 30 4月, 2014 1 次提交
  9. 19 3月, 2014 1 次提交
    • V
      cpufreq: arm_big_little: set 'physical_cluster' for each CPU · 8f3ba3d3
      viresh kumar 提交于
      We have a per-CPU variable for managing which cluster a CPU belongs to.
      Currently, physical_cluster is set for policy->cpu only which leads to
      the following on some SoC's:
      
       - There are two clusters:
         - Cluster 0 has four ARM Cortex A7 CPUs (slower ones): 0,1,2,3
         - Cluster 1 has four ARM Cortex A15 CPUs (faster ones): 4,5,6,7
       - CPUs are booted in order 0,1..7 and so initially policy->cpu for A7 cluster
         would be 0 and for A15 cluster would be 4.
       - Now CPU4 (i.e. A15_0) is hotplugged out and so policy->cpu for A15 cluster
         becomes 5 (i.e. A15_1).
       - But physical cluster is only set for CPU0 and CPU4 in ARM big LITTLE driver
         and isn't updated.
       - Now freq change request comes for A15 cluster and we would try to update freq
         of physical_cluster of CPU5, i.e. A15_1. And it is currently set to zero
         (default value of uninitialized global variables).
       - And so we actually try to change freq of A7 cluster instead of A15.
       - This also results in kernel crash as sometimes we might request freq above
         A7's limit and CPU may behave badly..
      
      Fix this by initializing physical_cluster for all CPUs of a policy.
      
      Based on previous work by Xin Wang.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8f3ba3d3
  10. 12 3月, 2014 1 次提交
  11. 06 1月, 2014 1 次提交
    • V
      cpufreq: Mark ARM drivers with CPUFREQ_NEED_INITIAL_FREQ_CHECK flag · ae6b4271
      Viresh Kumar 提交于
      Sometimes boot loaders set CPU frequency to a value outside of frequency table
      present with cpufreq core. In such cases CPU might be unstable if it has to run
      on that frequency for long duration of time and so its better to set it to a
      frequency which is specified in frequency table.
      
      On some systems we can't really say what frequency we're running at the moment
      and so for these we shouldn't check if we are running at a frequency present in
      frequency table. And so we really can't force this for all the cpufreq drivers.
      
      Hence we are created another flag here: CPUFREQ_NEED_INITIAL_FREQ_CHECK that
      will be marked by platforms which want to go for this check at boot time.
      
      Initially this is done for all ARM platforms but others may follow if required.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ae6b4271
  12. 31 10月, 2013 3 次提交
  13. 26 10月, 2013 3 次提交
  14. 17 10月, 2013 1 次提交
  15. 16 10月, 2013 3 次提交
  16. 01 10月, 2013 2 次提交
  17. 24 6月, 2013 1 次提交
    • V
      cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error cases · 3d69dd50
      Viresh Kumar 提交于
      PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
      should be called or both shouldn't be.
      
      In case we have started PRECHANGE notifier and found an error, we must call
      POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
      calling notifiers is complete.
      
      This patch fixes it.
      
      This also removes code setting policy->cur as this is also done by POSTCHANGE
      notifier.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      3d69dd50
  18. 12 5月, 2013 2 次提交
  19. 22 4月, 2013 1 次提交
  20. 02 4月, 2013 1 次提交