kernel/linux.git/drivers/opp/of.c, branch v6.12.80

OPP: OF: Fix an OF node leak in _opp_add_static_v2()

2025-02-08T08:57:10+00:00

[ Upstream commit 1d38eb7f7b26261a0b642f6e0923269c7c000a97 ] _opp_add_static_v2() leaks the obtained OF node reference when _of_opp_alloc_required_opps() fails. Add an of_node_put() call in the error path. Fixes: 3466ea2cd6b6 ("OPP: Don't drop opp->np reference while it is still in use") Signed-off-by: Joe Hattori Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

OPP: Introduce an OF helper function to inform if required-opps is used

2024-06-26T05:47:20+00:00

As being shown from a subsequent change to genpd, it's useful to understand if a device's OF node has an OPP-table described and whether it contains OPP nodes that makes use of the required-opps DT property. For this reason, let's introduce an OPP OF helper function called dev_pm_opp_of_has_required_opp(). Signed-off-by: Ulf Hansson Signed-off-by: Viresh Kumar

OPP: OF: Export dev_opp_pm_calc_power() for usage from EM

2024-04-08T14:05:14+00:00

There are device drivers which can modify voltage values for OPPs. It could be due to the chip binning and those drivers have specific chip knowledge about it. This adjustment can happen after Energy Model is registered, thus EM can have stale data about power. Export dev_opp_pm_calc_power() which can be used by Energy Model to calculate new power with the new voltage for OPPs. Acked-by: Viresh Kumar Reviewed-by: Dietmar Eggemann Signed-off-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki

OPP: Don't set OPP recursively for a parent genpd

2023-11-28T10:33:25+00:00

Like other frameworks (clk, regulator, etc.) genpd core too takes care of propagation to performance state to parent genpds. The OPP core shouldn't attempt the same, or it may result in undefined behavior. Add checks at various places to take care of the same. Reviewed-by: Ulf Hansson Tested-by: Stephan Gerhold Signed-off-by: Viresh Kumar

OPP: Call dev_pm_opp_set_opp() for required OPPs

2023-11-28T10:33:19+00:00

Configuring the required OPP was never properly implemented, we just took an exception for genpds and configured them directly, while leaving out all other required OPP types. Now that a standard call to dev_pm_opp_set_opp() takes care of configuring the opp->level too, the special handling for genpds can be avoided by simply calling dev_pm_opp_set_opp() for the required OPPs, which shall eventually configure the corresponding level for genpds. This also makes it possible for us to configure other type of required OPPs (no concrete users yet though), via the same path. This is how other frameworks take care of parent nodes, like clock, regulators, etc, where we recursively call the same helper. In order to call dev_pm_opp_set_opp() for the virtual genpd devices, they must share the OPP table of the genpd. Call _add_opp_dev() for them to get that done. This commit also extends the struct dev_pm_opp_config to pass required devices, for non-genpd cases, which can be used to call dev_pm_opp_set_opp() for the non-genpd required devices. Reviewed-by: Ulf Hansson Tested-by: Stephan Gerhold Signed-off-by: Viresh Kumar

OPP: Use _set_opp_level() for single genpd case

2023-11-28T10:33:15+00:00

There are two genpd (as required-opp) cases that we need to handle, devices with a single genpd and ones with multiple genpds. The multiple genpds case is clear, where the OPP core calls dev_pm_domain_attach_by_name() for them and uses the virtual devices returned by this helper to call dev_pm_domain_set_performance_state() later to change the performance state. The single genpd case however requires special handling as we need to use the same `dev` structure (instead of a virtual one provided by genpd core) for setting the performance state via dev_pm_domain_set_performance_state(). As we move towards more generic code to take care of the required OPPs, where we will recursively call dev_pm_opp_set_opp() for all the required OPPs, the above special case becomes a problem. It doesn't make sense for a device's DT entry to have both "opp-level" and single "required-opps" entry pointing to a genpd's OPP, as that would make the OPP core call dev_pm_domain_set_performance_state() for two different values for the same device structure. And so we can reuse the 'opp->level" field in such a case and call _set_opp_level() for the device. Reviewed-by: Ulf Hansson Tested-by: Stephan Gerhold Signed-off-by: Viresh Kumar

OPP: Level zero is valid

2023-11-28T10:33:04+00:00

The level zero can be used by some OPPs to drop performance state vote for the device. It is perfectly fine to allow the same. _set_opp_level() considers it as an invalid value currently and returns early. In order to support this properly, initialize the level field with U32_MAX, which denotes unused level field. Reported-by: Stephan Gerhold Reviewed-by: Ulf Hansson Tested-by: Stephan Gerhold Signed-off-by: Viresh Kumar

OPP: Add _link_required_opps() to avoid code duplication

2023-10-16T10:36:09+00:00

Factor out _link_required_opps() to remove duplicate code. No functional change. Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson

OPP: Fix formatting of if/else block

2023-10-16T10:35:51+00:00

Add {} to both if else blocks or none. Signed-off-by: Viresh Kumar Reviewed-by: Ulf Hansson

OPP: Fix -Wunsequenced in _of_add_opp_table_v1()

2023-10-06T07:19:29+00:00

Clang warns (or errors with CONFIG_WERROR=y): drivers/opp/of.c:1081:28: error: multiple unsequenced modifications to 'val' [-Werror,-Wunsequenced] 1081 | .freq = be32_to_cpup(val++) * 1000, | ^ 1082 | .u_volt = be32_to_cpup(val++), | ~~ 1 error generated. There is no sequence point in a designated initializer. Move back to separate variables for the creation of the values, so that there are sequence points between each evaluation and increment of val. Fixes: 75bbc92c09d8 ("OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility") Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Viresh Kumar