1. 21 Jul, 2016 1 commit
    • Steve Muckle's avatar
      cpufreq: add cpufreq_driver_resolve_freq() · e3c06236
      Steve Muckle authored
      Cpufreq governors may need to know what a particular target frequency
      maps to in the driver without necessarily wanting to set the frequency.
      Support this operation via a new cpufreq API,
      cpufreq_driver_resolve_freq(). This API returns the lowest driver
      frequency equal or greater than the target frequency
      (CPUFREQ_RELATION_L), subject to any policy (min/max) or driver
      limitations. The mapping is also cached in the policy so that a
      subsequent fast_switch operation can avoid repeating the same lookup.
      
      The API will call a new cpufreq driver callback, resolve_freq(), if it
      has been registered by the driver. Otherwise the frequency is resolved
      via cpufreq_frequency_table_target(). Rather than require ->target()
      style drivers to provide a resolve_freq() callback it is left to the
      caller to ensure that the driver implements this callback if necessary
      to use cpufreq_driver_resolve_freq().
      Suggested-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarSteve Muckle <smuckle@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e3c06236
  2. 06 Jul, 2016 1 commit
  3. 08 Jun, 2016 3 commits
  4. 02 Jun, 2016 4 commits
    • Rafael J. Wysocki's avatar
      cpufreq: stats: Make the stats code non-modular · 1aefc75b
      Rafael J. Wysocki authored
      The modularity of cpufreq_stats is quite problematic.
      
      First off, the usage of policy notifiers for the initialization
      and cleanup in the cpufreq_stats module is inherently racy with
      respect to CPU offline/online and the initialization and cleanup
      of the cpufreq driver.
      
      Second, fast frequency switching (used by the schedutil governor)
      cannot be enabled if any transition notifiers are registered, so
      if the cpufreq_stats module (that registers a transition notifier
      for updating transition statistics) is loaded, the schedutil governor
      cannot use fast frequency switching.
      
      On the other hand, allowing cpufreq_stats to be built as a module
      doesn't really add much value.  Arguably, there's not much reason
      for that code to be modular at all.
      
      For the above reasons, make the cpufreq stats code non-modular,
      modify the core to invoke functions provided by that code directly
      and drop the notifiers from it.
      
      Make the stats sysfs attributes appear empty if fast frequency
      switching is enabled as the statistics will not be updated in that
      case anyway (and returning -EBUSY from those attributes breaks
      powertop).
      
      While at it, clean up Kconfig help for the CPU_FREQ_STAT and
      CPU_FREQ_STAT_DETAILS options.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      1aefc75b
    • 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
    • Viresh Kumar's avatar
      cpufreq: governor: Create cpufreq_policy_apply_limits() · bf2be2de
      Viresh Kumar authored
      Create a new helper to avoid code duplication across governors.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      bf2be2de
    • 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
  5. 08 Apr, 2016 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: Call cpufreq_disable_fast_switch() in sugov_exit() · 6c9d9c81
      Rafael J. Wysocki authored
      Due to differences in the cpufreq core's handling of runtime CPU
      offline and nonboot CPUs disabling during system suspend-to-RAM,
      fast frequency switching gets disabled after a suspend-to-RAM and
      resume cycle on all of the nonboot CPUs.
      
      To prevent that from happening, move the invocation of
      cpufreq_disable_fast_switch() from cpufreq_exit_governor() to
      sugov_exit(), as the schedutil governor is the only user of fast
      frequency switching today anyway.
      
      That simply prevents cpufreq_disable_fast_switch() from being called
      without invoking the ->governor callback for the CPUFREQ_GOV_POLICY_EXIT
      event (which happens during system suspend now).
      
      Fixes: b7898fda (cpufreq: Support for fast frequency switching)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      6c9d9c81
  6. 01 Apr, 2016 3 commits
    • 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
    • Rafael J. Wysocki's avatar
      cpufreq: Move governor symbols to cpufreq.h · 379480d8
      Rafael J. Wysocki authored
      Move definitions of symbols related to transition latency and
      sampling rate to include/linux/cpufreq.h so they can be used by
      (future) goverernors located outside of drivers/cpufreq/.
      
      No functional changes.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      379480d8
    • Rafael J. Wysocki's avatar
      cpufreq: Move governor attribute set headers to cpufreq.h · 66893b6a
      Rafael J. Wysocki authored
      Move definitions and function headers related to struct gov_attr_set
      to include/linux/cpufreq.h so they can be used by (future) goverernors
      located outside of drivers/cpufreq/.
      
      No functional changes.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      66893b6a
  7. 10 Mar, 2016 1 commit
  8. 09 Mar, 2016 3 commits
    • Viresh Kumar's avatar
      cpufreq: Remove 'policy->governor_enabled' · 242aa883
      Viresh Kumar authored
      The entire sequence of events (like INIT/START or STOP/EXIT) for which
      cpufreq_governor() is called, is guaranteed to be protected by
      policy->rwsem now.
      
      The additional checks that were added earlier (as we were forced to drop
      policy->rwsem before calling cpufreq_governor() for EXIT event), aren't
      required anymore.
      
      Over that, they weren't sufficient really. They just take care of
      START/STOP events, but not INIT/EXIT and the state machine was never
      maintained properly by them.
      
      Kill the unnecessary checks and policy->governor_enabled field.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      242aa883
    • Viresh Kumar's avatar
      Revert "cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT" · 68e80dae
      Viresh Kumar authored
      Earlier, when the struct freq-attr was used to represent governor
      attributes, the standard cpufreq show/store sysfs attribute callbacks
      were applied to the governor tunable attributes and they always acquire
      the policy->rwsem lock before carrying out the operation.  That could
      have resulted in an ABBA deadlock if governor tunable attributes are
      removed under policy->rwsem while one of them is being accessed
      concurrently (if sysfs attributes removal wins the race, it will wait
      for the access to complete with policy->rwsem held while the attribute
      callback will block on policy->rwsem indefinitely).
      
      We attempted to address this issue by dropping policy->rwsem around
      governor tunable attributes removal (that is, around invocations of the
      ->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
      in cpufreq_set_policy(), but that opened up race conditions that had not
      been possible with policy->rwsem held all the time.
      
      The previous commit, "cpufreq: governor: New sysfs show/store callbacks
      for governor tunables", fixed the original ABBA deadlock by adding new
      governor specific show/store callbacks.
      
      We don't have to drop rwsem around invocations of governor event
      CPUFREQ_GOV_POLICY_EXIT anymore, and original fix can be reverted now.
      
      Fixes: 955ef483 (cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT)
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reported-by: default avatarJuri Lelli <juri.lelli@arm.com>
      Tested-by: default avatarJuri Lelli <juri.lelli@arm.com>
      Tested-by: default avatarShilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      68e80dae
    • Rafael J. Wysocki's avatar
      cpufreq: Add mechanism for registering utilization update callbacks · 34e2c555
      Rafael J. Wysocki authored
      Introduce a mechanism by which parts of the cpufreq subsystem
      ("setpolicy" drivers or the core) can register callbacks to be
      executed from cpufreq_update_util() which is invoked by the
      scheduler's update_load_avg() on CPU utilization changes.
      
      This allows the "setpolicy" drivers to dispense with their timers
      and do all of the computations they need and frequency/voltage
      adjustments in the update_load_avg() code path, among other things.
      
      The update_load_avg() changes were suggested by Peter Zijlstra.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      34e2c555
  9. 26 Feb, 2016 1 commit
  10. 04 Feb, 2016 1 commit
  11. 31 Dec, 2015 2 commits
  12. 02 Dec, 2015 1 commit
  13. 28 Oct, 2015 3 commits
  14. 15 Sep, 2015 1 commit
  15. 01 Sep, 2015 4 commits
  16. 07 Aug, 2015 1 commit
  17. 06 Aug, 2015 1 commit
    • Viresh Kumar's avatar
      cpufreq: Allow drivers to enable boost support after registering driver · 44139ed4
      Viresh Kumar authored
      In some cases it wouldn't be known at time of driver registration, if
      the driver needs to support boost frequencies.
      
      For example, while getting boost information from DT with opp-v2
      bindings, we need to parse the bindings for all the CPUs to know if
      turbo/boost OPPs are supported or not.
      
      One way out to do that efficiently is to delay supporting boost mode
      (i.e. creating /sys/devices/system/cpu/cpufreq/boost file), until the
      time OPP bindings are parsed.
      
      At that point, the driver can enable boost support. This can be done at
      ->init(), where the frequency table is created.
      
      To do that, the driver requires few APIs from cpufreq core that let him
      do this. This patch provides these APIs.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      44139ed4
  18. 28 Jul, 2015 1 commit
    • Rafael J. Wysocki's avatar
      cpufreq: Avoid attempts to create duplicate symbolic links · 559ed407
      Rafael J. Wysocki authored
      After commit 87549141 (cpufreq: Stop migrating sysfs files on
      hotplug) there is a problem with CPUs that share cpufreq policy
      objects with other CPUs and are initially offline.
      
      Say CPU1 shares a policy with CPU0 which is online and is registered
      first.  As part of the registration process, cpufreq_add_dev() is
      called for it.  It creates the policy object and a symbolic link
      to it from the CPU1's sysfs directory.  If CPU1 is registered
      subsequently and it is offline at that time, cpufreq_add_dev() will
      attempt to create a symbolic link to the policy object for it, but
      that link is present already, so a warning about that will be
      triggered.
      
      To avoid that warning, make cpufreq use an additional CPU mask
      containing related CPUs that are actually present for each policy
      object.  That mask is initialized when the policy object is populated
      after its creation (for the first online CPU using it) and it includes
      CPUs from the "policy CPUs" mask returned by the cpufreq driver's
      ->init() callback that are physically present at that time.  Symbolic
      links to the policy are created only for the CPUs in that mask.
      
      If cpufreq_add_dev() is invoked for an offline CPU, it checks the
      new mask and only creates the symlink if the CPU was not in it (the
      CPU is added to the mask at the same time).
      
      In turn, cpufreq_remove_dev() drops the given CPU from the new mask,
      removes its symlink to the policy object and returns, unless it is
      the CPU owning the policy object.  In that case, the policy object
      is moved to a new CPU's sysfs directory or deleted if the CPU being
      removed was the last user of the policy.
      
      While at it, notice that cpufreq_remove_dev() can't fail, because
      its return value is ignored, so make it ignore return values from
      __cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
      and prevent these functions from aborting on errors returned by
      __cpufreq_governor().  Also drop the now unused sif argument from
      them.
      
      Fixes: 87549141 (cpufreq: Stop migrating sysfs files on hotplug)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reported-and-tested-by: default avatarRussell King <linux@arm.linux.org.uk>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      559ed407
  19. 22 May, 2015 1 commit
  20. 14 May, 2015 1 commit
    • Viresh Kumar's avatar
      cpufreq: Manage governor usage history with 'policy->last_governor' · 4573237b
      Viresh Kumar authored
      History of which governor was used last is common to all CPUs within a
      policy and maintaining it per-cpu isn't the best approach for sure.
      
      Apart from wasting memory, this also increases the complexity of
      managing this data structure as it has to be updated for all CPUs.
      
      To make that somewhat simpler, lets store this information in a new
      field 'last_governor' in struct cpufreq_policy and update it on removal
      of last cpu of a policy.
      
      As a side-effect it also solves an old problem, consider a system with
      two clusters 0 & 1. And there is one policy per cluster.
      
      Cluster 0: CPU0 and 1.
      Cluster 1: CPU2 and 3.
      
       - CPU2 is first brought online, and governor is set to performance
         (default as cpufreq_cpu_governor wasn't set).
       - Governor is changed to ondemand.
       - CPU2 is taken offline and cpufreq_cpu_governor is updated for CPU2.
       - CPU3 is brought online.
       - Because cpufreq_cpu_governor wasn't set for CPU3, the default governor
         performance is picked for CPU3.
      
      This patch fixes the bug as we now have a single variable to update for
      policy.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4573237b
  21. 23 Jan, 2015 3 commits
  22. 29 Nov, 2014 2 commits