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

_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.

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

_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 <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Drop redundant code in _link_required_opps()

Due to that the required-devs for the required OPPs are now always being
assigned, we no longer need the special treatment in _link_required_opps()

OPP: Drop redundant code in _link_required_opps()

Due to that the required-devs for the required OPPs are now always being
assigned, we no longer need the special treatment in _link_required_opps()
for the single PM domain case. Let's therefore drop it.

Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

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

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 a

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

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 <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

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

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

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

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 <[email protected]>
Reviewed-by: Dietmar Eggemann <[email protected]>
Signed-off-by: Lukasz Luba <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

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

Like other frameworks (clk, regulator, etc.) genpd core too takes care
of propagation to performance state to parent genpds. The OPP core
shouldn't

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

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 <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Call dev_pm_opp_set_opp() for required OPPs

Configuring the required OPP was never properly implemented, we just
took an exception for genpds and configured them directly, while leaving
out all

OPP: Call dev_pm_opp_set_opp() for required OPPs

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 <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Use _set_opp_level() for single genpd case

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 ca

OPP: Use _set_opp_level() for single genpd case

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 <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Level zero is valid

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 v

OPP: Level zero is valid

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 <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Add _link_required_opps() to avoid code duplication

Factor out _link_required_opps() to remove duplicate code. No functional
change.

Signed-off-by: Viresh Kumar <[email protected]>
Revie

OPP: Add _link_required_opps() to avoid code duplication

Factor out _link_required_opps() to remove duplicate code. No functional
change.

Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

OPP: Fix formatting of if/else block

Add {} to both if else blocks or none.

Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

OPP: Fix -Wunsequenced in _of_add_opp_table_v1()

Clang warns (or errors with CONFIG_WERROR=y):

drivers/opp/of.c:1081:28: error: multiple unsequenced modifications to 'val' [-Werror,-Wunsequenced]

OPP: Fix -Wunsequenced in _of_add_opp_table_v1()

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 <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility

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

OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility

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 <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Properly propagate error along when failing to get icc_path

fa155f4f8348 ("OPP: Use dev_err_probe() when failing to get icc_path")
failed to actually use the error it was trying to log:

sm

OPP: Properly propagate error along when failing to get icc_path

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 <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Closes: https://lore.kernel.org/r/[email protected]/
Signed-off-by: Andrew Halaney <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Use dev_err_probe() when failing to get icc_path

This, in tandem with dynamic debug, can print useful information about
-EPROBE_DEFFER like below, and keeps similar behavior for other errors:

OPP: Use dev_err_probe() when failing to get icc_path

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 <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

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

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_p

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

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 <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

OPP: pstate is only valid for genpd OPP tables

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 sam

OPP: pstate is only valid for genpd OPP tables

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 <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Tested-by: Bjorn Andersson <[email protected]>

show more ...

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

This code was added (long back) by commit 009acd196fc8 ("PM / OPP:
Support updating performance state of device's power domain") and at
th

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

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 <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

OPP: Protect `lazy_opp_tables` list with `opp_table_lock`

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

Reported-by: Step

OPP: Protect `lazy_opp_tables` list with `opp_table_lock`

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 <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>

show more ...

OPP: Staticize `lazy_opp_tables` in of.c

`lazy_opp_tables` is only used in of.c, move it there and mark it
`static`.

Signed-off-by: Viresh Kumar <[email protected]>

OPP: Adjust includes to remove of_device.h

Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Adjust the
include

OPP: Adjust includes to remove of_device.h

Now that of_cpu_device_node_get() is defined in of.h, of_device.h is just
implicitly including other includes, and is no longer needed. Adjust the
include files with what was implicitly included by of_device.h (cpu.h and
of.h) and drop including of_device.h.

Acked-by: Viresh Kumar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Herring <[email protected]>

show more ...

OPP: Move required opps configuration to specialized callback

The required-opps configuration is closely tied to genpd and performance
states at the moment and it is not very obvious that required-o

OPP: Move required opps configuration to specialized callback

The required-opps configuration is closely tied to genpd and performance
states at the moment and it is not very obvious that required-opps can
live without genpds. Though we don't support configuring required-opps
for non-genpd cases currently.

This commit aims at separating these parts, where configuring genpds
would be a special case of configuring the required-opps.

Add a specialized callback, set_required_opps(), to the opp table and
set it to different callbacks accordingly.

This shouldn't result in any functional changes for now.

Signed-off-by: Viresh Kumar <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

opp: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/

opp: Use of_property_present() for testing DT property presence

It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.

Signed-off-by: Rob Herring <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: decouple dt properties in opp_parse_supplies()

The opp-microwatt property was added with the intention of providing
platforms a way to specify a precise value for the power consumption
of a dev

OPP: decouple dt properties in opp_parse_supplies()

The opp-microwatt property was added with the intention of providing
platforms a way to specify a precise value for the power consumption
of a device at a given OPP to enable better energy-aware scheduling
decisions by informing the kernel of the total static and dynamic
power of a device at a given OPP, removing the reliance on the EM
subsystem's often flawed estimations. This property is parsed by
opp_parse_supplies(), which creates a hard dependency on the
opp-microvolt property.

Some platforms, such as Apple Silicon, do not describe their device's
voltage regulators in the DT as they cannot be controlled by the kernel
and/or rely on opaque firmware algorithms to control their voltage and
current characteristics at runtime. We can, however, experimentally
determine the power consumption of a given device at a given OPP, taking
advantage of opp-microwatt to provide EAS on such devices as was
initially intended.

Allow platforms to specify and consume any subset of opp-microvolt,
opp-microamp, or opp-microwatt without a hard dependency on
opp-microvolt to enable this functionality on such platforms.

Tested-by: James Calligeros <[email protected]>
Signed-off-by: James Calligeros <[email protected]>
Co-developed-by: Viresh Kumar <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Simplify opp_parse_supplies() by restructuring it

opp_parse_supplies() has grown into too big of a routine (~190 lines)
and it is not straight-forward to understand it anymore.

Break it into s

OPP: Simplify opp_parse_supplies() by restructuring it

opp_parse_supplies() has grown into too big of a routine (~190 lines)
and it is not straight-forward to understand it anymore.

Break it into smaller routines and reduce code redundancy a bit by using
the same code to parse properties.

This shouldn't result in any logical changes.

Tested-by: James Calligeros <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...

OPP: Parse named opp-microwatt property too

We missed parsing the named opp-microwatt-<name> property, fix that.

Tested-by: James Calligeros <[email protected]>
Signed-off-by: Viresh Kumar <v

OPP: Parse named opp-microwatt property too

We missed parsing the named opp-microwatt-<name> property, fix that.

Tested-by: James Calligeros <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>

show more ...