kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-10-16 22:39:48 +00:00
Code Issues Releases Packages Activity
linux/drivers/opp/of.c

1621 lines
40 KiB
Raw Permalink Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-04 10:11:33 +02:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: add missing of_node_put() for of_get_cpu_node() Commit 762792913f8c (PM / OPP: Fix get sharing CPUs when hotplug is used) moved away from using cpu_dev->of_node because of some limitations. However, commit 7467c9d95989 (of: return of_get_cpu_node from of_cpu_device_node_get if CPUs are not registered) added support to fall back to of_get_cpu_node() if called if CPUs are not registered yet. Add the missing of_node_put() for the CPU device nodes. Also go back to using of_cpu_device_node_get() in dev_pm_opp_of_get_sharing_cpus() to avoid scanning the device tree again. Acked-by: Viresh Kumar <vireshk@kernel.org> Fixes: 762792913f8c (PM / OPP: Fix get sharing CPUs when hotplug is used) Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-12 11:32:23 +01:00
PM / OPP: Get performance state using genpd helper 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>
2016-11-18 15:47:46 +05:30
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Parse OPP table's DT properties from _of_init_opp_table() Parse the DT properties present in the OPP table from _of_init_opp_table(), which is a dedicated routine for DT parsing. Minor relocation of helpers is required for this. It is possible now for _managed_opp() to return a partially initialized OPP table if the OPP table is created via the helpers like dev_pm_opp_set_supported_hw() and we need another flag to indicate if the static OPP are already parsed or not to make sure we don't incorrectly skip initializing the static OPPs. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-14 12:04:43 +05:30
OPP: Prevent creating multiple OPP tables for devices sharing OPP nodes 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-07 09:01:54 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Use dev_pm_opp_get_opp_table() instead of _add_opp_table() Migrate all users of _add_opp_table() to use dev_pm_opp_get_opp_table() to guarantee that the OPP table doesn't get freed while being used. Also update _managed_opp() to get the reference to the OPP table. Now that the OPP table wouldn't get freed while these routines are executing after dev_pm_opp_get_opp_table() is called, there is no need to take opp_table_lock. Drop them as well. Now that _add_opp_table(), _remove_opp_table() and the unlocked release routines aren't used anymore, remove them. 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-01-23 10:11:45 +05:30
OPP: Prevent creating multiple OPP tables for devices sharing OPP nodes 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-07 09:01:54 +05:30
PM / OPP: Use dev_pm_opp_get_opp_table() instead of _add_opp_table() Migrate all users of _add_opp_table() to use dev_pm_opp_get_opp_table() to guarantee that the OPP table doesn't get freed while being used. Also update _managed_opp() to get the reference to the OPP table. Now that the OPP table wouldn't get freed while these routines are executing after dev_pm_opp_get_opp_table() is called, there is no need to take opp_table_lock. Drop them as well. Now that _add_opp_table(), _remove_opp_table() and the unlocked release routines aren't used anymore, remove them. 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-01-23 10:11:45 +05:30
OPP: Prevent creating multiple OPP tables for devices sharing OPP nodes 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-07 09:01:54 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Move away from RCU locking The RCU locking isn't well suited for the OPP core. The RCU locking fits better for reader heavy stuff, while the OPP core have at max one or two readers only at a time. Over that, it was getting very confusing the way RCU locking was used with the OPP core. The individual OPPs are mostly well handled, i.e. for an update a new structure was created and then that replaced the older one. But the OPP tables were updated directly all the time from various parts of the core. Though they were mostly used from within RCU locked region, they didn't had much to do with RCU and were governed by the mutex instead. And that mixed with the 'opp_table_lock' has made the core even more confusing. Now that we are already managing the OPPs and the OPP tables with kernel reference infrastructure, we can get rid of RCU locking completely and simplify the code a lot. Remove all RCU references from code and comments. Acquire opp_table->lock while parsing the list of OPPs though. 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-01-23 10:11:49 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Use dev_pm_opp_get_opp_table() instead of _add_opp_table() Migrate all users of _add_opp_table() to use dev_pm_opp_get_opp_table() to guarantee that the OPP table doesn't get freed while being used. Also update _managed_opp() to get the reference to the OPP table. Now that the OPP table wouldn't get freed while these routines are executing after dev_pm_opp_get_opp_table() is called, there is no need to take opp_table_lock. Drop them as well. Now that _add_opp_table(), _remove_opp_table() and the unlocked release routines aren't used anymore, remove them. 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-01-23 10:11:45 +05:30
PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table dev_pm_opp_get_sharing_cpus() returns 0 even in the case when the OPP core doesn't know whether or not the table is shared. It works on the majority of platforms, where the OPP table is never created before invoking the function and then -ENODEV is returned by it. But in the case of one platform (Jetson TK1) at least, the situation is a bit different. The OPP table has been created (somehow) before dev_pm_opp_get_sharing_cpus() is called and it returns 0. Its caller treats that as 'the CPUs don't share OPPs' and that leads to degraded performance. Fix this by converting 'shared_opp' in struct opp_table to an enum and making dev_pm_opp_get_sharing_cpus() return -EINVAL in case when the value of that field is "access unknown", so that the caller can handle it accordingly (cpufreq-dt considers that as 'all CPUs share the table', for example). Fixes: 6f707daa3833 "PM / OPP: Add dev_pm_opp_get_sharing_cpus()" Reported-and-tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw : Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-16 19:03:11 +05:30
PM / OPP: Use dev_pm_opp_get_opp_table() instead of _add_opp_table() Migrate all users of _add_opp_table() to use dev_pm_opp_get_opp_table() to guarantee that the OPP table doesn't get freed while being used. Also update _managed_opp() to get the reference to the OPP table. Now that the OPP table wouldn't get freed while these routines are executing after dev_pm_opp_get_opp_table() is called, there is no need to take opp_table_lock. Drop them as well. Now that _add_opp_table(), _remove_opp_table() and the unlocked release routines aren't used anymore, remove them. 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-01-23 10:11:45 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Prevent creating multiple OPP tables for devices sharing OPP nodes 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-07 09:01:54 +05:30
PM / OPP: Use dev_pm_opp_get_opp_table() instead of _add_opp_table() Migrate all users of _add_opp_table() to use dev_pm_opp_get_opp_table() to guarantee that the OPP table doesn't get freed while being used. Also update _managed_opp() to get the reference to the OPP table. Now that the OPP table wouldn't get freed while these routines are executing after dev_pm_opp_get_opp_table() is called, there is no need to take opp_table_lock. Drop them as well. Now that _add_opp_table(), _remove_opp_table() and the unlocked release routines aren't used anymore, remove them. 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-01-23 10:11:45 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Don't print an error if required-opps is missing The 'required-opps' property is considered optional, hence remove the pr_err() in of_parse_required_opp() when we find the property is missing. While at it, also fix the return value of of_get_required_opp_performance_state() when of_parse_required_opp() fails, return a -ENODEV instead of the -EINVAL. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-08-12 16:57:20 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
OPP: Improve _find_table_of_opp_np() Make _find_table_of_opp_np() more efficient by using of_get_parent() to find the parent OPP table node. Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-11-22 11:04:00 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
OPP: Improve _find_table_of_opp_np() Make _find_table_of_opp_np() more efficient by using of_get_parent() to find the parent OPP table node. Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-11-22 11:04:00 +05:30
opp: Allocate the OPP table outside of opp_table_lock There is no critical section which needs protection with locks while allocating an OPP table, except while adding it to the opp_tables list. And taking the opp_table_lock for the entire duration causes circular dependency issues like the one mentioned below. This patch takes another approach to reduce the size of the critical section to avoid such issues, the details of that are present within the patch. ====================================================== WARNING: possible circular locking dependency detected 5.4.72 #14 Not tainted ------------------------------------------------------ chrome/1865 is trying to acquire lock: ffffffdd34921750 (opp_table_lock){+.+.}, at: _find_opp_table+0x34/0x74 but task is already holding lock: ffffff81f0fc71a8 (reservation_ww_class_mutex){+.+.}, at: submit_lock_objects+0x70/0x1ec fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-ce" which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (reservation_ww_class_mutex){+.+.}: __mutex_lock_common+0xec/0xc0c ww_mutex_lock_interruptible+0x5c/0xc4 msm_gem_fault+0x2c/0x124 __do_fault+0x40/0x16c handle_mm_fault+0x7cc/0xd98 do_page_fault+0x230/0x3b4 do_translation_fault+0x5c/0x78 do_mem_abort+0x4c/0xb4 el0_da+0x1c/0x20 -> #3 (&mm->mmap_sem){++++}: __might_fault+0x70/0x98 compat_filldir+0xf8/0x48c dcache_readdir+0x70/0x1dc iterate_dir+0xd4/0x180 __arm64_compat_sys_getdents+0xa0/0x19c el0_svc_common+0xa8/0x178 el0_svc_compat_handler+0x2c/0x40 el0_svc_compat+0x8/0x10 -> #2 (&sb->s_type->i_mutex_key#3){++++}: down_write+0x54/0x16c start_creating+0x68/0x128 debugfs_create_dir+0x28/0x114 opp_debug_register+0x8c/0xc0 _add_opp_dev_unlocked+0x5c/0x70 _add_opp_dev+0x38/0x58 _opp_get_opp_table+0xdc/0x1ac dev_pm_opp_get_opp_table_indexed+0x24/0x30 dev_pm_opp_of_add_table_indexed+0x48/0x84 of_genpd_add_provider_onecell+0xc0/0x1b8 rpmhpd_probe+0x240/0x268 platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_populate+0x70/0xbc devm_of_platform_populate+0x58/0xa0 rpmh_rsc_probe+0x36c/0x3cc platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_bus_create+0x230/0x368 of_platform_populate+0x70/0xbc of_platform_default_populate_init+0xa8/0xc0 do_one_initcall+0x1c8/0x3fc do_initcall_level+0xb4/0x10c do_basic_setup+0x30/0x48 kernel_init_freeable+0x124/0x1a4 kernel_init+0x14/0x104 ret_from_fork+0x10/0x18 -> #1 (&opp_table->lock){+.+.}: __mutex_lock_common+0xec/0xc0c mutex_lock_nested+0x40/0x50 _add_opp_dev+0x2c/0x58 _opp_get_opp_table+0xdc/0x1ac dev_pm_opp_get_opp_table_indexed+0x24/0x30 dev_pm_opp_of_add_table_indexed+0x48/0x84 of_genpd_add_provider_onecell+0xc0/0x1b8 rpmhpd_probe+0x240/0x268 platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_populate+0x70/0xbc devm_of_platform_populate+0x58/0xa0 rpmh_rsc_probe+0x36c/0x3cc platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_populate+0x70/0xbc devm_of_platform_populate+0x58/0xa0 rpmh_rsc_probe+0x36c/0x3cc platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_bus_create+0x230/0x368 of_platform_populate+0x70/0xbc of_platform_default_populate_init+0xa8/0xc0 do_one_initcall+0x1c8/0x3fc do_initcall_level+0xb4/0x10c do_basic_setup+0x30/0x48 kernel_init_freeable+0x124/0x1a4 kernel_init+0x14/0x104 ret_from_fork+0x10/0x18 -> #0 (opp_table_lock){+.+.}: __lock_acquire+0xee4/0x2450 lock_acquire+0x1cc/0x210 __mutex_lock_common+0xec/0xc0c mutex_lock_nested+0x40/0x50 _find_opp_table+0x34/0x74 dev_pm_opp_find_freq_exact+0x2c/0xdc a6xx_gmu_resume+0xc8/0xecc a6xx_pm_resume+0x148/0x200 adreno_resume+0x28/0x34 pm_generic_runtime_resume+0x34/0x48 __rpm_callback+0x70/0x10c rpm_callback+0x34/0x8c rpm_resume+0x414/0x550 __pm_runtime_resume+0x7c/0xa0 msm_gpu_submit+0x60/0x1c0 msm_ioctl_gem_submit+0xadc/0xb60 drm_ioctl_kernel+0x9c/0x118 drm_ioctl+0x27c/0x408 drm_compat_ioctl+0xcc/0xdc __se_compat_sys_ioctl+0x100/0x206c __arm64_compat_sys_ioctl+0x20/0x2c el0_svc_common+0xa8/0x178 el0_svc_compat_handler+0x2c/0x40 el0_svc_compat+0x8/0x10 other info that might help us debug this: Chain exists of: opp_table_lock --> &mm->mmap_sem --> reservation_ww_class_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(reservation_ww_class_mutex); lock(&mm->mmap_sem); lock(reservation_ww_class_mutex); lock(opp_table_lock); *** DEADLOCK *** 3 locks held by chrome/1865: #0: ffffff81edecc0d8 (&dev->struct_mutex){+.+.}, at: msm_ioctl_gem_submit+0x264/0xb60 #1: ffffff81d0000870 (reservation_ww_class_acquire){+.+.}, at: msm_ioctl_gem_submit+0x8e8/0xb60 #2: ffffff81f0fc71a8 (reservation_ww_class_mutex){+.+.}, at: submit_lock_objects+0x70/0x1ec stack backtrace: CPU: 0 PID: 1865 Comm: chrome Not tainted 5.4.72 #14 Hardware name: Google Lazor (rev1+) with LTE (DT) Call trace: dump_backtrace+0x0/0x158 show_stack+0x20/0x2c dump_stack+0xc8/0x160 print_circular_bug+0x2c4/0x2c8 check_noncircular+0x1a8/0x1b0 __lock_acquire+0xee4/0x2450 lock_acquire+0x1cc/0x210 __mutex_lock_common+0xec/0xc0c mutex_lock_nested+0x40/0x50 _find_opp_table+0x34/0x74 dev_pm_opp_find_freq_exact+0x2c/0xdc a6xx_gmu_resume+0xc8/0xecc a6xx_pm_resume+0x148/0x200 adreno_resume+0x28/0x34 pm_generic_runtime_resume+0x34/0x48 __rpm_callback+0x70/0x10c rpm_callback+0x34/0x8c rpm_resume+0x414/0x550 __pm_runtime_resume+0x7c/0xa0 msm_gpu_submit+0x60/0x1c0 msm_ioctl_gem_submit+0xadc/0xb60 drm_ioctl_kernel+0x9c/0x118 drm_ioctl+0x27c/0x408 drm_compat_ioctl+0xcc/0xdc __se_compat_sys_ioctl+0x100/0x206c __arm64_compat_sys_ioctl+0x20/0x2c el0_svc_common+0xa8/0x178 el0_svc_compat_handler+0x2c/0x40 el0_svc_compat+0x8/0x10 Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-10-27 16:53:21 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
OPP: Improve _find_table_of_opp_np() Make _find_table_of_opp_np() more efficient by using of_get_parent() to find the parent OPP table node. Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-11-22 11:04:00 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allocate the OPP table outside of opp_table_lock There is no critical section which needs protection with locks while allocating an OPP table, except while adding it to the opp_tables list. And taking the opp_table_lock for the entire duration causes circular dependency issues like the one mentioned below. This patch takes another approach to reduce the size of the critical section to avoid such issues, the details of that are present within the patch. ====================================================== WARNING: possible circular locking dependency detected 5.4.72 #14 Not tainted ------------------------------------------------------ chrome/1865 is trying to acquire lock: ffffffdd34921750 (opp_table_lock){+.+.}, at: _find_opp_table+0x34/0x74 but task is already holding lock: ffffff81f0fc71a8 (reservation_ww_class_mutex){+.+.}, at: submit_lock_objects+0x70/0x1ec fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-ce" which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (reservation_ww_class_mutex){+.+.}: __mutex_lock_common+0xec/0xc0c ww_mutex_lock_interruptible+0x5c/0xc4 msm_gem_fault+0x2c/0x124 __do_fault+0x40/0x16c handle_mm_fault+0x7cc/0xd98 do_page_fault+0x230/0x3b4 do_translation_fault+0x5c/0x78 do_mem_abort+0x4c/0xb4 el0_da+0x1c/0x20 -> #3 (&mm->mmap_sem){++++}: __might_fault+0x70/0x98 compat_filldir+0xf8/0x48c dcache_readdir+0x70/0x1dc iterate_dir+0xd4/0x180 __arm64_compat_sys_getdents+0xa0/0x19c el0_svc_common+0xa8/0x178 el0_svc_compat_handler+0x2c/0x40 el0_svc_compat+0x8/0x10 -> #2 (&sb->s_type->i_mutex_key#3){++++}: down_write+0x54/0x16c start_creating+0x68/0x128 debugfs_create_dir+0x28/0x114 opp_debug_register+0x8c/0xc0 _add_opp_dev_unlocked+0x5c/0x70 _add_opp_dev+0x38/0x58 _opp_get_opp_table+0xdc/0x1ac dev_pm_opp_get_opp_table_indexed+0x24/0x30 dev_pm_opp_of_add_table_indexed+0x48/0x84 of_genpd_add_provider_onecell+0xc0/0x1b8 rpmhpd_probe+0x240/0x268 platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_populate+0x70/0xbc devm_of_platform_populate+0x58/0xa0 rpmh_rsc_probe+0x36c/0x3cc platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_bus_create+0x230/0x368 of_platform_populate+0x70/0xbc of_platform_default_populate_init+0xa8/0xc0 do_one_initcall+0x1c8/0x3fc do_initcall_level+0xb4/0x10c do_basic_setup+0x30/0x48 kernel_init_freeable+0x124/0x1a4 kernel_init+0x14/0x104 ret_from_fork+0x10/0x18 -> #1 (&opp_table->lock){+.+.}: __mutex_lock_common+0xec/0xc0c mutex_lock_nested+0x40/0x50 _add_opp_dev+0x2c/0x58 _opp_get_opp_table+0xdc/0x1ac dev_pm_opp_get_opp_table_indexed+0x24/0x30 dev_pm_opp_of_add_table_indexed+0x48/0x84 of_genpd_add_provider_onecell+0xc0/0x1b8 rpmhpd_probe+0x240/0x268 platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_populate+0x70/0xbc devm_of_platform_populate+0x58/0xa0 rpmh_rsc_probe+0x36c/0x3cc platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_populate+0x70/0xbc devm_of_platform_populate+0x58/0xa0 rpmh_rsc_probe+0x36c/0x3cc platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_bus_create+0x230/0x368 of_platform_populate+0x70/0xbc of_platform_default_populate_init+0xa8/0xc0 do_one_initcall+0x1c8/0x3fc do_initcall_level+0xb4/0x10c do_basic_setup+0x30/0x48 kernel_init_freeable+0x124/0x1a4 kernel_init+0x14/0x104 ret_from_fork+0x10/0x18 -> #0 (opp_table_lock){+.+.}: __lock_acquire+0xee4/0x2450 lock_acquire+0x1cc/0x210 __mutex_lock_common+0xec/0xc0c mutex_lock_nested+0x40/0x50 _find_opp_table+0x34/0x74 dev_pm_opp_find_freq_exact+0x2c/0xdc a6xx_gmu_resume+0xc8/0xecc a6xx_pm_resume+0x148/0x200 adreno_resume+0x28/0x34 pm_generic_runtime_resume+0x34/0x48 __rpm_callback+0x70/0x10c rpm_callback+0x34/0x8c rpm_resume+0x414/0x550 __pm_runtime_resume+0x7c/0xa0 msm_gpu_submit+0x60/0x1c0 msm_ioctl_gem_submit+0xadc/0xb60 drm_ioctl_kernel+0x9c/0x118 drm_ioctl+0x27c/0x408 drm_compat_ioctl+0xcc/0xdc __se_compat_sys_ioctl+0x100/0x206c __arm64_compat_sys_ioctl+0x20/0x2c el0_svc_common+0xa8/0x178 el0_svc_compat_handler+0x2c/0x40 el0_svc_compat+0x8/0x10 other info that might help us debug this: Chain exists of: opp_table_lock --> &mm->mmap_sem --> reservation_ww_class_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(reservation_ww_class_mutex); lock(&mm->mmap_sem); lock(reservation_ww_class_mutex); lock(opp_table_lock); *** DEADLOCK *** 3 locks held by chrome/1865: #0: ffffff81edecc0d8 (&dev->struct_mutex){+.+.}, at: msm_ioctl_gem_submit+0x264/0xb60 #1: ffffff81d0000870 (reservation_ww_class_acquire){+.+.}, at: msm_ioctl_gem_submit+0x8e8/0xb60 #2: ffffff81f0fc71a8 (reservation_ww_class_mutex){+.+.}, at: submit_lock_objects+0x70/0x1ec stack backtrace: CPU: 0 PID: 1865 Comm: chrome Not tainted 5.4.72 #14 Hardware name: Google Lazor (rev1+) with LTE (DT) Call trace: dump_backtrace+0x0/0x158 show_stack+0x20/0x2c dump_stack+0xc8/0x160 print_circular_bug+0x2c4/0x2c8 check_noncircular+0x1a8/0x1b0 __lock_acquire+0xee4/0x2450 lock_acquire+0x1cc/0x210 __mutex_lock_common+0xec/0xc0c mutex_lock_nested+0x40/0x50 _find_opp_table+0x34/0x74 dev_pm_opp_find_freq_exact+0x2c/0xdc a6xx_gmu_resume+0xc8/0xecc a6xx_pm_resume+0x148/0x200 adreno_resume+0x28/0x34 pm_generic_runtime_resume+0x34/0x48 __rpm_callback+0x70/0x10c rpm_callback+0x34/0x8c rpm_resume+0x414/0x550 __pm_runtime_resume+0x7c/0xa0 msm_gpu_submit+0x60/0x1c0 msm_ioctl_gem_submit+0xadc/0xb60 drm_ioctl_kernel+0x9c/0x118 drm_ioctl+0x27c/0x408 drm_compat_ioctl+0xcc/0xdc __se_compat_sys_ioctl+0x100/0x206c __arm64_compat_sys_ioctl+0x20/0x2c el0_svc_common+0xa8/0x178 el0_svc_compat_handler+0x2c/0x40 el0_svc_compat+0x8/0x10 Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-10-27 16:53:21 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allocate the OPP table outside of opp_table_lock There is no critical section which needs protection with locks while allocating an OPP table, except while adding it to the opp_tables list. And taking the opp_table_lock for the entire duration causes circular dependency issues like the one mentioned below. This patch takes another approach to reduce the size of the critical section to avoid such issues, the details of that are present within the patch. ====================================================== WARNING: possible circular locking dependency detected 5.4.72 #14 Not tainted ------------------------------------------------------ chrome/1865 is trying to acquire lock: ffffffdd34921750 (opp_table_lock){+.+.}, at: _find_opp_table+0x34/0x74 but task is already holding lock: ffffff81f0fc71a8 (reservation_ww_class_mutex){+.+.}, at: submit_lock_objects+0x70/0x1ec fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-ce" which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (reservation_ww_class_mutex){+.+.}: __mutex_lock_common+0xec/0xc0c ww_mutex_lock_interruptible+0x5c/0xc4 msm_gem_fault+0x2c/0x124 __do_fault+0x40/0x16c handle_mm_fault+0x7cc/0xd98 do_page_fault+0x230/0x3b4 do_translation_fault+0x5c/0x78 do_mem_abort+0x4c/0xb4 el0_da+0x1c/0x20 -> #3 (&mm->mmap_sem){++++}: __might_fault+0x70/0x98 compat_filldir+0xf8/0x48c dcache_readdir+0x70/0x1dc iterate_dir+0xd4/0x180 __arm64_compat_sys_getdents+0xa0/0x19c el0_svc_common+0xa8/0x178 el0_svc_compat_handler+0x2c/0x40 el0_svc_compat+0x8/0x10 -> #2 (&sb->s_type->i_mutex_key#3){++++}: down_write+0x54/0x16c start_creating+0x68/0x128 debugfs_create_dir+0x28/0x114 opp_debug_register+0x8c/0xc0 _add_opp_dev_unlocked+0x5c/0x70 _add_opp_dev+0x38/0x58 _opp_get_opp_table+0xdc/0x1ac dev_pm_opp_get_opp_table_indexed+0x24/0x30 dev_pm_opp_of_add_table_indexed+0x48/0x84 of_genpd_add_provider_onecell+0xc0/0x1b8 rpmhpd_probe+0x240/0x268 platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_populate+0x70/0xbc devm_of_platform_populate+0x58/0xa0 rpmh_rsc_probe+0x36c/0x3cc platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_bus_create+0x230/0x368 of_platform_populate+0x70/0xbc of_platform_default_populate_init+0xa8/0xc0 do_one_initcall+0x1c8/0x3fc do_initcall_level+0xb4/0x10c do_basic_setup+0x30/0x48 kernel_init_freeable+0x124/0x1a4 kernel_init+0x14/0x104 ret_from_fork+0x10/0x18 -> #1 (&opp_table->lock){+.+.}: __mutex_lock_common+0xec/0xc0c mutex_lock_nested+0x40/0x50 _add_opp_dev+0x2c/0x58 _opp_get_opp_table+0xdc/0x1ac dev_pm_opp_get_opp_table_indexed+0x24/0x30 dev_pm_opp_of_add_table_indexed+0x48/0x84 of_genpd_add_provider_onecell+0xc0/0x1b8 rpmhpd_probe+0x240/0x268 platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_populate+0x70/0xbc devm_of_platform_populate+0x58/0xa0 rpmh_rsc_probe+0x36c/0x3cc platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_populate+0x70/0xbc devm_of_platform_populate+0x58/0xa0 rpmh_rsc_probe+0x36c/0x3cc platform_drv_probe+0x90/0xb0 really_probe+0x134/0x2ec driver_probe_device+0x64/0xfc __device_attach_driver+0x8c/0xa4 bus_for_each_drv+0x90/0xd8 __device_attach+0xc0/0x148 device_initial_probe+0x20/0x2c bus_probe_device+0x34/0x94 device_add+0x1fc/0x3b0 of_device_add+0x3c/0x4c of_platform_device_create_pdata+0xb8/0xfc of_platform_bus_create+0x1e4/0x368 of_platform_bus_create+0x230/0x368 of_platform_populate+0x70/0xbc of_platform_default_populate_init+0xa8/0xc0 do_one_initcall+0x1c8/0x3fc do_initcall_level+0xb4/0x10c do_basic_setup+0x30/0x48 kernel_init_freeable+0x124/0x1a4 kernel_init+0x14/0x104 ret_from_fork+0x10/0x18 -> #0 (opp_table_lock){+.+.}: __lock_acquire+0xee4/0x2450 lock_acquire+0x1cc/0x210 __mutex_lock_common+0xec/0xc0c mutex_lock_nested+0x40/0x50 _find_opp_table+0x34/0x74 dev_pm_opp_find_freq_exact+0x2c/0xdc a6xx_gmu_resume+0xc8/0xecc a6xx_pm_resume+0x148/0x200 adreno_resume+0x28/0x34 pm_generic_runtime_resume+0x34/0x48 __rpm_callback+0x70/0x10c rpm_callback+0x34/0x8c rpm_resume+0x414/0x550 __pm_runtime_resume+0x7c/0xa0 msm_gpu_submit+0x60/0x1c0 msm_ioctl_gem_submit+0xadc/0xb60 drm_ioctl_kernel+0x9c/0x118 drm_ioctl+0x27c/0x408 drm_compat_ioctl+0xcc/0xdc __se_compat_sys_ioctl+0x100/0x206c __arm64_compat_sys_ioctl+0x20/0x2c el0_svc_common+0xa8/0x178 el0_svc_compat_handler+0x2c/0x40 el0_svc_compat+0x8/0x10 other info that might help us debug this: Chain exists of: opp_table_lock --> &mm->mmap_sem --> reservation_ww_class_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(reservation_ww_class_mutex); lock(&mm->mmap_sem); lock(reservation_ww_class_mutex); lock(opp_table_lock); *** DEADLOCK *** 3 locks held by chrome/1865: #0: ffffff81edecc0d8 (&dev->struct_mutex){+.+.}, at: msm_ioctl_gem_submit+0x264/0xb60 #1: ffffff81d0000870 (reservation_ww_class_acquire){+.+.}, at: msm_ioctl_gem_submit+0x8e8/0xb60 #2: ffffff81f0fc71a8 (reservation_ww_class_mutex){+.+.}, at: submit_lock_objects+0x70/0x1ec stack backtrace: CPU: 0 PID: 1865 Comm: chrome Not tainted 5.4.72 #14 Hardware name: Google Lazor (rev1+) with LTE (DT) Call trace: dump_backtrace+0x0/0x158 show_stack+0x20/0x2c dump_stack+0xc8/0x160 print_circular_bug+0x2c4/0x2c8 check_noncircular+0x1a8/0x1b0 __lock_acquire+0xee4/0x2450 lock_acquire+0x1cc/0x210 __mutex_lock_common+0xec/0xc0c mutex_lock_nested+0x40/0x50 _find_opp_table+0x34/0x74 dev_pm_opp_find_freq_exact+0x2c/0xdc a6xx_gmu_resume+0xc8/0xecc a6xx_pm_resume+0x148/0x200 adreno_resume+0x28/0x34 pm_generic_runtime_resume+0x34/0x48 __rpm_callback+0x70/0x10c rpm_callback+0x34/0x8c rpm_resume+0x414/0x550 __pm_runtime_resume+0x7c/0xa0 msm_gpu_submit+0x60/0x1c0 msm_ioctl_gem_submit+0xadc/0xb60 drm_ioctl_kernel+0x9c/0x118 drm_ioctl+0x27c/0x408 drm_compat_ioctl+0xcc/0xdc __se_compat_sys_ioctl+0x100/0x206c __arm64_compat_sys_ioctl+0x20/0x2c el0_svc_common+0xa8/0x178 el0_svc_compat_handler+0x2c/0x40 el0_svc_compat+0x8/0x10 Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-10-27 16:53:21 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
OPP: Improve _find_table_of_opp_np() Make _find_table_of_opp_np() more efficient by using of_get_parent() to find the parent OPP table node. Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-11-22 11:04:00 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
opp: Allocate genpd_virt_devs from dev_pm_opp_attach_genpd() Currently the space for the array of virtual devices is allocated along with the OPP table, but that isn't going to work well from now onwards. For single power domain case, a driver can either use the original device structure for setting the performance state (if genpd attached with dev_pm_domain_attach()) or use the virtual device structure (if genpd attached with dev_pm_domain_attach_by_name(), which returns the virtual device) and so we can't know in advance if we are going to need genpd_virt_devs array or not. Lets delay the allocation a bit and do it along with dev_pm_opp_attach_genpd() rather. The deallocation is done from dev_pm_opp_detach_genpd(). Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-05-08 15:43:36 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: of: Allow empty opp-table with opp-shared The opp binding now allows to have an empty opp table and shared-opp to still describe that devices share v/f lines. When initialising an empty opp table, allow such case by: - treating such conditions with warnings in place of errors - don't fail on empty table Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-12-08 17:42:27 +00:00
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Fix required-opps phandle array count check The 'required-opps' property is optional. So of_count_phandle_with_args() can return -ENOENT when queried for required-opps. Handle this case. Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-09-30 15:39:08 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allocate genpd_virt_devs from dev_pm_opp_attach_genpd() Currently the space for the array of virtual devices is allocated along with the OPP table, but that isn't going to work well from now onwards. For single power domain case, a driver can either use the original device structure for setting the performance state (if genpd attached with dev_pm_domain_attach()) or use the virtual device structure (if genpd attached with dev_pm_domain_attach_by_name(), which returns the virtual device) and so we can't know in advance if we are going to need genpd_virt_devs array or not. Lets delay the allocation a bit and do it along with dev_pm_opp_attach_genpd() rather. The deallocation is done from dev_pm_opp_detach_genpd(). Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-05-08 15:43:36 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allow required-opps to be used for non genpd use cases Don't limit required_opp_table to genpd only. One possible use case is cpufreq based devfreq governor, which can use required-opps property to derive devfreq from cpufreq. Though the OPP core still doesn't support non-genpd required-opps in _set_required_opps(). Suggested-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> [ Viresh: Update _set_required_opps() to check for genpd ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-06-16 13:33:35 +08:00
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
OPP: Pass index to _of_init_opp_table() 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-05 16:17:14 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Parse OPP table's DT properties from _of_init_opp_table() Parse the DT properties present in the OPP table from _of_init_opp_table(), which is a dedicated routine for DT parsing. Minor relocation of helpers is required for this. It is possible now for _managed_opp() to return a partially initialized OPP table if the OPP table is created via the helpers like dev_pm_opp_set_supported_hw() and we need another flag to indicate if the static OPP are already parsed or not to make sure we don't incorrectly skip initializing the static OPPs. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-14 12:04:43 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Parse OPP table's DT properties from _of_init_opp_table() Parse the DT properties present in the OPP table from _of_init_opp_table(), which is a dedicated routine for DT parsing. Minor relocation of helpers is required for this. It is possible now for _managed_opp() to return a partially initialized OPP table if the OPP table is created via the helpers like dev_pm_opp_set_supported_hw() and we need another flag to indicate if the static OPP are already parsed or not to make sure we don't incorrectly skip initializing the static OPPs. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-14 12:04:43 +05:30
OPP: Identify and mark genpd OPP tables We need to handle genpd OPP tables differently, this is already the case at one location and will be extended going forward. Add another field to the OPP table to check if the table belongs to a genpd or not. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-13 16:00:11 +05:30
OPP: Parse OPP table's DT properties from _of_init_opp_table() Parse the DT properties present in the OPP table from _of_init_opp_table(), which is a dedicated routine for DT parsing. Minor relocation of helpers is required for this. It is possible now for _managed_opp() to return a partially initialized OPP table if the OPP table is created via the helpers like dev_pm_opp_set_supported_hw() and we need another flag to indicate if the static OPP are already parsed or not to make sure we don't incorrectly skip initializing the static OPPs. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-14 12:04:43 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
OPP: Don't drop opp_table->np reference while it is still in use The OPP table contains a reference of the DT node, opp_table->np, throughout its lifetime. We shouldn't drop the refcount for the same from _of_init_opp_table(), but do that while removing the OPP table finally. Signed-off-by: Liang He <windhl@126.com> [ Viresh: Updated subject / commit log and drop reference from _of_clear_opp_table() ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-18 21:36:31 +08:00
OPP: Populate required opp tables from "required-opps" property The current implementation works only for the case where a single phandle is present in the "required-opps" property, while DT allows multiple phandles to be present there. This patch adds new infrastructure to parse all the phandles present in "required-opps" property and save pointers of the required OPP's OPP tables. These will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
OPP: Don't drop opp->np reference while it is still in use The struct dev_pm_opp contains a reference of the DT node, opp->np, throughout its lifetime. We should increase the refcount for the same from _opp_add_static_v2(), and drop it while removing the OPP finally. Signed-off-by: Liang He <windhl@126.com> [ Viresh: Updated subject / commit log, create _of_clear_opp() and drop reference from it] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-18 21:36:32 +08:00
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
OPP: Don't drop opp->np reference while it is still in use The struct dev_pm_opp contains a reference of the DT node, opp->np, throughout its lifetime. We should increase the refcount for the same from _opp_add_static_v2(), and drop it while removing the OPP finally. Signed-off-by: Liang He <windhl@126.com> [ Viresh: Updated subject / commit log, create _of_clear_opp() and drop reference from it] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-18 21:36:32 +08:00
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
opp: use list_del_init instead of list_del/INIT_LIST_HEAD Using list_del_init() instead of list_del() + INIT_LIST_HEAD() to simpify the code. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-05-18 12:49:10 +08:00
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
opp: Don't parse icc paths unnecessarily The DT node of the device may contain interconnect paths while the OPP table doesn't have the bandwidth values. There is no need to parse the paths in such cases. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Support the case of !opp_table and massaged changelog ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-28 00:54:18 +05:30
OPP: call of_node_put() on error path in _bandwidth_supported() This code does not call of_node_put(opp_np) if of_get_next_available_child() returns NULL. But it should. Fixes: 45679f9b508f ("opp: Don't parse icc paths unnecessarily") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-04-06 09:40:14 +03:00
opp: Don't parse icc paths unnecessarily The DT node of the device may contain interconnect paths while the OPP table doesn't have the bandwidth values. There is no need to parse the paths in such cases. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Support the case of !opp_table and massaged changelog ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-28 00:54:18 +05:30
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
opp: Don't parse icc paths unnecessarily The DT node of the device may contain interconnect paths while the OPP table doesn't have the bandwidth values. There is no need to parse the paths in such cases. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Support the case of !opp_table and massaged changelog ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-28 00:54:18 +05:30
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
opp: Don't parse icc paths unnecessarily The DT node of the device may contain interconnect paths while the OPP table doesn't have the bandwidth values. There is no need to parse the paths in such cases. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Support the case of !opp_table and massaged changelog ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-28 00:54:18 +05:30
opp: of: Allow empty opp-table with opp-shared The opp binding now allows to have an empty opp table and shared-opp to still describe that devices share v/f lines. When initialising an empty opp table, allow such case by: - treating such conditions with warnings in place of errors - don't fail on empty table Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-12-08 17:42:27 +00:00
opp: Don't parse icc paths unnecessarily The DT node of the device may contain interconnect paths while the OPP table doesn't have the bandwidth values. There is no need to parse the paths in such cases. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Sibi Sankar <sibis@codeaurora.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Support the case of !opp_table and massaged changelog ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-28 00:54:18 +05:30
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Allow opp-supported-hw to contain multiple versions The bindings allow multiple versions to be passed to "opp-supported-hw" property, either of which can result in enabling of the OPP. Update code to allow that. Tested-by: Stephan Gerhold <stephan@gerhold.net> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-08-26 16:32:27 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Don't support OPP if it provides supported-hw but platform does not The OPP framework allows each OPP to set a opp-supported-hw property which provides values that are matched against supported_hw values provided by the platform to limit support for certain OPPs on specific hardware. Currently, if the platform does not set supported_hw values, all OPPs are interpreted as supported, even if they have provided their own opp-supported-hw values. If an OPP has provided opp-supported-hw, it is indicating that there is some specific hardware configuration it is supported by. These constraints should be honored, and if no supported_hw has been provided by the platform, there is no way to determine if that OPP is actually supported, so it should be marked as not supported. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-09-23 15:07:47 -05:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Allow opp-supported-hw to contain multiple versions The bindings allow multiple versions to be passed to "opp-supported-hw" property, either of which can result in enabling of the OPP. Update code to allow that. Tested-by: Stephan Gerhold <stephan@gerhold.net> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-08-26 16:32:27 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Allow opp-supported-hw to contain multiple versions The bindings allow multiple versions to be passed to "opp-supported-hw" property, either of which can result in enabling of the OPP. Update code to allow that. Tested-by: Stephan Gerhold <stephan@gerhold.net> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-08-26 16:32:27 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Allow opp-supported-hw to contain multiple versions The bindings allow multiple versions to be passed to "opp-supported-hw" property, either of which can result in enabling of the OPP. Update code to allow that. Tested-by: Stephan Gerhold <stephan@gerhold.net> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-08-26 16:32:27 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Add "opp-microwatt" supporting code Add new property to the OPP: power value. The OPP entry in the DT can have "opp-microwatt". Add the needed code to handle this new property in the existing infrastructure. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:14 +00:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: opp-microvolt is not optional if regulators are set If dev_pm_opp_set_regulators() is called for a device and its regulators are set in the OPP core, the OPP nodes for the device must contain the "opp-microvolt" property, otherwise there is something wrong and we better error out. 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-05-23 09:32:12 +05:30
OPP: Fix missing debugfs supply directory for OPPs 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>
2018-12-11 16:39:36 +05:30
PM / OPP: opp-microvolt is not optional if regulators are set If dev_pm_opp_set_regulators() is called for a device and its regulators are set in the OPP core, the OPP nodes for the device must contain the "opp-microvolt" property, otherwise there is something wrong and we better error out. 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-05-23 09:32:12 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Fix missing debugfs supply directory for OPPs 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>
2018-12-11 16:39:36 +05:30
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
OPP: Add "opp-microwatt" supporting code Add new property to the OPP: power value. The OPP entry in the DT can have "opp-microwatt". Add the needed code to handle this new property in the existing infrastructure. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:14 +00:00
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
OPP: Add "opp-microwatt" supporting code Add new property to the OPP: power value. The OPP entry in the DT can have "opp-microwatt". Add the needed code to handle this new property in the existing infrastructure. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:14 +00:00
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
OPP: Add "opp-microwatt" supporting code Add new property to the OPP: power value. The OPP entry in the DT can have "opp-microwatt". Add the needed code to handle this new property in the existing infrastructure. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:14 +00:00
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Remove _dev_pm_opp_find_and_remove_table() wrapper Remove the unnecessary wrapper and merge _dev_pm_opp_find_and_remove_table() with dev_pm_opp_remove_table(). Tested-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-08-20 13:18:23 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Allow multiple clocks for a device This patch adds support to allow multiple clocks for a device. The design is pretty much similar to how this is done for regulators, and platforms can supply their own version of the config_clks() callback if they have multiple clocks for their device. The core manages the calls via opp_table->config_clks() eventually. We have kept both "clk" and "clks" fields in the OPP table structure and the reason is provided as a comment in _opp_set_clknames(). The same isn't done for "rates" though and we use rates[0] at most of the places now. Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-10 12:02:04 +05:30
OPP: Use consistent names for OPP table instances The OPP table is called "opp_table" at most of the places and "table" at few. Make all of them follow the same naming convention, "opp_table". Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-09 15:35:36 +05:30
opp: Add sanity checks in _read_opp_key() When we read the OPP keys, it would be nice to do some sanity checks of the values we get from DT and see if they match with the information that is populated in the OPP table. Let's pass a pointer of the table, so that we can do some validation. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Fix rebase conflicts ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:22 +03:00
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
OPP: Use consistent names for OPP table instances The OPP table is called "opp_table" at most of the places and "table" at few. Make all of them follow the same naming convention, "opp_table". Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-09 15:35:36 +05:30
opp: Add sanity checks in _read_opp_key() When we read the OPP keys, it would be nice to do some sanity checks of the values we get from DT and see if they match with the information that is populated in the OPP table. Let's pass a pointer of the table, so that we can do some validation. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Fix rebase conflicts ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:22 +03:00
OPP: Use consistent names for OPP table instances The OPP table is called "opp_table" at most of the places and "table" at few. Make all of them follow the same naming convention, "opp_table". Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-09 15:35:36 +05:30
opp: Add sanity checks in _read_opp_key() When we read the OPP keys, it would be nice to do some sanity checks of the values we get from DT and see if they match with the information that is populated in the OPP table. Let's pass a pointer of the table, so that we can do some validation. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Fix rebase conflicts ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:22 +03:00
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
OPP: Remove rate_not_available parameter to _opp_add() commit 32715be4fe95 ("opp: Fix adding OPP entries in a wrong order if rate is unavailable") removed the only user of this field, get rid of rest of it now. Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-08 11:57:24 +05:30
OPP: Add helpers for reading the binding properties The opp-hz DT property is not mandatory and we may use another property as a key in the OPP table. Add helper functions to simplify the reading and comparing the keys. Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Removed an unnecessary comment ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:19 +03:00
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
OPP: Add helpers for reading the binding properties The opp-hz DT property is not mandatory and we may use another property as a key in the OPP table. Add helper functions to simplify the reading and comparing the keys. Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Removed an unnecessary comment ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:19 +03:00
OPP: Allow multiple clocks for a device This patch adds support to allow multiple clocks for a device. The design is pretty much similar to how this is done for regulators, and platforms can supply their own version of the config_clks() callback if they have multiple clocks for their device. The core manages the calls via opp_table->config_clks() eventually. We have kept both "clk" and "clks" fields in the OPP table structure and the reason is provided as a comment in _opp_set_clknames(). The same isn't done for "rates" though and we use rates[0] at most of the places now. Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-10 12:02:04 +05:30
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
OPP: Allow multiple clocks for a device This patch adds support to allow multiple clocks for a device. The design is pretty much similar to how this is done for regulators, and platforms can supply their own version of the config_clks() callback if they have multiple clocks for their device. The core manages the calls via opp_table->config_clks() eventually. We have kept both "clk" and "clks" fields in the OPP table structure and the reason is provided as a comment in _opp_set_clknames(). The same isn't done for "rates" though and we use rates[0] at most of the places now. Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-10 12:02:04 +05:30
OPP: Add helpers for reading the binding properties The opp-hz DT property is not mandatory and we may use another property as a key in the OPP table. Add helper functions to simplify the reading and comparing the keys. Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Removed an unnecessary comment ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:19 +03:00
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
OPP: Use consistent names for OPP table instances The OPP table is called "opp_table" at most of the places and "table" at few. Make all of them follow the same naming convention, "opp_table". Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-09 15:35:36 +05:30
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
OPP: Use consistent names for OPP table instances The OPP table is called "opp_table" at most of the places and "table" at few. Make all of them follow the same naming convention, "opp_table". Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-09 15:35:36 +05:30
opp: Add support for parsing interconnect bandwidth The OPP bindings now support bandwidth values, so add support to parse it from device tree and store it into the new dev_pm_opp_icc_bw struct, which is part of the dev_pm_opp. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Create _read_bw() and use it, renamed _of_find_icc_paths() to dev_pm_opp_of_find_icc_paths(), exported it and made opp_table argument optional. Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:21 +03:00
OPP: Add helpers for reading the binding properties The opp-hz DT property is not mandatory and we may use another property as a key in the OPP table. Add helper functions to simplify the reading and comparing the keys. Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Removed an unnecessary comment ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:19 +03:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Don't allocate OPP table from _opp_allocate() There is no point in trying to find/allocate the table for every OPP that is added for a device. It would be far more efficient to allocate the table only once and pass its pointer to the routines that add the OPP entry. Locking is removed from _opp_add_static_v2() and _opp_add_v1() now as the callers call them with that lock already held. Call to _remove_opp_table() routine is also removed from _opp_free() now, as opp_table isn't allocated from within _opp_allocate(). This is handled by the routines which created the OPP table in the first place. 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-01-02 14:41:01 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added Currently the _of_add_opp_table_v2 call loops through the OPP nodes in the operating-points-v2 table in the device tree and calls _opp_add_static_v2 for each to add them to the table. It counts each iteration through this loop as an added OPP, however there are cases where _opp_add_static_v2() returns 0 but no new OPP is added to the list. This can happen while adding duplicate OPP or if the OPP isn't supported by hardware. Because of this the count variable will contain the number of OPP nodes in the table in device tree but not necessarily the ones that are actually added. As this count value is what is checked to determine if there are any valid OPPs, if a platform has an operating-points-v2 table with all OPP nodes containing opp-supported-hw values that are not currently supported, then _of_add_opp_table_v2 will fail to abort as it should due to an empty table. Additionally, since commit 3ba98324e81a ("PM / OPP: Get performance state using genpd helper"), the same count variable is compared against the number of OPPs containing performance states and requires that either all or none have pstates set, however in the case of any opp table that has any entries that do not get added by _opp_add_static_v2 due to incompatible opp-supported-hw fields, these numbers will not match and _of_add_opp_table_v2 will incorrectly fail. We need to clearly identify all the three cases (success, failure, unsupported/duplicate OPPs) and then increment count only on success case. Change return type of _opp_add_static_v2() to return the pointer to the newly added OPP instead of an integer. This routine now returns a valid pointer if the OPP is really added, NULL for unsupported or duplicate OPPs, and error value cased as a pointer on errors. Ideally the fixes tag in this commit should point back to the commit that introduced OPP v2 initially, as that's where we started incorrectly accounting for duplicate OPPs: commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings") But it wasn't a real problem until recently as the count was only used to check if any OPPs are added or not. And so this commit points to a rather recent commit where we added more code that depends on the value of "count". Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper") Reported-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 16:13:15 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added Currently the _of_add_opp_table_v2 call loops through the OPP nodes in the operating-points-v2 table in the device tree and calls _opp_add_static_v2 for each to add them to the table. It counts each iteration through this loop as an added OPP, however there are cases where _opp_add_static_v2() returns 0 but no new OPP is added to the list. This can happen while adding duplicate OPP or if the OPP isn't supported by hardware. Because of this the count variable will contain the number of OPP nodes in the table in device tree but not necessarily the ones that are actually added. As this count value is what is checked to determine if there are any valid OPPs, if a platform has an operating-points-v2 table with all OPP nodes containing opp-supported-hw values that are not currently supported, then _of_add_opp_table_v2 will fail to abort as it should due to an empty table. Additionally, since commit 3ba98324e81a ("PM / OPP: Get performance state using genpd helper"), the same count variable is compared against the number of OPPs containing performance states and requires that either all or none have pstates set, however in the case of any opp table that has any entries that do not get added by _opp_add_static_v2 due to incompatible opp-supported-hw fields, these numbers will not match and _of_add_opp_table_v2 will incorrectly fail. We need to clearly identify all the three cases (success, failure, unsupported/duplicate OPPs) and then increment count only on success case. Change return type of _opp_add_static_v2() to return the pointer to the newly added OPP instead of an integer. This routine now returns a valid pointer if the OPP is really added, NULL for unsupported or duplicate OPPs, and error value cased as a pointer on errors. Ideally the fixes tag in this commit should point back to the commit that introduced OPP v2 initially, as that's where we started incorrectly accounting for duplicate OPPs: commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings") But it wasn't a real problem until recently as the count was only used to check if any OPPs are added or not. And so this commit points to a rather recent commit where we added more code that depends on the value of "count". Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper") Reported-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 16:13:15 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added Currently the _of_add_opp_table_v2 call loops through the OPP nodes in the operating-points-v2 table in the device tree and calls _opp_add_static_v2 for each to add them to the table. It counts each iteration through this loop as an added OPP, however there are cases where _opp_add_static_v2() returns 0 but no new OPP is added to the list. This can happen while adding duplicate OPP or if the OPP isn't supported by hardware. Because of this the count variable will contain the number of OPP nodes in the table in device tree but not necessarily the ones that are actually added. As this count value is what is checked to determine if there are any valid OPPs, if a platform has an operating-points-v2 table with all OPP nodes containing opp-supported-hw values that are not currently supported, then _of_add_opp_table_v2 will fail to abort as it should due to an empty table. Additionally, since commit 3ba98324e81a ("PM / OPP: Get performance state using genpd helper"), the same count variable is compared against the number of OPPs containing performance states and requires that either all or none have pstates set, however in the case of any opp table that has any entries that do not get added by _opp_add_static_v2 due to incompatible opp-supported-hw fields, these numbers will not match and _of_add_opp_table_v2 will incorrectly fail. We need to clearly identify all the three cases (success, failure, unsupported/duplicate OPPs) and then increment count only on success case. Change return type of _opp_add_static_v2() to return the pointer to the newly added OPP instead of an integer. This routine now returns a valid pointer if the OPP is really added, NULL for unsupported or duplicate OPPs, and error value cased as a pointer on errors. Ideally the fixes tag in this commit should point back to the commit that introduced OPP v2 initially, as that's where we started incorrectly accounting for duplicate OPPs: commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings") But it wasn't a real problem until recently as the count was only used to check if any OPPs are added or not. And so this commit points to a rather recent commit where we added more code that depends on the value of "count". Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper") Reported-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 16:13:15 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added Currently the _of_add_opp_table_v2 call loops through the OPP nodes in the operating-points-v2 table in the device tree and calls _opp_add_static_v2 for each to add them to the table. It counts each iteration through this loop as an added OPP, however there are cases where _opp_add_static_v2() returns 0 but no new OPP is added to the list. This can happen while adding duplicate OPP or if the OPP isn't supported by hardware. Because of this the count variable will contain the number of OPP nodes in the table in device tree but not necessarily the ones that are actually added. As this count value is what is checked to determine if there are any valid OPPs, if a platform has an operating-points-v2 table with all OPP nodes containing opp-supported-hw values that are not currently supported, then _of_add_opp_table_v2 will fail to abort as it should due to an empty table. Additionally, since commit 3ba98324e81a ("PM / OPP: Get performance state using genpd helper"), the same count variable is compared against the number of OPPs containing performance states and requires that either all or none have pstates set, however in the case of any opp table that has any entries that do not get added by _opp_add_static_v2 due to incompatible opp-supported-hw fields, these numbers will not match and _of_add_opp_table_v2 will incorrectly fail. We need to clearly identify all the three cases (success, failure, unsupported/duplicate OPPs) and then increment count only on success case. Change return type of _opp_add_static_v2() to return the pointer to the newly added OPP instead of an integer. This routine now returns a valid pointer if the OPP is really added, NULL for unsupported or duplicate OPPs, and error value cased as a pointer on errors. Ideally the fixes tag in this commit should point back to the commit that introduced OPP v2 initially, as that's where we started incorrectly accounting for duplicate OPPs: commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings") But it wasn't a real problem until recently as the count was only used to check if any OPPs are added or not. And so this commit points to a rather recent commit where we added more code that depends on the value of "count". Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper") Reported-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 16:13:15 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Don't allocate OPP table from _opp_allocate() There is no point in trying to find/allocate the table for every OPP that is added for a device. It would be far more efficient to allocate the table only once and pass its pointer to the routines that add the OPP entry. Locking is removed from _opp_add_static_v2() and _opp_add_v1() now as the callers call them with that lock already held. Call to _remove_opp_table() routine is also removed from _opp_free() now, as opp_table isn't allocated from within _opp_allocate(). This is handled by the routines which created the OPP table in the first place. 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-01-02 14:41:01 +05:30
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added Currently the _of_add_opp_table_v2 call loops through the OPP nodes in the operating-points-v2 table in the device tree and calls _opp_add_static_v2 for each to add them to the table. It counts each iteration through this loop as an added OPP, however there are cases where _opp_add_static_v2() returns 0 but no new OPP is added to the list. This can happen while adding duplicate OPP or if the OPP isn't supported by hardware. Because of this the count variable will contain the number of OPP nodes in the table in device tree but not necessarily the ones that are actually added. As this count value is what is checked to determine if there are any valid OPPs, if a platform has an operating-points-v2 table with all OPP nodes containing opp-supported-hw values that are not currently supported, then _of_add_opp_table_v2 will fail to abort as it should due to an empty table. Additionally, since commit 3ba98324e81a ("PM / OPP: Get performance state using genpd helper"), the same count variable is compared against the number of OPPs containing performance states and requires that either all or none have pstates set, however in the case of any opp table that has any entries that do not get added by _opp_add_static_v2 due to incompatible opp-supported-hw fields, these numbers will not match and _of_add_opp_table_v2 will incorrectly fail. We need to clearly identify all the three cases (success, failure, unsupported/duplicate OPPs) and then increment count only on success case. Change return type of _opp_add_static_v2() to return the pointer to the newly added OPP instead of an integer. This routine now returns a valid pointer if the OPP is really added, NULL for unsupported or duplicate OPPs, and error value cased as a pointer on errors. Ideally the fixes tag in this commit should point back to the commit that introduced OPP v2 initially, as that's where we started incorrectly accounting for duplicate OPPs: commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings") But it wasn't a real problem until recently as the count was only used to check if any OPPs are added or not. And so this commit points to a rather recent commit where we added more code that depends on the value of "count". Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper") Reported-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 16:13:15 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Remove rate_not_available parameter to _opp_add() commit 32715be4fe95 ("opp: Fix adding OPP entries in a wrong order if rate is unavailable") removed the only user of this field, get rid of rest of it now. Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-08 11:57:24 +05:30
opp: Allow required-opps to be used for non genpd use cases Don't limit required_opp_table to genpd only. One possible use case is cpufreq based devfreq governor, which can use required-opps property to derive devfreq from cpufreq. Though the OPP core still doesn't support non-genpd required-opps in _set_required_opps(). Suggested-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org> [ Viresh: Update _set_required_opps() to check for genpd ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-06-16 13:33:35 +08:00
OPP: Add helpers for reading the binding properties The opp-hz DT property is not mandatory and we may use another property as a key in the OPP table. Add helper functions to simplify the reading and comparing the keys. Signed-off-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> [ Viresh: Removed an unnecessary comment ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-05-12 15:53:19 +03:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Allow multiple clocks for a device This patch adds support to allow multiple clocks for a device. The design is pretty much similar to how this is done for regulators, and platforms can supply their own version of the config_clks() callback if they have multiple clocks for their device. The core manages the calls via opp_table->config_clks() eventually. We have kept both "clk" and "clks" fields in the OPP table structure and the reason is provided as a comment in _opp_set_clknames(). The same isn't done for "rates" though and we use rates[0] at most of the places now. Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-10 12:02:04 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Don't drop opp->np reference while it is still in use The struct dev_pm_opp contains a reference of the DT node, opp->np, throughout its lifetime. We should increase the refcount for the same from _opp_add_static_v2(), and drop it while removing the OPP finally. Signed-off-by: Liang He <windhl@126.com> [ Viresh: Updated subject / commit log, create _of_clear_opp() and drop reference from it] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-18 21:36:32 +08:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Configure all required OPPs Now that all the infrastructure is in place to support multiple required OPPs, lets switch over to using it. A new internal routine _set_required_opps() takes care of updating performance state for all the required OPPs. With this the performance state updates are supported even when the end device needs to configure regulators as well, that wasn't the case earlier. The pstates were earlier stored in the end device's OPP structures, that also changes now as those values are stored in the genpd's OPP structures. And so we switch over to using pm_genpd_opp_to_performance_state() instead of of_genpd_opp_to_performance_state() to get performance state for the genpd OPPs. The routine _generic_set_opp_domain() is not required anymore and is removed. On errors we don't try to recover by reverting to old settings as things are really complex now and the calls here should never really fail unless there is a bug. There is no point increasing the complexity, for code which will never be executed. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-14 10:03:26 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Remove rate_not_available parameter to _opp_add() commit 32715be4fe95 ("opp: Fix adding OPP entries in a wrong order if rate is unavailable") removed the only user of this field, get rid of rest of it now. Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-08 11:57:24 +05:30
PM / OPP: Fix memory leak while adding duplicate OPPs There are two types of duplicate OPPs that get different behavior from the core: A) An earlier OPP is marked 'available' and has same freq/voltages as the new one. B) An earlier OPP with same frequency, but is marked 'unavailable' OR doesn't have same voltages as the new one. The OPP core returns 0 for the first one, but -EEXIST for the second. While the OPP core returns 0 for the first case, its callers don't free the newly allocated OPP structure which isn't used anymore. Fix that by returning -EBUSY instead of 0, but make the callers return 0 eventually. As this isn't a critical fix, its not getting marked for stable kernel. 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-01-02 14:40:55 +05:30
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
PM / OPP: Fix memory leak while adding duplicate OPPs There are two types of duplicate OPPs that get different behavior from the core: A) An earlier OPP is marked 'available' and has same freq/voltages as the new one. B) An earlier OPP with same frequency, but is marked 'unavailable' OR doesn't have same voltages as the new one. The OPP core returns 0 for the first one, but -EEXIST for the second. While the OPP core returns 0 for the first case, its callers don't free the newly allocated OPP structure which isn't used anymore. Fix that by returning -EBUSY instead of 0, but make the callers return 0 eventually. As this isn't a critical fix, its not getting marked for stable kernel. 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-01-02 14:40:55 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Reuse _opp_compare_key() in _opp_add_static_v2() Reuse _opp_compare_key() in _opp_add_static_v2() instead of just comparing frequency while finding suspend frequency. Also add a comment over _opp_compare_key() explaining its return values. Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-10 10:32:50 +05:30
OPP: Allow multiple clocks for a device This patch adds support to allow multiple clocks for a device. The design is pretty much similar to how this is done for regulators, and platforms can supply their own version of the config_clks() callback if they have multiple clocks for their device. The core manages the calls via opp_table->config_clks() eventually. We have kept both "clk" and "clks" fields in the OPP table structure and the reason is provided as a comment in _opp_set_clknames(). The same isn't done for "rates" though and we use rates[0] at most of the places now. Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-10 12:02:04 +05:30
opp: of: Support multiple suspend OPPs defined in DT With property "opp-supported-hw" introduced, the OPP table in DT could be a large OPP table and ONLY a subset of OPPs are available, based on the version of the hardware running on. That introduces restriction of using "opp-suspend" property to define the suspend OPP, as we are NOT sure if the OPP containing "opp-suspend" property is available for the hardware running on, and the of opp core does NOT allow multiple suspend OPPs defined in DT OPP table. To eliminate this restrition, make of opp core allow multiple suspend OPPs defined in DT, and pick the OPP with highest rate and with "opp-suspend" property present to be suspend OPP, it can speed up the suspend/resume process. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-07-09 16:00:13 +08:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Print OPP level in debug message of _opp_add_static_v2() Print OPP level in debug message of _opp_add_static_v2(). This helps to chase GENPD bugs. Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Tested-by: Matt Merhar <mattmerhar@protonmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-01-18 03:55:24 +03:00
OPP: Allow multiple clocks for a device This patch adds support to allow multiple clocks for a device. The design is pretty much similar to how this is done for regulators, and platforms can supply their own version of the config_clks() callback if they have multiple clocks for their device. The core manages the calls via opp_table->config_clks() eventually. We have kept both "clk" and "clks" fields in the OPP table structure and the reason is provided as a comment in _opp_set_clknames(). The same isn't done for "rates" though and we use rates[0] at most of the places now. Co-developed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-06-10 12:02:04 +05:30
PM / OPP: Add infrastructure to manage multiple regulators This patch adds infrastructure to manage multiple regulators and updates the only user (cpufreq-dt) of dev_pm_opp_set{put}_regulator(). This is preparatory work for adding full support for devices with multiple regulators. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-01 16:28:19 +05:30
opp: Print OPP level in debug message of _opp_add_static_v2() Print OPP level in debug message of _opp_add_static_v2(). This helps to chase GENPD bugs. Tested-by: Peter Geis <pgwipeout@gmail.com> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Tested-by: Matt Merhar <mattmerhar@protonmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-01-18 03:55:24 +03:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Move away from RCU locking The RCU locking isn't well suited for the OPP core. The RCU locking fits better for reader heavy stuff, while the OPP core have at max one or two readers only at a time. Over that, it was getting very confusing the way RCU locking was used with the OPP core. The individual OPPs are mostly well handled, i.e. for an update a new structure was created and then that replaced the older one. But the OPP tables were updated directly all the time from various parts of the core. Though they were mostly used from within RCU locked region, they didn't had much to do with RCU and were governed by the mutex instead. And that mixed with the 'opp_table_lock' has made the core even more confusing. Now that we are already managing the OPPs and the OPP tables with kernel reference infrastructure, we can get rid of RCU locking completely and simplify the code a lot. Remove all RCU references from code and comments. Acquire opp_table->lock while parsing the list of OPPs though. 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-01-23 10:11:49 +05:30
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added Currently the _of_add_opp_table_v2 call loops through the OPP nodes in the operating-points-v2 table in the device tree and calls _opp_add_static_v2 for each to add them to the table. It counts each iteration through this loop as an added OPP, however there are cases where _opp_add_static_v2() returns 0 but no new OPP is added to the list. This can happen while adding duplicate OPP or if the OPP isn't supported by hardware. Because of this the count variable will contain the number of OPP nodes in the table in device tree but not necessarily the ones that are actually added. As this count value is what is checked to determine if there are any valid OPPs, if a platform has an operating-points-v2 table with all OPP nodes containing opp-supported-hw values that are not currently supported, then _of_add_opp_table_v2 will fail to abort as it should due to an empty table. Additionally, since commit 3ba98324e81a ("PM / OPP: Get performance state using genpd helper"), the same count variable is compared against the number of OPPs containing performance states and requires that either all or none have pstates set, however in the case of any opp table that has any entries that do not get added by _opp_add_static_v2 due to incompatible opp-supported-hw fields, these numbers will not match and _of_add_opp_table_v2 will incorrectly fail. We need to clearly identify all the three cases (success, failure, unsupported/duplicate OPPs) and then increment count only on success case. Change return type of _opp_add_static_v2() to return the pointer to the newly added OPP instead of an integer. This routine now returns a valid pointer if the OPP is really added, NULL for unsupported or duplicate OPPs, and error value cased as a pointer on errors. Ideally the fixes tag in this commit should point back to the commit that introduced OPP v2 initially, as that's where we started incorrectly accounting for duplicate OPPs: commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings") But it wasn't a real problem until recently as the count was only used to check if any OPPs are added or not. And so this commit points to a rather recent commit where we added more code that depends on the value of "count". Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper") Reported-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 16:13:15 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Populate OPPs from "required-opps" property An earlier commit populated the OPP tables from the "required-opps" property, this commit populates the individual OPPs. This is repeated for each OPP in the OPP table and these populated OPPs will be used by later commits. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-07 14:50:43 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Don't allocate OPP table from _opp_allocate() There is no point in trying to find/allocate the table for every OPP that is added for a device. It would be far more efficient to allocate the table only once and pass its pointer to the routines that add the OPP entry. Locking is removed from _opp_add_static_v2() and _opp_add_v1() now as the callers call them with that lock already held. Call to _remove_opp_table() routine is also removed from _opp_free() now, as opp_table isn't allocated from within _opp_allocate(). This is handled by the routines which created the OPP table in the first place. 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-01-02 14:41:01 +05:30
opp: Fix return in _opp_add_static_v2() Fix sparse warning: drivers/opp/of.c:924 _opp_add_static_v2() warn: passing zero to 'ERR_PTR' For duplicate OPPs 'ret' be set to zero. Fixes: deac8703da5f ("PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-10-08 15:46:52 +08:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Pass OPP table to _of_add_opp_table_v{1|2}() Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar code to get the OPP table and their parent routine also parses the DT to find the OPP table's node pointer. This can be simplified by getting the OPP table in advance and then passing it as argument to these routines. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-12 11:21:17 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Allow opp-level to be set to 0 The DT bindings don't put such a constraint, nor should the kernel. It is perfectly fine for opp-level to be set to 0, if we need to put the performance state votes for a domain for a particular OPP. Reported-by: Stephan Gerhold <stephan@gerhold.net> Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-11 14:56:18 +05:30
PM / OPP: Get performance state using genpd helper 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>
2016-11-18 15:47:46 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Prevent creating multiple OPP tables for devices sharing OPP nodes 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-07 09:01:54 +05:30
opp: Replace list_kref with a local counter A kref or refcount isn't the right tool to be used here for counting number of devices that are sharing the static OPPs created for the OPP table. For example, we are reinitializing the kref again, after it reaches a value of 0 and frees the resources, if the static OPPs get added for the same OPP table structure (as the OPP table structure was never freed). That is messy and very unclear. This patch makes parsed_static_opps an unsigned integer and uses it to count the number of users of the static OPPs. The increment and decrement to parsed_static_opps is done under opp_table->lock now to make sure no races are possible if the OPP table is getting added and removed in parallel (which doesn't happen in practice, but can in theory). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-11 16:35:03 +05:30
OPP: Prevent creating multiple OPP tables for devices sharing OPP nodes 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-07 09:01:54 +05:30
opp: Replace list_kref with a local counter A kref or refcount isn't the right tool to be used here for counting number of devices that are sharing the static OPPs created for the OPP table. For example, we are reinitializing the kref again, after it reaches a value of 0 and frees the resources, if the static OPPs get added for the same OPP table structure (as the OPP table structure was never freed). That is messy and very unclear. This patch makes parsed_static_opps an unsigned integer and uses it to count the number of users of the static OPPs. The increment and decrement to parsed_static_opps is done under opp_table->lock now to make sure no races are possible if the OPP table is getting added and removed in parallel (which doesn't happen in practice, but can in theory). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-11 16:35:03 +05:30
OPP: Prevent creating multiple OPP tables for devices sharing OPP nodes 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-07 09:01:54 +05:30
opp: Replace list_kref with a local counter A kref or refcount isn't the right tool to be used here for counting number of devices that are sharing the static OPPs created for the OPP table. For example, we are reinitializing the kref again, after it reaches a value of 0 and frees the resources, if the static OPPs get added for the same OPP table structure (as the OPP table structure was never freed). That is messy and very unclear. This patch makes parsed_static_opps an unsigned integer and uses it to count the number of users of the static OPPs. The increment and decrement to parsed_static_opps is done under opp_table->lock now to make sure no races are possible if the OPP table is getting added and removed in parallel (which doesn't happen in practice, but can in theory). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-11 16:35:03 +05:30
opp: Reinitialize the list_kref before adding the static OPPs again The list_kref reaches a count of 0 when all the static OPPs are removed, for example when dev_pm_opp_of_cpumask_remove_table() is called, though the actual OPP table may not get freed as it may still be referenced by other parts of the kernel, like from a call to dev_pm_opp_set_supported_hw(). And if we call dev_pm_opp_of_cpumask_add_table() again at this point, we must reinitialize the list_kref otherwise the kernel will hit a WARN() in kref infrastructure for incrementing a kref with value 0. Fixes: 11e1a1648298 ("opp: Don't decrement uninitialized list_kref") Reported-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-10-18 14:11:58 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Pass OPP table to _of_add_opp_table_v{1|2}() Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar code to get the OPP table and their parent routine also parses the DT to find the OPP table's node pointer. This can be simplified by getting the OPP table in advance and then passing it as argument to these routines. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-12 11:21:17 +05:30
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added Currently the _of_add_opp_table_v2 call loops through the OPP nodes in the operating-points-v2 table in the device tree and calls _opp_add_static_v2 for each to add them to the table. It counts each iteration through this loop as an added OPP, however there are cases where _opp_add_static_v2() returns 0 but no new OPP is added to the list. This can happen while adding duplicate OPP or if the OPP isn't supported by hardware. Because of this the count variable will contain the number of OPP nodes in the table in device tree but not necessarily the ones that are actually added. As this count value is what is checked to determine if there are any valid OPPs, if a platform has an operating-points-v2 table with all OPP nodes containing opp-supported-hw values that are not currently supported, then _of_add_opp_table_v2 will fail to abort as it should due to an empty table. Additionally, since commit 3ba98324e81a ("PM / OPP: Get performance state using genpd helper"), the same count variable is compared against the number of OPPs containing performance states and requires that either all or none have pstates set, however in the case of any opp table that has any entries that do not get added by _opp_add_static_v2 due to incompatible opp-supported-hw fields, these numbers will not match and _of_add_opp_table_v2 will incorrectly fail. We need to clearly identify all the three cases (success, failure, unsupported/duplicate OPPs) and then increment count only on success case. Change return type of _opp_add_static_v2() to return the pointer to the newly added OPP instead of an integer. This routine now returns a valid pointer if the OPP is really added, NULL for unsupported or duplicate OPPs, and error value cased as a pointer on errors. Ideally the fixes tag in this commit should point back to the commit that introduced OPP v2 initially, as that's where we started incorrectly accounting for duplicate OPPs: commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings") But it wasn't a real problem until recently as the count was only used to check if any OPPs are added or not. And so this commit points to a rather recent commit where we added more code that depends on the value of "count". Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper") Reported-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 16:13:15 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Add missing of_node_put(np) The for_each_available_child_of_node() loop in _of_add_opp_table_v2() doesn't drop the reference to "np" on errors. Fix that. Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings) Cc: 4.3+ <stable@vger.kernel.org> # 4.3+ Signed-off-by: Tobias Jordan <Tobias.Jordan@elektrobit.com> [ VK: Improved commit log. ] 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-04 11:35:03 +05:30
opp: Replace list_kref with a local counter A kref or refcount isn't the right tool to be used here for counting number of devices that are sharing the static OPPs created for the OPP table. For example, we are reinitializing the kref again, after it reaches a value of 0 and frees the resources, if the static OPPs get added for the same OPP table structure (as the OPP table structure was never freed). That is messy and very unclear. This patch makes parsed_static_opps an unsigned integer and uses it to count the number of users of the static OPPs. The increment and decrement to parsed_static_opps is done under opp_table->lock now to make sure no races are possible if the OPP table is getting added and removed in parallel (which doesn't happen in practice, but can in theory). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-11 16:35:03 +05:30
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added Currently the _of_add_opp_table_v2 call loops through the OPP nodes in the operating-points-v2 table in the device tree and calls _opp_add_static_v2 for each to add them to the table. It counts each iteration through this loop as an added OPP, however there are cases where _opp_add_static_v2() returns 0 but no new OPP is added to the list. This can happen while adding duplicate OPP or if the OPP isn't supported by hardware. Because of this the count variable will contain the number of OPP nodes in the table in device tree but not necessarily the ones that are actually added. As this count value is what is checked to determine if there are any valid OPPs, if a platform has an operating-points-v2 table with all OPP nodes containing opp-supported-hw values that are not currently supported, then _of_add_opp_table_v2 will fail to abort as it should due to an empty table. Additionally, since commit 3ba98324e81a ("PM / OPP: Get performance state using genpd helper"), the same count variable is compared against the number of OPPs containing performance states and requires that either all or none have pstates set, however in the case of any opp table that has any entries that do not get added by _opp_add_static_v2 due to incompatible opp-supported-hw fields, these numbers will not match and _of_add_opp_table_v2 will incorrectly fail. We need to clearly identify all the three cases (success, failure, unsupported/duplicate OPPs) and then increment count only on success case. Change return type of _opp_add_static_v2() to return the pointer to the newly added OPP instead of an integer. This routine now returns a valid pointer if the OPP is really added, NULL for unsupported or duplicate OPPs, and error value cased as a pointer on errors. Ideally the fixes tag in this commit should point back to the commit that introduced OPP v2 initially, as that's where we started incorrectly accounting for duplicate OPPs: commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings") But it wasn't a real problem until recently as the count was only used to check if any OPPs are added or not. And so this commit points to a rather recent commit where we added more code that depends on the value of "count". Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper") Reported-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 16:13:15 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: remove WARN when no valid OPPs remain This WARN can be triggered per-core and the stack trace is not useful. Replace it with plain dev_err(). Fix a comment while at it. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-07-26 10:30:56 +02:00
opp: Free static OPPs on errors while adding them The static OPPs aren't getting freed properly, if errors occur while adding them. Fix that by calling _put_opp_list_kref() and putting their reference on failures. Fixes: 11e1a1648298 ("opp: Don't decrement uninitialized list_kref") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-18 14:41:07 +05:30
opp: Replace list_kref with a local counter A kref or refcount isn't the right tool to be used here for counting number of devices that are sharing the static OPPs created for the OPP table. For example, we are reinitializing the kref again, after it reaches a value of 0 and frees the resources, if the static OPPs get added for the same OPP table structure (as the OPP table structure was never freed). That is messy and very unclear. This patch makes parsed_static_opps an unsigned integer and uses it to count the number of users of the static OPPs. The increment and decrement to parsed_static_opps is done under opp_table->lock now to make sure no races are possible if the OPP table is getting added and removed in parallel (which doesn't happen in practice, but can in theory). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-11 16:35:03 +05:30
opp: Free static OPPs on errors while adding them The static OPPs aren't getting freed properly, if errors occur while adding them. Fix that by calling _put_opp_list_kref() and putting their reference on failures. Fixes: 11e1a1648298 ("opp: Don't decrement uninitialized list_kref") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-18 14:41:07 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Allow opp-level to be set to 0 The DT bindings don't put such a constraint, nor should the kernel. It is perfectly fine for opp-level to be set to 0, if we need to put the performance state votes for a domain for a particular OPP. Reported-by: Stephan Gerhold <stephan@gerhold.net> Tested-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-11 14:56:18 +05:30
PM / OPP: Get performance state using genpd helper 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>
2016-11-18 15:47:46 +05:30
opp: Allow lazy-linking of required-opps The OPP core currently requires the required opp tables to be available before the dependent OPP table is added, as it needs to create links from the dependent OPP table to the required ones. This may not be convenient for all the platforms though, as this requires strict ordering for probing the drivers. This patch allows lazy-linking of the required-opps. The OPP tables for which the required-opp-tables aren't available at the time of their initialization, are added to a special list of OPP tables: lazy_opp_tables. Later on, whenever a new OPP table is registered with the OPP core, we check if it is required by an OPP table in the pending list; if yes, then we complete the linking then and there. An OPP table is marked unusable until the time all its required-opp tables are available. And if lazy-linking fails for an OPP table, the OPP core disables all of its OPPs to make sure no one can use them. Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-25 13:57:58 +05:30
OPP: Use a single mechanism to free the OPP table 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-12 12:35:19 +05:30
opp: Free static OPPs on errors while adding them The static OPPs aren't getting freed properly, if errors occur while adding them. Fix that by calling _put_opp_list_kref() and putting their reference on failures. Fixes: 11e1a1648298 ("opp: Don't decrement uninitialized list_kref") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-18 14:41:07 +05:30
opp: Replace list_kref with a local counter A kref or refcount isn't the right tool to be used here for counting number of devices that are sharing the static OPPs created for the OPP table. For example, we are reinitializing the kref again, after it reaches a value of 0 and frees the resources, if the static OPPs get added for the same OPP table structure (as the OPP table structure was never freed). That is messy and very unclear. This patch makes parsed_static_opps an unsigned integer and uses it to count the number of users of the static OPPs. The increment and decrement to parsed_static_opps is done under opp_table->lock now to make sure no races are possible if the OPP table is getting added and removed in parallel (which doesn't happen in practice, but can in theory). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-11 16:35:03 +05:30
opp: Free static OPPs on errors while adding them The static OPPs aren't getting freed properly, if errors occur while adding them. Fix that by calling _put_opp_list_kref() and putting their reference on failures. Fixes: 11e1a1648298 ("opp: Don't decrement uninitialized list_kref") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-11-18 14:41:07 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Pass OPP table to _of_add_opp_table_v{1|2}() Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar code to get the OPP table and their parent routine also parses the DT to find the OPP table's node pointer. This can be simplified by getting the OPP table in advance and then passing it as argument to these routines. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-12 11:21:17 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Don't allocate OPP table from _opp_allocate() There is no point in trying to find/allocate the table for every OPP that is added for a device. It would be far more efficient to allocate the table only once and pass its pointer to the routines that add the OPP entry. Locking is removed from _opp_add_static_v2() and _opp_add_v1() now as the callers call them with that lock already held. Call to _remove_opp_table() routine is also removed from _opp_free() now, as opp_table isn't allocated from within _opp_allocate(). This is handled by the routines which created the OPP table in the first place. 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-01-02 14:41:01 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1() Until now for V1 OPP bindings we used to call dev_pm_opp_of_cpumask_add_table() first and then dev_pm_opp_set_sharing_cpus() in the cpufreq-dt driver. A later patch will though update the cpufreq-dt driver to optimize the code a bit and we will call dev_pm_opp_set_sharing_cpus() first followed by dev_pm_opp_of_cpumask_add_table(), which doesn't work well today as it tries to re parse the OPP entries. This should work nevertheless for V1 bindings as the same works for V2 bindings. Adapt the same approach from V2 bindings and fix this. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-01 15:07:09 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1() Until now for V1 OPP bindings we used to call dev_pm_opp_of_cpumask_add_table() first and then dev_pm_opp_set_sharing_cpus() in the cpufreq-dt driver. A later patch will though update the cpufreq-dt driver to optimize the code a bit and we will call dev_pm_opp_set_sharing_cpus() first followed by dev_pm_opp_of_cpumask_add_table(), which doesn't work well today as it tries to re parse the OPP entries. This should work nevertheless for V1 bindings as the same works for V2 bindings. Adapt the same approach from V2 bindings and fix this. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-01 15:07:09 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1() Until now for V1 OPP bindings we used to call dev_pm_opp_of_cpumask_add_table() first and then dev_pm_opp_set_sharing_cpus() in the cpufreq-dt driver. A later patch will though update the cpufreq-dt driver to optimize the code a bit and we will call dev_pm_opp_set_sharing_cpus() first followed by dev_pm_opp_of_cpumask_add_table(), which doesn't work well today as it tries to re parse the OPP entries. This should work nevertheless for V1 bindings as the same works for V2 bindings. Adapt the same approach from V2 bindings and fix this. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-01 15:07:09 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Don't allocate OPP table from _opp_allocate() There is no point in trying to find/allocate the table for every OPP that is added for a device. It would be far more efficient to allocate the table only once and pass its pointer to the routines that add the OPP entry. Locking is removed from _opp_add_static_v2() and _opp_add_v1() now as the callers call them with that lock already held. Call to _remove_opp_table() routine is also removed from _opp_free() now, as opp_table isn't allocated from within _opp_allocate(). This is handled by the routines which created the OPP table in the first place. 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-01-02 14:41:01 +05:30
PM / OPP: Error out on failing to add static OPPs for v1 bindings The code adding static OPPs for V2 bindings already does so. Make the V1 bindings specific code behave the same. 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-01-02 14:40:58 +05:30
opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1() Until now for V1 OPP bindings we used to call dev_pm_opp_of_cpumask_add_table() first and then dev_pm_opp_set_sharing_cpus() in the cpufreq-dt driver. A later patch will though update the cpufreq-dt driver to optimize the code a bit and we will call dev_pm_opp_set_sharing_cpus() first followed by dev_pm_opp_of_cpumask_add_table(), which doesn't work well today as it tries to re parse the OPP entries. This should work nevertheless for V1 bindings as the same works for V2 bindings. Adapt the same approach from V2 bindings and fix this. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-01 15:07:09 +05:30
PM / OPP: Error out on failing to add static OPPs for v1 bindings The code adding static OPPs for V2 bindings already does so. Make the V1 bindings specific code behave the same. 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-01-02 14:40:58 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Don't always remove static OPPs in _of_add_opp_table_v1() The patch missed returning 0 early in case of success and hence the static OPPs got removed by mistake. Fix it. Fixes: 90d46d71cce2 ("opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1()") Reported-by: Aisheng Dong <aisheng.dong@nxp.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dong Aisheng <aisheng.dong@nxp.com>
2020-10-14 09:56:28 +05:30
opp: Handle multiple calls for same OPP table in _of_add_opp_table_v1() Until now for V1 OPP bindings we used to call dev_pm_opp_of_cpumask_add_table() first and then dev_pm_opp_set_sharing_cpus() in the cpufreq-dt driver. A later patch will though update the cpufreq-dt driver to optimize the code a bit and we will call dev_pm_opp_set_sharing_cpus() first followed by dev_pm_opp_of_cpumask_add_table(), which doesn't work well today as it tries to re parse the OPP entries. This should work nevertheless for V1 bindings as the same works for V2 bindings. Adapt the same approach from V2 bindings and fix this. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-09-01 15:07:09 +05:30
PM / OPP: Don't allocate OPP table from _opp_allocate() There is no point in trying to find/allocate the table for every OPP that is added for a device. It would be far more efficient to allocate the table only once and pass its pointer to the routines that add the OPP entry. Locking is removed from _opp_add_static_v2() and _opp_add_v1() now as the callers call them with that lock already held. Call to _remove_opp_table() routine is also removed from _opp_free() now, as opp_table isn't allocated from within _opp_allocate(). This is handled by the routines which created the OPP table in the first place. 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-01-02 14:41:01 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Remove dev{m}_pm_opp_of_add_table_noclk() Remove the now unused variants and the now unnecessary "getclk" parameter from few routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-05 09:41:56 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Pass OPP table to _of_add_opp_table_v{1|2}() Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar code to get the OPP table and their parent routine also parses the DT to find the OPP table's node pointer. This can be simplified by getting the OPP table in advance and then passing it as argument to these routines. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-12 11:21:17 +05:30
opp: Create _of_add_table_indexed() to reduce code duplication The implementation of dev_pm_opp_of_add_table() and dev_pm_opp_of_add_table_indexed() are almost identical. Create _of_add_table_indexed() to reduce code redundancy. Also remove the duplication of the doc style comments by referring to dev_pm_opp_of_add_table() from dev_pm_opp_of_add_table_indexed(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dmitry Osipenko <digetx@gmail.com>
2021-01-27 12:45:56 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Create _of_add_table_indexed() to reduce code duplication The implementation of dev_pm_opp_of_add_table() and dev_pm_opp_of_add_table_indexed() are almost identical. Create _of_add_table_indexed() to reduce code redundancy. Also remove the duplication of the doc style comments by referring to dev_pm_opp_of_add_table() from dev_pm_opp_of_add_table_indexed(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dmitry Osipenko <digetx@gmail.com>
2021-01-27 12:45:56 +05:30
OPP: Remove dev{m}_pm_opp_of_add_table_noclk() Remove the now unused variants and the now unnecessary "getclk" parameter from few routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-05 09:41:56 +05:30
opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER The OPP core manages various resources, e.g. clocks or interconnect paths. These resources are looked up when the OPP table is allocated once dev_pm_opp_get_opp_table() is called the first time (either directly or indirectly through one of the many helper functions). At this point, the resources may not be available yet, i.e. looking them up will result in -EPROBE_DEFER. Unfortunately, dev_pm_opp_get_opp_table() is currently unable to propagate this error code since it only returns the allocated OPP table or NULL. This means that all consumers of the OPP core are required to make sure that all necessary resources are available. Usually this happens by requesting them, checking the result and releasing them immediately after. For example, we have added "dev_pm_opp_of_find_icc_paths(dev, NULL)" to several drivers now just to make sure the interconnect providers are ready before the OPP table is allocated. If this call is missing, the OPP core will only warn about this and then attempt to continue without interconnect. This will eventually fail horribly, e.g.: cpu cpu0: _allocate_opp_table: Error finding interconnect paths: -517 ... later ... of: _read_bw: Mismatch between opp-peak-kBps and paths (1 0) cpu cpu0: _opp_add_static_v2: opp key field not found cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22 This example happens when trying to use interconnects for a CPU OPP table together with qcom-cpufreq-nvmem.c. qcom-cpufreq-nvmem calls dev_pm_opp_set_supported_hw(), which ends up allocating the OPP table early. To fix the problem with the current approach we would need to add yet another call to dev_pm_opp_of_find_icc_paths(dev, NULL). But actually qcom-cpufreq-nvmem.c has nothing to do with interconnects... This commit attempts to make this more robust by allowing dev_pm_opp_get_opp_table() to return an error pointer. Fixing all the usages is trivial because the function is usually used indirectly through another helper (e.g. dev_pm_opp_set_supported_hw() above). These other helpers already return an error pointer. The example above then works correctly because set_supported_hw() will return -EPROBE_DEFER, and qcom-cpufreq-nvmem.c already propagates that error. It should also be possible to remove the remaining usages of "dev_pm_opp_of_find_icc_paths(dev, NULL)" from other drivers as well. Note that this commit currently only handles -EPROBE_DEFER for the clock/interconnects within _allocate_opp_table(). Other errors are just ignored as before. Eventually those should be propagated as well. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> [ Viresh: skip checking return value of dev_pm_opp_get_opp_table() for EPROBE_DEFER in domain.c, fix NULL return value and reorder code a bit in core.c, and update exynos-asv.c ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-07-27 11:30:46 +02:00
OPP: Pass OPP table to _of_add_opp_table_v{1|2}() Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar code to get the OPP table and their parent routine also parses the DT to find the OPP table's node pointer. This can be simplified by getting the OPP table in advance and then passing it as argument to these routines. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-12 11:21:17 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Pass OPP table to _of_add_opp_table_v{1|2}() Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar code to get the OPP table and their parent routine also parses the DT to find the OPP table's node pointer. This can be simplified by getting the OPP table in advance and then passing it as argument to these routines. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-12 11:21:17 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Pass OPP table to _of_add_opp_table_v{1|2}() Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar code to get the OPP table and their parent routine also parses the DT to find the OPP table's node pointer. This can be simplified by getting the OPP table in advance and then passing it as argument to these routines. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-12 11:21:17 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Pass OPP table to _of_add_opp_table_v{1|2}() Both _of_add_opp_table_v1() and _of_add_opp_table_v2() contain similar code to get the OPP table and their parent routine also parses the DT to find the OPP table's node pointer. This can be simplified by getting the OPP table in advance and then passing it as argument to these routines. Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-12 11:21:17 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
opp: Add devres wrapper for dev_pm_opp_of_add_table Add devres wrapper for dev_pm_opp_of_add_table() to simplify drivers code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-03-14 19:33:57 +03:00
OPP: Remove dev{m}_pm_opp_of_add_table_noclk() Remove the now unused variants and the now unnecessary "getclk" parameter from few routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-05 09:41:56 +05:30
opp: Add more resource-managed variants of dev_pm_opp_of_add_table() Add resource-managed variants of dev_pm_opp_of_add_table_indexed() and dev_pm_opp_of_add_table_noclk(), allowing drivers to remove boilerplate code. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> [ Viresh: Added underscore to devm_of_add_table_indexed() ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-09-20 20:22:46 +03:00
OPP: Remove dev{m}_pm_opp_of_add_table_noclk() Remove the now unused variants and the now unnecessary "getclk" parameter from few routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-05 09:41:56 +05:30
opp: Add more resource-managed variants of dev_pm_opp_of_add_table() Add resource-managed variants of dev_pm_opp_of_add_table_indexed() and dev_pm_opp_of_add_table_noclk(), allowing drivers to remove boilerplate code. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> [ Viresh: Added underscore to devm_of_add_table_indexed() ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-09-20 20:22:46 +03:00
opp: Add devres wrapper for dev_pm_opp_of_add_table Add devres wrapper for dev_pm_opp_of_add_table() to simplify drivers code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-03-14 19:33:57 +03:00
OPP: Remove dev{m}_pm_opp_of_add_table_noclk() Remove the now unused variants and the now unnecessary "getclk" parameter from few routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-05 09:41:56 +05:30
opp: Add devres wrapper for dev_pm_opp_of_add_table Add devres wrapper for dev_pm_opp_of_add_table() to simplify drivers code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-03-14 19:33:57 +03:00
PM / OPP: Implement dev_pm_opp_of_add_table_indexed() The "operating-points-v2" property can contain a list of phandles now, specifically for the power domain providers that provide multiple domains. Add support to parse that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-04-26 10:45:46 +05:30
opp: Create _of_add_table_indexed() to reduce code duplication The implementation of dev_pm_opp_of_add_table() and dev_pm_opp_of_add_table_indexed() are almost identical. Create _of_add_table_indexed() to reduce code redundancy. Also remove the duplication of the doc style comments by referring to dev_pm_opp_of_add_table() from dev_pm_opp_of_add_table_indexed(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dmitry Osipenko <digetx@gmail.com>
2021-01-27 12:45:56 +05:30
PM / OPP: Implement dev_pm_opp_of_add_table_indexed() The "operating-points-v2" property can contain a list of phandles now, specifically for the power domain providers that provide multiple domains. Add support to parse that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-04-26 10:45:46 +05:30
opp: Create _of_add_table_indexed() to reduce code duplication The implementation of dev_pm_opp_of_add_table() and dev_pm_opp_of_add_table_indexed() are almost identical. Create _of_add_table_indexed() to reduce code redundancy. Also remove the duplication of the doc style comments by referring to dev_pm_opp_of_add_table() from dev_pm_opp_of_add_table_indexed(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dmitry Osipenko <digetx@gmail.com>
2021-01-27 12:45:56 +05:30
PM / OPP: Implement dev_pm_opp_of_add_table_indexed() The "operating-points-v2" property can contain a list of phandles now, specifically for the power domain providers that provide multiple domains. Add support to parse that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-04-26 10:45:46 +05:30
opp: Create _of_add_table_indexed() to reduce code duplication The implementation of dev_pm_opp_of_add_table() and dev_pm_opp_of_add_table_indexed() are almost identical. Create _of_add_table_indexed() to reduce code redundancy. Also remove the duplication of the doc style comments by referring to dev_pm_opp_of_add_table() from dev_pm_opp_of_add_table_indexed(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dmitry Osipenko <digetx@gmail.com>
2021-01-27 12:45:56 +05:30
PM / OPP: Implement dev_pm_opp_of_add_table_indexed() The "operating-points-v2" property can contain a list of phandles now, specifically for the power domain providers that provide multiple domains. Add support to parse that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-04-26 10:45:46 +05:30
OPP: Remove dev{m}_pm_opp_of_add_table_noclk() Remove the now unused variants and the now unnecessary "getclk" parameter from few routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-05 09:41:56 +05:30
opp: Create _of_add_table_indexed() to reduce code duplication The implementation of dev_pm_opp_of_add_table() and dev_pm_opp_of_add_table_indexed() are almost identical. Create _of_add_table_indexed() to reduce code redundancy. Also remove the duplication of the doc style comments by referring to dev_pm_opp_of_add_table() from dev_pm_opp_of_add_table_indexed(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dmitry Osipenko <digetx@gmail.com>
2021-01-27 12:45:56 +05:30
PM / OPP: Implement dev_pm_opp_of_add_table_indexed() The "operating-points-v2" property can contain a list of phandles now, specifically for the power domain providers that provide multiple domains. Add support to parse that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-04-26 10:45:46 +05:30
opp: Create _of_add_table_indexed() to reduce code duplication The implementation of dev_pm_opp_of_add_table() and dev_pm_opp_of_add_table_indexed() are almost identical. Create _of_add_table_indexed() to reduce code redundancy. Also remove the duplication of the doc style comments by referring to dev_pm_opp_of_add_table() from dev_pm_opp_of_add_table_indexed(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dmitry Osipenko <digetx@gmail.com>
2021-01-27 12:45:56 +05:30
OPP: Remove dev{m}_pm_opp_of_add_table_noclk() Remove the now unused variants and the now unnecessary "getclk" parameter from few routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-05 09:41:56 +05:30
PM / OPP: Implement dev_pm_opp_of_add_table_indexed() The "operating-points-v2" property can contain a list of phandles now, specifically for the power domain providers that provide multiple domains. Add support to parse that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-04-26 10:45:46 +05:30
opp: Add more resource-managed variants of dev_pm_opp_of_add_table() Add resource-managed variants of dev_pm_opp_of_add_table_indexed() and dev_pm_opp_of_add_table_noclk(), allowing drivers to remove boilerplate code. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> [ Viresh: Added underscore to devm_of_add_table_indexed() ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-09-20 20:22:46 +03:00
OPP: Remove dev{m}_pm_opp_of_add_table_noclk() Remove the now unused variants and the now unnecessary "getclk" parameter from few routines. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-07-05 09:41:56 +05:30
opp: Add more resource-managed variants of dev_pm_opp_of_add_table() Add resource-managed variants of dev_pm_opp_of_add_table_indexed() and dev_pm_opp_of_add_table_noclk(), allowing drivers to remove boilerplate code. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> [ Viresh: Added underscore to devm_of_add_table_indexed() ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2021-09-20 20:22:46 +03:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table() 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: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-09-13 13:14:36 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Improve error handling in dev_pm_opp_of_cpumask_add_table() The error handling wasn't appropriate in dev_pm_opp_of_cpumask_add_table(). For example it returns 0 on success and also for the case where cpumask is empty or cpu_device wasn't found for any of the CPUs. It should really return error on such cases, so that the callers can be aware of the outcome. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 15:12:06 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Improve error handling in dev_pm_opp_of_cpumask_add_table() The error handling wasn't appropriate in dev_pm_opp_of_cpumask_add_table(). For example it returns 0 on success and also for the case where cpumask is empty or cpu_device wasn't found for any of the CPUs. It should really return error on such cases, so that the callers can be aware of the outcome. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 15:12:06 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Improve error handling in dev_pm_opp_of_cpumask_add_table() The error handling wasn't appropriate in dev_pm_opp_of_cpumask_add_table(). For example it returns 0 on success and also for the case where cpumask is empty or cpu_device wasn't found for any of the CPUs. It should really return error on such cases, so that the callers can be aware of the outcome. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 15:12:06 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: OF: Use pr_debug() instead of pr_err() while adding OPP table Some platforms add the OPPs dynamically from platform specific drivers instead of getting them statically from DT. The cpufreq-dt driver already ignores the return value of dev_pm_opp_of_cpumask_add_table() to not error out for such cases, but we still end up printing error message from that routine. That's not nice. Convert the print message to use pr_debug() instead. Reported-by: Mason <slash.tmp@free.fr> 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-07-12 09:21:49 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Improve error handling in dev_pm_opp_of_cpumask_add_table() The error handling wasn't appropriate in dev_pm_opp_of_cpumask_add_table(). For example it returns 0 on success and also for the case where cpumask is empty or cpu_device wasn't found for any of the CPUs. It should really return error on such cases, so that the callers can be aware of the outcome. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 15:12:06 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
OPP: Improve error handling in dev_pm_opp_of_cpumask_add_table() The error handling wasn't appropriate in dev_pm_opp_of_cpumask_add_table(). For example it returns 0 on success and also for the case where cpumask is empty or cpu_device wasn't found for any of the CPUs. It should really return error on such cases, so that the callers can be aware of the outcome. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 15:12:06 +05:30
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Fix get sharing CPUs when hotplug is used We fail dev_pm_opp_of_get_sharing_cpus() when possible CPU device does not exist. This can happen on platforms where not all possible CPUs are available at start up ie. hotplugged out. The CPU device is not registered in the system so we are not able to check struct device to set the sharing CPUs bitmask properly. Example (real use case): 2 physical MIPS cores, 4 VPE, cpu0/2 run Linux and cpu1/3 are not available for Linux at boot up. cpufreq-dt driver + OPP v2 fail to register opp_table due to the fact there is no struct device for cpu1 (remains offline at bootup). To solve the bug, stop using device struct to check device_node. Instead get CPU device_node directly from device tree with of_get_cpu_node(). Signed-off-by: Waldemar Rymarkiewicz <waldemarx.rymarkiewicz@intel.com> Acked-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-07-27 12:01:17 +02:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API Rename _of_get_opp_desc_node to dev_pm_opp_of_get_opp_desc_node and add it to include/linux/pm_opp.h to allow other drivers, such as platform OPP and cpufreq drivers, to make use of it. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-03 11:29:26 -06:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: fix debug/error messages in dev_pm_opp_of_get_sharing_cpus() These log messages are wrong because _of_get_opp_desc_node() returns an operating-points-v2 node. Commit a6eed752f5fb ("PM / OPP: passing NULL to PTR_ERR()") fixed static checker warnings, and reworded the messages at the same time (but the latter was not mentioned in the git-log). Restore the correct messages. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-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>
2016-10-20 16:12:49 +09:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: add missing of_node_put() for of_get_cpu_node() Commit 762792913f8c (PM / OPP: Fix get sharing CPUs when hotplug is used) moved away from using cpu_dev->of_node because of some limitations. However, commit 7467c9d95989 (of: return of_get_cpu_node from of_cpu_device_node_get if CPUs are not registered) added support to fall back to of_get_cpu_node() if called if CPUs are not registered yet. Add the missing of_node_put() for the CPU device nodes. Also go back to using of_cpu_device_node_get() in dev_pm_opp_of_get_sharing_cpus() to avoid scanning the device tree again. Acked-by: Viresh Kumar <vireshk@kernel.org> Fixes: 762792913f8c (PM / OPP: Fix get sharing CPUs when hotplug is used) Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-12 11:32:23 +01:00
PM / OPP: Fix get sharing CPUs when hotplug is used We fail dev_pm_opp_of_get_sharing_cpus() when possible CPU device does not exist. This can happen on platforms where not all possible CPUs are available at start up ie. hotplugged out. The CPU device is not registered in the system so we are not able to check struct device to set the sharing CPUs bitmask properly. Example (real use case): 2 physical MIPS cores, 4 VPE, cpu0/2 run Linux and cpu1/3 are not available for Linux at boot up. cpufreq-dt driver + OPP v2 fail to register opp_table due to the fact there is no struct device for cpu1 (remains offline at bootup). To solve the bug, stop using device struct to check device_node. Instead get CPU device_node directly from device tree with of_get_cpu_node(). Signed-off-by: Waldemar Rymarkiewicz <waldemarx.rymarkiewicz@intel.com> Acked-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-07-27 12:01:17 +02:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Fix get sharing CPUs when hotplug is used We fail dev_pm_opp_of_get_sharing_cpus() when possible CPU device does not exist. This can happen on platforms where not all possible CPUs are available at start up ie. hotplugged out. The CPU device is not registered in the system so we are not able to check struct device to set the sharing CPUs bitmask properly. Example (real use case): 2 physical MIPS cores, 4 VPE, cpu0/2 run Linux and cpu1/3 are not available for Linux at boot up. cpufreq-dt driver + OPP v2 fail to register opp_table due to the fact there is no struct device for cpu1 (remains offline at bootup). To solve the bug, stop using device struct to check device_node. Instead get CPU device_node directly from device tree with of_get_cpu_node(). Signed-off-by: Waldemar Rymarkiewicz <waldemarx.rymarkiewicz@intel.com> Acked-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-07-27 12:01:17 +02:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Implement dev_pm_opp_of_add_table_indexed() The "operating-points-v2" property can contain a list of phandles now, specifically for the power domain providers that provide multiple domains. Add support to parse that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-04-26 10:45:46 +05:30
PM / OPP: add missing of_node_put() for of_get_cpu_node() Commit 762792913f8c (PM / OPP: Fix get sharing CPUs when hotplug is used) moved away from using cpu_dev->of_node because of some limitations. However, commit 7467c9d95989 (of: return of_get_cpu_node from of_cpu_device_node_get if CPUs are not registered) added support to fall back to of_get_cpu_node() if called if CPUs are not registered yet. Add the missing of_node_put() for the CPU device nodes. Also go back to using of_cpu_device_node_get() in dev_pm_opp_of_get_sharing_cpus() to avoid scanning the device tree again. Acked-by: Viresh Kumar <vireshk@kernel.org> Fixes: 762792913f8c (PM / OPP: Fix get sharing CPUs when hotplug is used) Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-12 11:32:23 +01:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Fix get sharing CPUs when hotplug is used We fail dev_pm_opp_of_get_sharing_cpus() when possible CPU device does not exist. This can happen on platforms where not all possible CPUs are available at start up ie. hotplugged out. The CPU device is not registered in the system so we are not able to check struct device to set the sharing CPUs bitmask properly. Example (real use case): 2 physical MIPS cores, 4 VPE, cpu0/2 run Linux and cpu1/3 are not available for Linux at boot up. cpufreq-dt driver + OPP v2 fail to register opp_table due to the fact there is no struct device for cpu1 (remains offline at bootup). To solve the bug, stop using device struct to check device_node. Instead get CPU device_node directly from device tree with of_get_cpu_node(). Signed-off-by: Waldemar Rymarkiewicz <waldemarx.rymarkiewicz@intel.com> Acked-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-07-27 12:01:17 +02:00
PM / OPP: Move CONFIG_OF dependent code in a separate file Recently, a few issues were noticed in the code where CONFIG_OF wasn't consistently used for many routines. The core file is big enough now and ifdef hackery makes it less readable. Move OF-specific code to another file and compile that only if CONFIG_OF is enabled. Compile-tested: - For ARM (exynos) with CONFIG_OF enabled - For X86 with CONFIG_OF disabled (have to enable CONFIG_PM_OPP separately) No functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-05 16:20:33 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Don't return 0 on error from of_get_required_opp_performance_state() of_get_required_opp_performance_state() returns 0 on errors currently and a positive performance state otherwise. Since 0 is a valid performance state (representing off), it would be better if this routine returns negative values on error. That will also make it behave similar to dev_pm_opp_xlate_performance_state(), which also returns performance states and returns negative values on error. Change the return type of the function to "int" in order to return negative values. This doesn't have any users for now and so no other part of the kernel will be impacted with this change. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-12-14 15:20:56 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Don't return 0 on error from of_get_required_opp_performance_state() of_get_required_opp_performance_state() returns 0 on errors currently and a positive performance state otherwise. Since 0 is a valid performance state (representing off), it would be better if this routine returns negative values on error. That will also make it behave similar to dev_pm_opp_xlate_performance_state(), which also returns performance states and returns negative values on error. Change the return type of the function to "int" in order to return negative values. This doesn't have any users for now and so no other part of the kernel will be impacted with this change. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-12-14 15:20:56 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Don't return 0 on error from of_get_required_opp_performance_state() of_get_required_opp_performance_state() returns 0 on errors currently and a positive performance state otherwise. Since 0 is a valid performance state (representing off), it would be better if this routine returns negative values on error. That will also make it behave similar to dev_pm_opp_xlate_performance_state(), which also returns performance states and returns negative values on error. Change the return type of the function to "int" in order to return negative values. This doesn't have any users for now and so no other part of the kernel will be impacted with this change. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-12-14 15:20:56 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
opp: Don't print an error if required-opps is missing The 'required-opps' property is considered optional, hence remove the pr_err() in of_parse_required_opp() when we find the property is missing. While at it, also fix the return value of of_get_required_opp_performance_state() when of_parse_required_opp() fails, return a -ENODEV instead of the -EINVAL. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-08-12 16:57:20 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement of_dev_pm_opp_find_required_opp() 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>
2017-11-29 15:18:36 +05:30
OPP: Rename and relocate of_genpd_opp_to_performance_state() The OPP core already has the performance state values for each of the genpd's OPPs and there is no need to call the genpd callback again to get the performance state for the case where the end device doesn't have an OPP table and has the "required-opps" property directly in its node. This commit renames of_genpd_opp_to_performance_state() as of_get_required_opp_performance_state() and moves it to the OPP core, as it is all about OPP stuff now. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-27 16:29:50 +05:30
PM / OPP: Implement dev_pm_opp_get_of_node() This adds a new helper to let the power domain drivers to access opp->np, so that they can read platform specific properties from the node. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2018-01-12 10:03:45 +05:30
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: Add support of "opp-microwatt" for EM registration The Energy Model (EM) can be created based on DT entry: 'dynamic-power-coefficient'. It's a 'simple' EM which is limited to the dynamic power. It has to fit into the math formula which requires also information about voltage. Some of the platforms don't expose voltage information, thus it's not possible to use EM registration using DT. This patch aims to fix it. It introduces new implementation of the EM registration callback. The new mechanism relies on the new OPP feature allowing to get power (which is coming from "opp-microwatt" DT property) expressed in micro-Watts. The patch also opens new opportunity to better support platforms, which have a decent static power. It allows to register the EM based on real power measurements which models total power (static + dynamic), so better reflects real HW. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:16 +00:00
PM: EM: convert power field to micro-Watts precision and align drivers The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-07-07 08:15:52 +01:00
OPP: Add support of "opp-microwatt" for EM registration The Energy Model (EM) can be created based on DT entry: 'dynamic-power-coefficient'. It's a 'simple' EM which is limited to the dynamic power. It has to fit into the math formula which requires also information about voltage. Some of the platforms don't expose voltage information, thus it's not possible to use EM registration using DT. This patch aims to fix it. It introduces new implementation of the EM registration callback. The new mechanism relies on the new OPP feature allowing to get power (which is coming from "opp-microwatt" DT property) expressed in micro-Watts. The patch also opens new opportunity to better support platforms, which have a decent static power. It allows to register the EM based on real power measurements which models total power (static + dynamic), so better reflects real HW. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:16 +00:00
PM: EM: convert power field to micro-Watts precision and align drivers The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-07-07 08:15:52 +01:00
OPP: Add support of "opp-microwatt" for EM registration The Energy Model (EM) can be created based on DT entry: 'dynamic-power-coefficient'. It's a 'simple' EM which is limited to the dynamic power. It has to fit into the math formula which requires also information about voltage. Some of the platforms don't expose voltage information, thus it's not possible to use EM registration using DT. This patch aims to fix it. It introduces new implementation of the EM registration callback. The new mechanism relies on the new OPP feature allowing to get power (which is coming from "opp-microwatt" DT property) expressed in micro-Watts. The patch also opens new opportunity to better support platforms, which have a decent static power. It allows to register the EM based on real power measurements which models total power (static + dynamic), so better reflects real HW. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:16 +00:00
PM: EM: convert power field to micro-Watts precision and align drivers The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-07-07 08:15:52 +01:00
OPP: Add support of "opp-microwatt" for EM registration The Energy Model (EM) can be created based on DT entry: 'dynamic-power-coefficient'. It's a 'simple' EM which is limited to the dynamic power. It has to fit into the math formula which requires also information about voltage. Some of the platforms don't expose voltage information, thus it's not possible to use EM registration using DT. This patch aims to fix it. It introduces new implementation of the EM registration callback. The new mechanism relies on the new OPP feature allowing to get power (which is coming from "opp-microwatt" DT property) expressed in micro-Watts. The patch also opens new opportunity to better support platforms, which have a decent static power. It allows to register the EM based on real power measurements which models total power (static + dynamic), so better reflects real HW. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:16 +00:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
PM: EM: convert power field to micro-Watts precision and align drivers The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-07-07 08:15:52 +01:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
PM: EM: convert power field to micro-Watts precision and align drivers The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-07-07 08:15:52 +01:00
PM: EM: Change the order of arguments in the .active_power() callback The .active_power() callback passes the device pointer when it's called. Aligned with a convetion present in other subsystems and pass the 'dev' as a first argument. It looks more cleaner. Adjust all affected drivers which implement that API callback. Suggested-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-03-21 09:57:25 +00:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
PM: EM: convert power field to micro-Watts precision and align drivers The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-07-07 08:15:52 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
PM: EM: convert power field to micro-Watts precision and align drivers The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-07-07 08:15:52 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: Add support of "opp-microwatt" for EM registration The Energy Model (EM) can be created based on DT entry: 'dynamic-power-coefficient'. It's a 'simple' EM which is limited to the dynamic power. It has to fit into the math formula which requires also information about voltage. Some of the platforms don't expose voltage information, thus it's not possible to use EM registration using DT. This patch aims to fix it. It introduces new implementation of the EM registration callback. The new mechanism relies on the new OPP feature allowing to get power (which is coming from "opp-microwatt" DT property) expressed in micro-Watts. The patch also opens new opportunity to better support platforms, which have a decent static power. It allows to register the EM based on real power measurements which models total power (static + dynamic), so better reflects real HW. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:16 +00:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: Add support of "opp-microwatt" for EM registration The Energy Model (EM) can be created based on DT entry: 'dynamic-power-coefficient'. It's a 'simple' EM which is limited to the dynamic power. It has to fit into the math formula which requires also information about voltage. Some of the platforms don't expose voltage information, thus it's not possible to use EM registration using DT. This patch aims to fix it. It introduces new implementation of the EM registration callback. The new mechanism relies on the new OPP feature allowing to get power (which is coming from "opp-microwatt" DT property) expressed in micro-Watts. The patch also opens new opportunity to better support platforms, which have a decent static power. It allows to register the EM based on real power measurements which models total power (static + dynamic), so better reflects real HW. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:16 +00:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: Add support of "opp-microwatt" for EM registration The Energy Model (EM) can be created based on DT entry: 'dynamic-power-coefficient'. It's a 'simple' EM which is limited to the dynamic power. It has to fit into the math formula which requires also information about voltage. Some of the platforms don't expose voltage information, thus it's not possible to use EM registration using DT. This patch aims to fix it. It introduces new implementation of the EM registration callback. The new mechanism relies on the new OPP feature allowing to get power (which is coming from "opp-microwatt" DT property) expressed in micro-Watts. The patch also opens new opportunity to better support platforms, which have a decent static power. It allows to register the EM based on real power measurements which models total power (static + dynamic), so better reflects real HW. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:16 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: Add support of "opp-microwatt" for EM registration The Energy Model (EM) can be created based on DT entry: 'dynamic-power-coefficient'. It's a 'simple' EM which is limited to the dynamic power. It has to fit into the math formula which requires also information about voltage. Some of the platforms don't expose voltage information, thus it's not possible to use EM registration using DT. This patch aims to fix it. It introduces new implementation of the EM registration callback. The new mechanism relies on the new OPP feature allowing to get power (which is coming from "opp-microwatt" DT property) expressed in micro-Watts. The patch also opens new opportunity to better support platforms, which have a decent static power. It allows to register the EM based on real power measurements which models total power (static + dynamic), so better reflects real HW. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-03-02 11:29:16 +00:00
PM: EM: Add a flag indicating units of power values in Energy Model There are different platforms and devices which might use different scale for the power values. Kernel sub-systems might need to check if all Energy Model (EM) devices are using the same scale. Address that issue and store the information inside EM for each device. Thanks to that they can be easily compared and proper action triggered. Suggested-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Quentin Perret <qperret@google.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-11-05 12:50:01 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-05-27 10:58:54 +01:00
PM / OPP: Introduce a power estimation helper The Energy Model (EM) framework provides an API to let drivers register the active power of CPUs. The drivers are expected to provide a callback method which estimates the power consumed by a CPU at each available performance levels. How exactly this should be implemented, however, depends on the platform. On some systems, PM_OPP knows the voltage and frequency at which CPUs can run. When coupled with the CPU 'capacitance' (as provided by the 'dynamic-power-coefficient' devicetree binding), it is possible to estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with C its capacitance and V and f respectively the voltage and frequency of the OPP. The Intelligent Power Allocator (IPA) thermal governor already implements that estimation method, in the thermal framework. However, this power estimation method can be applied to any platform where all the parameters are known (C, V and f), and not only those suffering thermal issues. As such, the code implementing this feature can be re-used to also populate the EM framework now used by EAS. As a first step, introduce in PM_OPP a helper function which CPUFreq drivers can use to register into the EM framework. This duplicates the power estimation done in IPA until it can be migrated to using the EM framework. This will be done later, once the EM framework has support for at least all platforms currently supported by IPA. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Tested-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 11:09:48 +00:00