1. 02 Jun, 2016 3 commits
    • Viresh Kumar's avatar
      cpufreq: Send START policy notification after sending CREATE · 388612ba
      Viresh Kumar authored
      
      
      The sequence got a bit wrong as we are sending CPUFREQ_START
      notifications even before we have sent CPUFREQ_CREATE_POLICY.
      
      Fix it.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      388612ba
    • Rafael J. Wysocki's avatar
      cpufreq: Drop the 'initialized' field from struct cpufreq_governor · 9a15fb2c
      Rafael J. Wysocki authored
      
      
      The 'initialized' field in struct cpufreq_governor is only used by
      the conservative governor (as a usage counter) and the way that
      happens is far from straightforward and arguably incorrect.
      
      Namely, the value of 'initialized' is checked by
      cpufreq_dbs_governor_init() and cpufreq_dbs_governor_exit() and
      the results of those checks are passed (as the second argument) to
      the ->init() and ->exit() callbacks in struct dbs_governor.  Those
      callbacks are only implemented by the ondemand and conservative
      governors and ondemand doesn't use their second argument at all.
      In turn, the conservative governor uses it to decide whether or not
      to either register or unregister a transition notifier.
      
      That whole mechanism is not only unnecessarily convoluted, but also
      racy, because the 'initialized' field of struct cpufreq_governor is
      updated in cpufreq_init_governor() and cpufreq_exit_governor() under
      policy->rwsem which doesn't help if one of these functions is run
      twice in parallel for different policies (which isn't impossible in
      principle), for example.
      
      Instead of it, add a proper usage counter to the conservative
      governor and update it from cs_init() and cs_exit() which is
      guaranteed to be non-racy, as those functions are only called
      under gov_dbs_data_mutex which is global.
      
      With that in place, drop the 'initialized' field from struct
      cpufreq_governor as it is not used any more.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      9a15fb2c
    • Rafael J. Wysocki's avatar
      cpufreq: governor: Get rid of governor events · e788892b
      Rafael J. Wysocki authored
      
      
      The design of the cpufreq governor API is not very straightforward,
      as struct cpufreq_governor provides only one callback to be invoked
      from different code paths for different purposes.  The purpose it is
      invoked for is determined by its second "event" argument, causing it
      to act as a "callback multiplexer" of sorts.
      
      Unfortunately, that leads to extra complexity in governors, some of
      which implement the ->governor() callback as a switch statement
      that simply checks the event argument and invokes a separate function
      to handle that specific event.
      
      That extra complexity can be eliminated by replacing the all-purpose
      ->governor() callback with a family of callbacks to carry out specific
      governor operations: initialization and exit, start and stop and policy
      limits updates.  That also turns out to reduce the code size too, so
      do it.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      e788892b
  2. 30 May, 2016 3 commits
  3. 18 May, 2016 3 commits
  4. 02 May, 2016 1 commit
  5. 18 Apr, 2016 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: Abort cpufreq_update_current_freq() for cpufreq_suspended set · c9d9c929
      Rafael J. Wysocki authored
      Since governor operations are generally skipped if cpufreq_suspended
      is set, cpufreq_start_governor() should do nothing in that case.
      
      That function is called in the cpufreq_online() path, and may also
      be called from cpufreq_offline() in some cases, which are invoked
      by the nonboot CPUs disabing/enabling code during system suspend
      to RAM and resume.  That happens when all devices have been
      suspended, so if the cpufreq driver relies on things like I2C to
      get the current frequency, it may not be ready to do that then.
      
      To prevent problems from happening for this reason, make
      cpufreq_update_current_freq(), which is the only function invoked
      by cpufreq_start_governor() that doesn't check cpufreq_suspended
      already, return 0 upfront if cpufreq_suspended is set.
      
      Fixes: 3bbf8fe3
      
       (cpufreq: Always update current frequency before startig governor)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      c9d9c929
  6. 08 Apr, 2016 3 commits
  7. 01 Apr, 2016 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: Support for fast frequency switching · b7898fda
      Rafael J. Wysocki authored
      
      
      Modify the ACPI cpufreq driver to provide a method for switching
      CPU frequencies from interrupt context and update the cpufreq core
      to support that method if available.
      
      Introduce a new cpufreq driver callback, ->fast_switch, to be
      invoked for frequency switching from interrupt context by (future)
      governors supporting that feature via (new) helper function
      cpufreq_driver_fast_switch().
      
      Add two new policy flags, fast_switch_possible, to be set by the
      cpufreq driver if fast frequency switching can be used for the
      given policy and fast_switch_enabled, to be set by the governor
      if it is going to use fast frequency switching for the given
      policy.  Also add a helper for setting the latter.
      
      Since fast frequency switching is inherently incompatible with
      cpufreq transition notifiers, make it possible to set the
      fast_switch_enabled only if there are no transition notifiers
      already registered and make the registration of new transition
      notifiers fail if fast_switch_enabled is set for at least one
      policy.
      
      Implement the ->fast_switch callback in the ACPI cpufreq driver
      and make it set fast_switch_possible during policy initialization
      as appropriate.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      b7898fda
  8. 22 Mar, 2016 3 commits
  9. 18 Mar, 2016 1 commit
  10. 10 Mar, 2016 1 commit
  11. 09 Mar, 2016 10 commits
  12. 26 Feb, 2016 1 commit
  13. 22 Feb, 2016 2 commits
  14. 12 Feb, 2016 1 commit
  15. 05 Feb, 2016 1 commit
  16. 27 Jan, 2016 1 commit
  17. 01 Jan, 2016 2 commits
  18. 02 Dec, 2015 1 commit
  19. 23 Nov, 2015 1 commit