1. 09 Mar, 2016 4 commits
    • 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 7 commits
    • Rafael J. Wysocki's avatar
      cpufreq: Pass CPU number to cpufreq_policy_alloc() · a34e63b1
      Rafael J. Wysocki authored
      
      
      Change cpufreq_policy_alloc() to take a CPU number instead of a CPU
      device pointer as its argument, as it is the only function called by
      cpufreq_add_dev() taking a device pointer argument at this point.
      
      That will allow us to split the CPU online part from cpufreq_add_dev()
      more cleanly going forward.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      a34e63b1
    • Rafael J. Wysocki's avatar
      cpufreq: Do not update related_cpus on every policy activation · 4d1f3a5b
      Rafael J. Wysocki authored
      
      
      The related_cpus mask includes CPUs whose cpufreq_cpu_data per-CPU
      pointers have been set the the given policy.  Since those pointers
      are only set at the policy creation time and unset when the policy
      is deleted, the related_cpus should not be updated between those
      two operations.
      
      For this reason, avoid updating it whenever the first of the
      "related" CPUs goes online.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      4d1f3a5b
    • Rafael J. Wysocki's avatar
      cpufreq: Drop unused dev argument from two functions · d9612a49
      Rafael J. Wysocki authored
      
      
      The dev argument of cpufreq_add_policy_cpu() and
      cpufreq_add_dev_interface() is not used by any of them,
      so drop it.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      d9612a49
    • Rafael J. Wysocki's avatar
      cpufreq: Drop unnecessary label from cpufreq_add_dev() · d4d854d6
      Rafael J. Wysocki authored
      
      
      The leftover out_release_rwsem label in cpufreq_add_dev() is not
      necessary any more and confusing, so drop it.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      d4d854d6
    • Rafael J. Wysocki's avatar
      cpufreq: Drop cpufreq_policy_restore() · 11ce707e
      Rafael J. Wysocki authored
      
      
      Notice that when cpufreq_policy_restore() is called, its per-CPU
      cpufreq_cpu_data variable has been already dereferenced and if that
      variable is not NULL, the policy local pointer in cpufreq_add_dev()
      contains its value.
      
      Therefore it is not necessary to dereference it again and the
      policy pointer can be used directly.  Moreover, if that pointer
      is not NULL, the policy is inactive (or the previous check would
      have made us return from cpufreq_add_dev()) so the restoration
      code from cpufreq_policy_restore() can be moved to that point
      in cpufreq_add_dev().
      
      Do that and drop cpufreq_policy_restore().
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      11ce707e
    • Rafael J. Wysocki's avatar
      cpufreq: Rework two functions related to CPU offline · 15c0b4d2
      Rafael J. Wysocki authored
      
      
      Since __cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
      are about CPU offline rather than about CPU removal, rename them to
      cpufreq_offline_prepare() and cpufreq_offline_finish(), respectively.
      
      Also change their argument from a struct device pointer to a CPU
      number, because they use the CPU number only internally anyway
      and make them void as their return values are ignored.
      
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      15c0b4d2
    • 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