1. 22 Feb, 2016 1 commit
  2. 12 Feb, 2016 1 commit
  3. 05 Feb, 2016 1 commit
  4. 27 Jan, 2016 1 commit
  5. 01 Jan, 2016 2 commits
  6. 02 Dec, 2015 1 commit
  7. 23 Nov, 2015 1 commit
  8. 28 Oct, 2015 5 commits
  9. 14 Oct, 2015 1 commit
  10. 08 Oct, 2015 1 commit
  11. 16 Sep, 2015 1 commit
  12. 09 Sep, 2015 1 commit
  13. 07 Sep, 2015 2 commits
  14. 01 Sep, 2015 6 commits
  15. 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>
  16. 06 Aug, 2015 1 commit
  17. 31 Jul, 2015 4 commits
  18. 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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>
    • 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
      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
      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>
  19. 24 Jul, 2015 1 commit
    • Sebastian Andrzej Siewior's avatar
      cpufreq: Remove cpufreq_rwsem · 454d3a25
      Sebastian Andrzej Siewior authored
      cpufreq_rwsem was introduced in commit 6eed9404
       ("cpufreq: Use
      rwsem for protecting critical sections) in order to replace
      try_module_get() on the cpu-freq driver. That try_module_get() worked
      well until the refcount was so heavily used that module removal became
      more or less impossible.
      Though when looking at the various (undocumented) protection
      mechanisms in that code, the randomly sprinkeled around cpufreq_rwsem
      locking sites are superfluous.
      The policy, which is acquired in cpufreq_cpu_get() and released in
      cpufreq_cpu_put() is sufficiently protected already.
          /* Protects against concurrent driver removal */
          read_lock_irqsave(&cpufreq_driver_lock, flags);
          policy = per_cpu(cpufreq_cpu_data, cpu);
          read_unlock_irqrestore(&cpufreq_driver_lock, flags);
      The reference on the policy serializes versus module unload already:
              per_cpu(cpufreq_cpu_data) = NULL;
      If there is a reference held on the policy, i.e. obtained prior to the
      unregister call, then cpufreq_policy_put_kobj() will wait until that
      reference is dropped. So once subsys_interface_unregister() returns
      there is no policy pointer in flight and no new reference can be
      obtained. So that rwsem protection is useless.
      The other usage of cpufreq_rwsem in show()/store() of the sysfs
      interface is redundant as well because sysfs already does the proper
      kobject_get()/put() pairs.
      That leaves CPU hotplug versus module removal. The current
      down_write() around the write_lock() in cpufreq_unregister_driver() is
      silly at best as it protects actually nothing.
      The trivial solution to this is to prevent hotplug across
      cpufreq_unregister_driver completely.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  20. 20 Jul, 2015 1 commit