1. 23 Nov, 2015 1 commit
  2. 28 Oct, 2015 5 commits
  3. 14 Oct, 2015 1 commit
  4. 08 Oct, 2015 1 commit
  5. 16 Sep, 2015 1 commit
  6. 09 Sep, 2015 1 commit
  7. 07 Sep, 2015 2 commits
  8. 01 Sep, 2015 6 commits
  9. 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
  10. 06 Aug, 2015 1 commit
  11. 31 Jul, 2015 4 commits
  12. 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
  13. 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.
      
        cpufreq_cpu_get(cpu)
          /* Protects against concurrent driver removal */
          read_lock_irqsave(&cpufreq_driver_lock, flags);
          policy = per_cpu(cpufreq_cpu_data, cpu);
          kobject_get(&policy->kobj);
          read_unlock_irqrestore(&cpufreq_driver_lock, flags);
      
      The reference on the policy serializes versus module unload already:
      
        cpufreq_unregister_driver()
          subsys_interface_unregister()
            __cpufreq_remove_dev_finish()
              per_cpu(cpufreq_cpu_data) = NULL;
      	cpufreq_policy_put_kobj()
      
      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>
      454d3a25
  14. 20 Jul, 2015 1 commit
  15. 16 Jul, 2015 2 commits
  16. 09 Jul, 2015 2 commits
    • Viresh Kumar's avatar
      cpufreq: Allow freq_table to be obtained for offline CPUs · 5a31d594
      Viresh Kumar authored
      
      
      Users of freq table may want to access it for any CPU from
      policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
      list of 'clip_cpus' (equivalent to policy->related_cpus) during
      registration and tries to get freq_table for the first CPU of this mask.
      
      If the CPU, for which it tries to fetch freq_table, is offline,
      cpufreq_frequency_get_table() fails. This happens because it relies on
      cpufreq_cpu_get_raw() for its functioning which returns policy only for
      online CPUs.
      
      The fix is to access the policy data structure for the given CPU
      directly (which also returns a valid policy for offline CPUs), but the
      policy itself has to be active (meaning that at least one CPU using it
      is online) for the frequency table to be returned.
      
      Because we will be using 'cpufreq_cpu_data' now, which is internal to
      the cpufreq core, move cpufreq_frequency_get_table() to cpufreq.c.
      
      Reported-and-tested-by: default avatarPi-Cheng Chen <pi-cheng.chen@linaro.org>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5a31d594
    • Viresh Kumar's avatar
      cpufreq: Initialize the governor again while restoring policy · 35afd02e
      Viresh Kumar authored
      
      
      When all CPUs of a policy are hot-unplugged, we EXIT the governor but
      don't mark policy->governor as NULL. This was done in order to keep last
      used governor's information intact in sysfs, while the CPUs are offline.
      
      But we also need to clear policy->governor when restoring the policy.
      
      Because policy->governor still points to the last governor while policy
      is restored, following sequence of event happens:
       - cpufreq_init_policy() called while restoring policy
       - find_governor() matches last_governor string for present governors and
         returns last used governor's pointer, say ondemand. policy->governor
         already has the same address, unless the governor was removed in
         between.
       - cpufreq_set_policy() is called with both old/new policies governor set
         as ondemand.
       - Because governors matched, we skip governor initialization and return
         after calling __cpufreq_governor(CPUFREQ_GOV_LIMITS). Because the
         governor wasn't initialized for this policy, it returned -EBUSY.
       - cpufreq_init_policy() exits the policy on this error, but doesn't
         destroy it properly (should be fixed separately).
       - And so we enter a scenario where the policy isn't completely
         initialized but used.
      
      Fix this by setting policy->governor to NULL while restoring the policy.
      
      Reported-and-tested-by: default avatarPi-Cheng Chen <pi-cheng.chen@linaro.org>
      Reported-and-tested-by: default avatar"Jon Medhurst (Tixy)" <tixy@linaro.org>
      Reported-and-tested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Fixes: 18bf3a12
      
       (cpufreq: Mark policy->governor = NULL for inactive policies)
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      35afd02e
  17. 10 Jun, 2015 3 commits