1. 21 Jul, 2016 2 commits
    • Viresh Kumar's avatar
      cpufreq: Disallow ->resolve_freq() for drivers providing ->target_index() · abe8bd02
      Viresh Kumar authored
      The handlers provided by cpufreq core are sufficient for resolving the
      frequency for drivers providing ->target_index(), as the core already
      has the frequency table and so ->resolve_freq() isn't required for such
      platforms.
      
      This patch disallows drivers with ->target_index() callback to use the
      ->resolve_freq() callback.
      
      Also, it fixes a potential kernel crash for drivers providing ->target()
      but no ->resolve_freq().
      
      Fixes: e3c06236
      
       "cpufreq: add cpufreq_driver_resolve_freq()"
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      abe8bd02
    • 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. 04 Jul, 2016 1 commit
  3. 28 Jun, 2016 1 commit
  4. 08 Jun, 2016 4 commits
  5. 02 Jun, 2016 5 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
    • Viresh Kumar's avatar
      cpufreq: Use clamp_val() in __cpufreq_driver_target() · 910c6e88
      Viresh Kumar authored
      
      
      Use clamp_val() instead of open coding it.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      910c6e88
    • 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
  6. 01 Jun, 2016 1 commit
  7. 30 May, 2016 3 commits
  8. 18 May, 2016 3 commits
  9. 02 May, 2016 1 commit
  10. 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
  11. 08 Apr, 2016 3 commits
  12. 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
  13. 22 Mar, 2016 3 commits
  14. 18 Mar, 2016 1 commit
  15. 10 Mar, 2016 1 commit
  16. 09 Mar, 2016 9 commits
    • Viresh Kumar's avatar
      Revert "cpufreq: postfix policy directory with the first CPU in related_cpus" · edd4a893
      Viresh Kumar authored
      Revert commit 3510fac4 (cpufreq: postfix policy directory with the
      first CPU in related_cpus).
      
      Earlier, the policy->kobj was added to the kobject core, before ->init()
      callback was called for the cpufreq drivers. Which allowed those drivers
      to add or remove, driver dependent, sysfs files/directories to the same
      kobj from their ->init() and ->exit() callbacks.
      
      That isn't possible anymore after commit 3510fac4
      
      .
      
      Now, there is no other clean alternative that people can adopt.
      
      Its better to revert the earlier commit to allow cpufreq drivers to
      create/remove sysfs files from ->init() and ->exit() callbacks.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      edd4a893
    • Rafael J. Wysocki's avatar
      cpufreq: Reduce cpufreq_update_util() overhead a bit · 08f511fd
      Rafael J. Wysocki authored
      
      
      Use the observation that cpufreq_update_util() is only called
      by the scheduler with rq->lock held, so the callers of
      cpufreq_set_update_util_data() can use synchronize_sched()
      instead of synchronize_rcu() to wait for cpufreq_update_util()
      to complete.  Moreover, if they are updated to do that,
      rcu_read_(un)lock() calls in cpufreq_update_util() might be
      replaced with rcu_read_(un)lock_sched(), respectively, but
      those aren't really necessary, because the scheduler calls
      that function from RCU-sched read-side critical sections
      already.
      
      In addition to that, if cpufreq_set_update_util_data() checks
      the func field in the struct update_util_data before setting
      the per-CPU pointer to it, the data->func check may be dropped
      from cpufreq_update_util() as well.
      
      Make the above changes to reduce the overhead from
      cpufreq_update_util() in the scheduler paths invoking it
      and to make the cleanup after removing its callbacks less
      heavy-weight somewhat.
      
      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>
      08f511fd
    • 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
      cpufreq: Rename __cpufreq_governor() to cpufreq_governor() · a1317e09
      Viresh Kumar authored
      
      
      The __ at the beginning of the routine aren't really necessary at all.
      Rename it to cpufreq_governor() instead.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a1317e09
    • Viresh Kumar's avatar
      cpufreq: Relocate handle_update() to kill its declaration · 11eb69b9
      Viresh Kumar authored
      
      
      handle_update() is declared at the top of the file as its user appear
      before its definition. Relocate the routine to get rid of this.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      11eb69b9
    • Viresh Kumar's avatar
      cpufreq: Remove cpufreq_governor_lock · 99522fe6
      Viresh Kumar authored
      
      
      We used to drop policy->rwsem just before calling __cpufreq_governor()
      in some cases earlier and so it was possible that __cpufreq_governor()
      ran concurrently via separate threads for the same policy.
      
      In order to guarantee valid state transitions for governors,
      'governor_enabled' was required to be protected using some locking
      and cpufreq_governor_lock was added for that.
      
      But now __cpufreq_governor() is always called under policy->rwsem,
      and 'governor_enabled' is protected against races even without
      cpufreq_governor_lock.
      
      Get rid of the extra lock now.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Tested-by: default avatarJuri Lelli <juri.lelli@arm.com>
      Tested-by: default avatarShilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
      [ rjw : Changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      99522fe6
    • Viresh Kumar's avatar
      cpufreq: Call __cpufreq_governor() with policy->rwsem held · 49f18560
      Viresh Kumar authored
      
      
      The cpufreq core code is not consistent with respect to invoking
      __cpufreq_governor() under policy->rwsem.
      
      Changing all code to always hold policy->rwsem around
      __cpufreq_governor() invocations will allow us to remove
      cpufreq_governor_lock that is used today because we can't
      guarantee that __cpufreq_governor() isn't executed twice in
      parallel for the same policy.
      
      We should also ensure that policy->rwsem is held across governor
      state changes.
      
      For example, while adding a CPU to the policy in the CPU online path,
      we need to stop the governor, change policy->cpus, start the governor
      and then refresh its limits. The complete sequence must be guaranteed
      to complete without interruptions by concurrent governor state
      updates.  That can be achieved by holding policy->rwsem around those
      sequences of operations.
      
      Also note that after this patch cpufreq_driver->stop_cpu() and
      ->exit() will get called under policy->rwsem which wasn't the case
      earlier. That shouldn't have any side effects, though.
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Tested-by: default avatarJuri Lelli <juri.lelli@arm.com>
      Tested-by: default avatarShilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
      [ rjw: Changelog ]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      49f18560
    • Viresh Kumar's avatar
      cpufreq: Merge cpufreq_offline_prepare/finish routines · 69cee714
      Viresh Kumar authored
      Commit 1aee40ac
      
       (cpufreq: Invoke __cpufreq_remove_dev_finish()
      after releasing cpu_hotplug.lock) split the cpufreq's CPU offline
      routine in two pieces, one of them to be run with CPU offline/online
      locked and the other to be called later.  The reason for that split
      was a possible deadlock scenario involving cpufreq sysfs attributes
      and CPU offline.
      
      However, the handling of CPU offline in cpufreq has changed since
      then.  Policy sysfs attributes are never removed during CPU offline,
      so there's no need to worry about accessing them during CPU offline,
      because that can't lead to any deadlocks now.  Governor sysfs
      attributes are still removed in __cpufreq_governor(_EXIT), but
      there is a new kobject type for them now and its show/store
      callbacks don't lock CPU offline/online (they don't need to do
      that).
      
      This means that the CPU offline code in cpufreq doesn't need to
      be split any more, so combine cpufreq_offline_prepare() with
      cpufreq_offline_finish().
      
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      [ rjw: Changelog ]
      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>
      69cee714
    • 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