aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/opp/core.c
AgeCommit message (Collapse)Author
2020-01-27OPP: Fix missing debugfs supply directory for OPPsViresh Kumar
[ Upstream commit 46f48aca2e5aef3f430e95d1a5fb68227ec8ec85 ] There is one case where we may end up with no "supply" directory for the OPPs in debugfs. That happens when the OPP core isn't managing the regulators for the device and the device's OPP do have microvolt property. It happens because the opp_table->regulator_count remains set to 0 and the debugfs routines don't add any supply directory in such a case. This commit fixes that by setting opp_table->regulator_count to 1 in that particular case. But to make everything work nicely and not break other parts of the core, regulator_count is defined as "int" now instead of "unsigned int" and it can have different special values now. It is set to -1 initially to mark it "uninitialized" and later only we set it to 0 or positive values after checking how many supplies are there. This also helps in finding the bugs where only few of the OPPs have the "opp-microvolt" property set and not all. Fixes: 1fae788ed640 ("PM / OPP: Don't create debugfs "supply-0" directory unnecessarily") Reported-by: Quentin Perret <quentin.perret@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24OPP: Return error on error from dev_pm_opp_get_opp_count()Viresh Kumar
[ Upstream commit 09f662f95306f3e3d47ab6842bc4b0bb868a80ad ] Return error number instead of 0 on failures. Fixes: a1e8c13600bf ("PM / OPP: "opp-hz" is optional for power domains") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-24Revert "OPP: Protect dev_list with opp_table lock"Greg Kroah-Hartman
This reverts commit 4c64ce947cfa447993efe005cbaad7ba31a91612 which is commit 3d2556992a878a2210d3be498416aee39e0c32aa upstream. Turns out to break the build on the odroid machines, so it needs to be reverted. Reported-by: Viresh Kumar <viresh.kumar@linaro.org> Reported-by: "kernelci.org bot" <bot@kernelci.org> Cc: Niklas Cassel <niklas.cassel@linaro.org> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-11-20OPP: Protect dev_list with opp_table lockViresh Kumar
[ Upstream commit 3d2556992a878a2210d3be498416aee39e0c32aa ] 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-02-12OPP: Use opp_table->regulators to verify no regulator caseViresh Kumar
[ Upstream commit 90e3577b5feb42bac1269e16bb3d2bdd8f6df40f ] The value of opp_table->regulator_count is not very consistent right now and it may end up being 0 while we do have a "opp-microvolt" property in the OPP table. It was kept that way as we used to check if any regulators are set with the OPP core for a device or not using value of regulator_count. Lets use opp_table->regulators for that purpose as the meaning of regulator_count is going to change in the later patches. Reported-by: Quentin Perret <quentin.perret@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-06-19PM / OPP: Update voltage in case freq == old_freqWaldemar 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: 6a0712f6f199 ("PM / OPP: Add dev_pm_opp_set_rate()") Cc: 4.6+ <stable@vger.kernel.org> # v4.6+ Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-05-22PM / OPP: Fix shared OPP table support in dev_pm_opp_register_set_opp_helper()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: Viresh Kumar <viresh.kumar@linaro.org>
2018-05-22PM / OPP: Fix shared OPP table support in dev_pm_opp_set_regulators()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: Viresh Kumar <viresh.kumar@linaro.org>
2018-05-22PM / OPP: Fix shared OPP table support in dev_pm_opp_set_prop_name()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: Viresh Kumar <viresh.kumar@linaro.org>
2018-05-22PM / OPP: Fix shared OPP table support in dev_pm_opp_set_supported_hw()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: Viresh Kumar <viresh.kumar@linaro.org>
2018-05-09PM / OPP: Remove dev_pm_opp_{un}register_get_pstate_helper()Viresh Kumar
These helpers aren't used anymore, remove them. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-05-09PM / OPP: Get performance state using genpd helperViresh Kumar
The genpd core provides an API now to retrieve the performance state from DT, use that instead of the ->get_pstate() callback. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-05-09PM / OPP: Implement of_dev_pm_opp_find_required_opp()Viresh Kumar
A device's DT node or its OPP nodes can contain a phandle to other device's OPP node, in the "required-opps" property. This patch implements a routine to find that required OPP from the node that contains the "required-opps" property. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-05-09PM / OPP: "opp-hz" is optional for power domainsViresh Kumar
"opp-hz" property is optional for power domains now and we shouldn't error out if it is missing for power domains. This patch creates two new routines, _get_opp_count() and _opp_is_duplicate(), by separating existing code from their parent functions. Also skip duplicate OPP check for power domain OPPs as they may not have any the "opp-hz" field, but a platform specific performance state binding to uniquely identify OPP nodes. By default the debugfs OPP nodes are named using the "rate" value, but that isn't possible for the power domain OPP nodes and hence they use the index of the OPP node in the OPP node list instead. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-10-14PM / OPP: Add dev_pm_opp_{un}register_get_pstate_helper()Viresh Kumar
This adds the dev_pm_opp_{un}register_get_pstate_helper() helper routines which will be used to set the get_pstate() callback for a device. This callback will be later called internally by the OPP core to get performance state corresponding to an OPP. This is required temporarily until the time we have proper DT bindings to include the performance state information. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-14PM / OPP: Support updating performance state of device's power domainViresh Kumar
The genpd framework now provides an API to request device's power domain to update its performance state. Use that interface from the OPP core for devices whose power domains support performance states. Note that this commit doesn't add any mechanism by which performance states are made available to the OPP core. That would be done by a later commit. Note that the current implementation is restricted to the case where the device doesn't have separate regulators for itself. We shouldn't over engineer the code before we have real use case for them. We can always come back and add more code to support such cases later on. Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-11PM / OPP: Rename dev_pm_opp_register_put_opp_helper()Viresh Kumar
The routine is named incorrectly since the first attempt as there is nothing like a put_opp() helper. We wanted to unregister the set_opp() helper here and so it should rather be named as dev_pm_opp_unregister_set_opp_helper(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-11PM / OPP: Move error message to debug levelFabio Estevam
On some i.MX6 platforms which do not have speed grading check, opp table will not be created in platform code, so cpufreq driver prints the following error message: cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19) However, this is not really an error in this case because the imx6q-cpufreq driver first calls dev_pm_opp_get_opp_count() and if it fails, it means that platform code does not provide OPP and then dev_pm_opp_of_add_table() will be called. In order to avoid such confusing error message, move it to debug level. It is up to the caller of dev_pm_opp_get_opp_count() to check its return value and decide if it will print an error or not. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-03PM / OPP: Move the OPP directory out of power/Viresh Kumar
The drivers/base/power/ directory is special and contains code related to power management core like system suspend/resume, hibernation, etc. It was fine to keep the OPP code inside it when we had just one file for it, but it is growing now and already has a directory for itself. Lets move it directly under drivers/ directory, just like cpufreq and cpuidle. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>