1. 05 11月, 2018 3 次提交
  2. 04 10月, 2018 1 次提交
  3. 01 10月, 2018 1 次提交
    • V
      OPP: Prevent creating multiple OPP tables for devices sharing OPP nodes · 283d55e6
      Viresh Kumar 提交于
      When two or more devices are sharing their clock and voltage rails, they
      share the same OPP table. But there are some corner cases where the OPP
      core incorrectly creates separate OPP tables for them.
      
      For example, CPU 0 and 1 share clock/voltage rails. The platform
      specific code calls dev_pm_opp_set_regulators() for CPU0 and the OPP
      core creates an OPP table for it (the individual OPPs aren't initialized
      as of now). The same is repeated for CPU1 then. Because
      _opp_get_opp_table() doesn't compare DT node pointers currently, it
      fails to find the link between CPU0 and CPU1 and so creates a new OPP
      table.
      
      Fix this by calling _managed_opp() from _opp_get_opp_table().
      _managed_opp() gain an additional argument (index) to get the right node
      pointer. This resulted in simplifying code in _of_add_opp_table_v2() as
      well.
      Tested-by: NNiklas Cassel <niklas.cassel@linaro.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      283d55e6
  4. 20 9月, 2018 6 次提交
    • V
      OPP: Use a single mechanism to free the OPP table · cdd6ed90
      Viresh Kumar 提交于
      Currently there are two separate ways to free the OPP table based on how
      it is created in the first place.
      
      We call _dev_pm_opp_remove_table() to free the static and/or dynamic
      OPP, OPP list devices, etc. This is done for the case where the OPP
      table is added while initializing the OPPs, like via the path
      dev_pm_opp_of_add_table().
      
      We also call dev_pm_opp_put_opp_table() in some cases which eventually
      frees the OPP table structure once the reference count reaches 0. This
      is used by the first case as well as other cases like
      dev_pm_opp_set_regulators() where the OPPs aren't necessarily
      initialized at this point.
      
      This whole thing is a bit unclear and messy and obstruct any further
      cleanup/fixup of OPP core.
      
      This patch tries to streamline this by keeping a single path for OPP
      table destruction, i.e. dev_pm_opp_put_opp_table().
      
      All the cleanup happens in _opp_table_kref_release() now after the
      reference count reaches 0. _dev_pm_opp_remove_table() is removed as it
      isn't required anymore.
      
      We don't drop the reference to the OPP table after creating it from
      _of_add_opp_table_v{1|2}() anymore and the same is dropped only when we
      try to remove them.
      Tested-by: NNiklas Cassel <niklas.cassel@linaro.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      cdd6ed90
    • V
      OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table() · 2a4eb735
      Viresh Kumar 提交于
      Only one platform was depending on this feature and it is already
      updated now. Stop removing dynamic OPPs from _dev_pm_opp_remove_table().
      This simplifies lot of paths and removes unnecessary parameters.
      Tested-by: NNiklas Cassel <niklas.cassel@linaro.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      2a4eb735
    • V
      OPP: Create separate kref for static OPPs list · d0e8ae6c
      Viresh Kumar 提交于
      The static OPPs don't always get freed with the OPP table, it can happen
      before that as well. For example, if the OPP table is first created
      using helpers like dev_pm_opp_set_supported_hw() and the OPPs are
      created at a later point. Now when the OPPs are removed, the OPP table
      stays until the time dev_pm_opp_put_supported_hw() is called.
      
      Later patches will streamline the freeing of OPP table and that requires
      the static OPPs to get freed with help of a separate kernel reference.
      This patch prepares for that by creating a separate kref for static OPPs
      list.
      Tested-by: NNiklas Cassel <niklas.cassel@linaro.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      d0e8ae6c
    • V
      OPP: Don't take OPP table's kref for static OPPs · 0ad8c623
      Viresh Kumar 提交于
      The reference count is only required to be incremented for every call
      that may lead to adding the OPP table. For static OPPs the same should
      be done from the parent routine which adds all static OPPs together and
      so only one refcount for all static OPPs.
      
      Update code to reflect that.
      
      The refcount is incremented every time a dynamic OPP is created (as that
      can lead to creating the OPP table) and the same is dropped when the OPP
      is removed.
      Tested-by: NNiklas Cassel <niklas.cassel@linaro.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      0ad8c623
    • V
      OPP: Pass index to _of_init_opp_table() · eb7c8743
      Viresh Kumar 提交于
      This is a preparatory patch required for the next commit which will
      start using OPP table's node pointer in _of_init_opp_table(), which
      requires the index in order to read the OPP table's phandle.
      
      This commit adds the index argument in the call chains in order to get
      it delivered to _of_init_opp_table().
      Tested-by: NNiklas Cassel <niklas.cassel@linaro.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      eb7c8743
    • V
      OPP: Protect dev_list with opp_table lock · 3d255699
      Viresh Kumar 提交于
      The dev_list needs to be protected with a lock, else we may have
      simultaneous access (addition/removal) to it and that would be racy.
      Extend scope of the opp_table lock to protect dev_list as well.
      Tested-by: NNiklas Cassel <niklas.cassel@linaro.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      3d255699
  5. 19 6月, 2018 1 次提交
    • W
      PM / OPP: Update voltage in case freq == old_freq · c5c2a97b
      Waldemar Rymarkiewicz 提交于
      This commit fixes a rare but possible case when the clk rate is updated
      without update of the regulator voltage.
      
      At boot up, CPUfreq checks if the system is running at the right freq. This
      is a sanity check in case a bootloader set clk rate that is outside of freq
      table present with cpufreq core. In such cases system can be unstable so
      better to change it to a freq that is preset in freq-table.
      
      The CPUfreq takes next freq that is >= policy->cur and this is our
      target_freq that needs to be set now.
      
      dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the
      old_freq (a current rate). If these are equal it returns early. If not,
      it searches for OPP (old_opp) that fits best to old_freq (not listed in
      the table) and updates old_freq (!).
      
      Here, we can end up with old_freq = old_opp.rate = target_freq, which
      is not handled in _generic_set_opp_regulator(). It's supposed to update
      voltage only when freq > old_freq  || freq > old_freq.
      
      if (freq > old_freq) {
      		ret = _set_opp_voltage(dev, reg, new_supply);
      [...]
      if (freq < old_freq) {
      		ret = _set_opp_voltage(dev, reg, new_supply);
      		if (ret)
      
      It results in, no voltage update while clk rate is updated.
      
      Example:
      freq-table = {
      	1000MHz   1.15V
      	 666MHZ   1.10V
      	 333MHz   1.05V
      }
      boot-up-freq        = 800MHz   # not listed in freq-table
      freq = target_freq  = 1GHz
      old_freq            = 800Mhz
      old_opp = _find_freq_ceil(opp_table, &old_freq);  #(old_freq is modified!)
      old_freq            = 1GHz
      
      Fixes: 6a0712f6 ("PM / OPP: Add dev_pm_opp_set_rate()")
      Cc: 4.6+ <stable@vger.kernel.org> # v4.6+
      Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@gmail.com>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      c5c2a97b
  6. 22 5月, 2018 4 次提交
    • V
      PM / OPP: Fix shared OPP table support in dev_pm_opp_register_set_opp_helper() · 5019acc6
      Viresh Kumar 提交于
      It should be fine to call dev_pm_opp_register_set_opp_helper() for all
      possible CPUs, even if some of them share the OPP table as the caller
      may not be aware of sharing policy.
      
      Lets increment the reference count of the OPP table and return its
      pointer. The caller need to call dev_pm_opp_register_put_opp_helper()
      the same number of times later on to drop all the references.
      
      To avoid adding another counter to count how many times
      dev_pm_opp_register_set_opp_helper() is called for the same OPP table,
      dev_pm_opp_register_put_opp_helper() frees the resources on the very
      first call made to it, assuming that the caller would be calling it
      sequentially for all the CPUs. We can revisit that if that assumption is
      broken in the future.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      5019acc6
    • V
      PM / OPP: Fix shared OPP table support in dev_pm_opp_set_regulators() · 779b783c
      Viresh Kumar 提交于
      It should be fine to call dev_pm_opp_set_regulators() for all possible
      CPUs, even if some of them share the OPP table as the caller may not be
      aware of sharing policy.
      
      Lets increment the reference count of the OPP table and return its
      pointer. The caller need to call dev_pm_opp_put_regulators() the same
      number of times later on to drop all the references.
      
      To avoid adding another counter to count how many times
      dev_pm_opp_set_regulators() is called for the same OPP table,
      dev_pm_opp_put_regulators() frees the resources on the very first call
      made to it, assuming that the caller would be calling it sequentially
      for all the CPUs. We can revisit that if that assumption is broken in
      the future.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      779b783c
    • V
      PM / OPP: Fix shared OPP table support in dev_pm_opp_set_prop_name() · 878ec1a9
      Viresh Kumar 提交于
      It should be fine to call dev_pm_opp_set_prop_name() for all possible
      CPUs, even if some of them share the OPP table as the caller may not be
      aware of sharing policy.
      
      Lets increment the reference count of the OPP table and return its
      pointer. The caller need to call dev_pm_opp_put_prop_name() the same
      number of times later on to drop all the references.
      
      To avoid adding another counter to count how many times
      dev_pm_opp_set_prop_name() is called for the same OPP table,
      dev_pm_opp_put_prop_name() frees the resources on the very first call
      made to it, assuming that the caller would be calling it sequentially
      for all the CPUs. We can revisit that if that assumption is broken in
      the future.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      878ec1a9
    • V
      PM / OPP: Fix shared OPP table support in dev_pm_opp_set_supported_hw() · 25419de1
      Viresh Kumar 提交于
      It should be fine to call dev_pm_opp_set_supported_hw() for all possible
      CPUs, even if some of them share the OPP table as the caller may not be
      aware of sharing policy.
      
      Lets increment the reference count of the OPP table and return its
      pointer. The caller need to call dev_pm_opp_put_supported_hw() the same
      number of times later on to drop all the references.
      
      To avoid adding another counter to count how many times
      dev_pm_opp_set_supported_hw() is called for the same OPP table,
      dev_pm_opp_put_supported_hw() frees the resources on the very first call
      made to it, assuming that the caller would be calling it sequentially
      for all the CPUs. We can revisit that if that assumption is broken in
      the future.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      25419de1
  7. 09 5月, 2018 4 次提交
  8. 14 10月, 2017 2 次提交
  9. 11 10月, 2017 2 次提交
  10. 03 10月, 2017 1 次提交
  11. 26 9月, 2017 1 次提交
  12. 24 6月, 2017 1 次提交
  13. 22 6月, 2017 2 次提交
  14. 24 2月, 2017 1 次提交
  15. 07 2月, 2017 1 次提交
  16. 30 1月, 2017 9 次提交