kernel/drivers/opp/of.c, branch linux-6.9.y

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

2023-11-28T10:33:25Z

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:19Z

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:15Z

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:04Z

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:09Z

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:51Z

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:29Z

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

OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility

2023-10-06T07:07:33Z

The dev_pm_opp_add() API is limited to add dynamic OPPs with a frequency and a voltage level. To enable more flexibility, let's add a new API, dev_pm_opp_add_dynamic() that's takes a struct dev_pm_opp_data* instead of a list of in-parameters. Signed-off-by: Ulf Hansson Signed-off-by: Viresh Kumar

OPP: Properly propagate error along when failing to get icc_path

2023-06-27T02:05:14Z

fa155f4f8348 ("OPP: Use dev_err_probe() when failing to get icc_path") failed to actually use the error it was trying to log: smatch warnings: drivers/opp/of.c:516 dev_pm_opp_of_find_icc_paths() warn: passing zero to 'dev_err_probe' Make sure to use the right error and pass it along. Fixes: fa155f4f8348 ("OPP: Use dev_err_probe() when failing to get icc_path") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202306262008.guNLgjt6-lkp@intel.com/ Signed-off-by: Andrew Halaney Signed-off-by: Viresh Kumar

OPP: Use dev_err_probe() when failing to get icc_path

2023-06-26T06:40:26Z

This, in tandem with dynamic debug, can print useful information about -EPROBE_DEFFER like below, and keeps similar behavior for other errors: [ 16.561072] cpu cpu0: error -EPROBE_DEFER: dev_pm_opp_of_find_icc_paths: Unable to get path0 [ 16.575777] platform 18591000.cpufreq: deferred probe pending Signed-off-by: Andrew Halaney Signed-off-by: Viresh Kumar