1. 09 Mar, 2016 5 commits
    • 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
    • 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
  2. 05 Feb, 2016 1 commit
  3. 27 Jan, 2016 1 commit
  4. 01 Jan, 2016 2 commits
  5. 02 Dec, 2015 1 commit
  6. 23 Nov, 2015 1 commit
  7. 28 Oct, 2015 5 commits
  8. 14 Oct, 2015 1 commit
  9. 08 Oct, 2015 1 commit
  10. 16 Sep, 2015 1 commit
  11. 09 Sep, 2015 1 commit
  12. 07 Sep, 2015 2 commits
  13. 01 Sep, 2015 6 commits
  14. 07 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
  15. 06 Aug, 2015 1 commit
  16. 31 Jul, 2015 4 commits
  17. 28 Jul, 2015 6 commits