linux-stable.git/drivers/opp/of.c, branch v6.7

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

OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility

2023-10-06T07:07:33+00:00

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:14+00:00

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:26+00:00

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

OPP: Simplify the over-designed pstate <-> level dance

2023-06-19T04:20:09+00:00

While adding support for "performance states" in the OPP and genpd core,
it was decided to set the `pstate` field via genpd's
pm_genpd_opp_to_performance_state() helper, to allow platforms to set
`pstate` even if they don't have a corresponding `level` field in the DT
OPP tables (More details are present in commit 6e41766a6a50 ("PM /
Domain: Implement of_genpd_opp_to_performance_state()")).

Revisiting that five years later clearly suggests that it was
over-designed as all current users are eventually using the `level`
value only.

The previous commit already added necessary checks to make sure pstate
is only used for genpd tables. Lets now simplify this a little, and use
`level` directly and remove `pstate` field altogether.

Suggested-by: Ulf Hansson 
Signed-off-by: Viresh Kumar 
Reviewed-by: Ulf Hansson

OPP: pstate is only valid for genpd OPP tables

2023-06-19T04:20:02+00:00

It is not very clear right now that the `pstate` field is only valid for
genpd OPP tables and not consumer tables. And there is no checking for
the same at various places.

Add checks in place to verify that and make it clear to the reader.

Signed-off-by: Viresh Kumar 
Reviewed-by: Ulf Hansson 
Reviewed-by: Bjorn Andersson 
Tested-by: Bjorn Andersson

OPP: don't drop performance constraint on OPP table removal

2023-06-14T09:24:01+00:00

This code was added (long back) by commit 009acd196fc8 ("PM / OPP:
Support updating performance state of device's power domain") and at
that time the `opp->pstate` field was used to store the performance
state required by a device's OPP.

Over time that changed and the `->pstate` field is now used only for
genpd devices and consumer devices access that via the required-opps
instead.

Because of all these changes, _opp_table_kref_release() now drops the
constraint only when the genpd's OPP table gets freed and not the
device's. Which is definitely not what we wanted. And dropping the
constraint doesn't have much meaning as the genpd itself is going away.

Moreover, if we want to drop constraints here, then just dropping the
performance constraint alone isn't sufficient as there are other
resource constraints like clk, regulator, etc. too, which must be
handled.

Probably the right thing to do here is to leave this decision to the
consumers, which can call `dev_pm_opp_set_rate(dev, 0)` or similar APIs
to drop all constraints properly. Which many of the consumers already
do.

Remove the special code, which is broken anyway.

Signed-off-by: Viresh Kumar 
Reviewed-by: Ulf Hansson

OPP: Protect `lazy_opp_tables` list with `opp_table_lock`

2023-06-14T03:50:50+00:00

The `opp_table_lock` lock is already used to protect the list elsewhere,
use it while adding or removing entries from it.

Reported-by: Stephan Gerhold 
Signed-off-by: Viresh Kumar 
Tested-by: Stephan Gerhold