1. 16 Sep, 2019 2 commits
  2. 10 Aug, 2019 1 commit
  3. 23 Jul, 2019 1 commit
  4. 16 Jul, 2019 1 commit
  5. 08 Jul, 2019 4 commits
  6. 28 Jun, 2019 3 commits
    • Viresh Kumar's avatar
      cpufreq: Avoid calling cpufreq_verify_current_freq() from handle_update() · 70a59fde
      Viresh Kumar authored
      On some occasions cpufreq_verify_current_freq() schedules a work whose
      callback is handle_update(), which further calls cpufreq_update_policy()
      which may end up calling cpufreq_verify_current_freq() again.
      
      On the other hand, when cpufreq_update_policy() is called from
      handle_update(), the pointer to the cpufreq policy is already
      available, but cpufreq_cpu_acquire() is still called to get it in
      cpufreq_update_policy(), which should be avoided as well.
      
      To fix these issues, create a new helper, refresh_frequency_limits(),
      and make both handle_update() call it cpufreq_update_policy().
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      [ rjw: Rename reeval_frequency_limits() as refresh_frequency_limits() ]
      [ rjw: Changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      70a59fde
    • Viresh Kumar's avatar
      cpufreq: Consolidate cpufreq_update_current_freq() and __cpufreq_get() · 5980752e
      Viresh Kumar authored
      Their implementations are quite similar, so modify
      cpufreq_update_current_freq() somewhat and call it from
      __cpufreq_get().
      
      Also rename cpufreq_update_current_freq() to
      cpufreq_verify_current_freq(), as that's what it is doing.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      [ rjw: Subject & changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5980752e
    • Viresh Kumar's avatar
      cpufreq: Don't skip frequency validation for has_target() drivers · 98015228
      Viresh Kumar authored
      CPUFREQ_CONST_LOOPS was introduced in a very old commit from pre-2.6
      kernel release by commit 6a4a93f9c0d5 ("[CPUFREQ] Fix 'out of sync'
      issue").
      
      Basically, that commit does two things:
      
       - It adds the frequency verification code (which is quite similar to
         what we have today as well).
      
       - And it sets the CPUFREQ_CONST_LOOPS flag only for setpolicy drivers,
         rightly so based on the code we had then. The idea was to avoid
         frequency validation for setpolicy drivers as the cpufreq core doesn't
         know what frequency the hardware is running at and so no point in
         doing frequency verification.
      
      The problem happened when we started to use the same CPUFREQ_CONST_LOOPS
      flag for constant loops-per-jiffy thing as well and many has_target()
      drivers started using the same flag and unknowingly skipped the
      verification of frequency. There is no logical reason behind skipping
      frequency validation because of the presence of CPUFREQ_CONST_LOOPS
      flag otherwise.
      
      Fix this issue by skipping frequency validation only for setpolicy
      drivers and always doing it for has_target() drivers irrespective of
      the presence or absence of CPUFREQ_CONST_LOOPS flag.
      
      cpufreq_notify_transition() is only called for has_target() type driver
      and not for set_policy type, and the check is simply redundant. Remove
      it as well.
      
      Also remove () around freq comparison statement as they aren't required
      and checkpatch also warns for them.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      98015228
  7. 26 Jun, 2019 3 commits
  8. 24 Jun, 2019 1 commit
  9. 19 Jun, 2019 2 commits
  10. 17 Jun, 2019 1 commit
  11. 13 Jun, 2019 1 commit
  12. 06 Jun, 2019 2 commits
  13. 05 Jun, 2019 5 commits
  14. 04 Jun, 2019 2 commits
  15. 03 Jun, 2019 2 commits
  16. 30 May, 2019 5 commits
  17. 24 May, 2019 1 commit
  18. 21 May, 2019 2 commits
  19. 20 May, 2019 1 commit