thermal: devfreq_cooling: Fix perf state when calculate dfc res_util

The issue occurs when the devfreq cooling device uses the EM power model
and the get_real_power() callback is provided by the dri

thermal: devfreq_cooling: Fix perf state when calculate dfc res_util

The issue occurs when the devfreq cooling device uses the EM power model
and the get_real_power() callback is provided by the driver.

The EM power table is sorted ascending，can't index the table by cooling
device state，so convert cooling state to performance state by
dfc->max_state - dfc->capped_state.

Fixes: 615510fe13bd ("thermal: devfreq_cooling: remove old power model and use EM")
Cc: 5.11+ <[email protected]> # 5.11+
Signed-off-by: Ye Zhang <[email protected]>
Reviewed-by: Dhruva Gole <[email protected]>
Reviewed-by: Lukasz Luba <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

drivers/thermal/devfreq_cooling: Use new Energy Model interface

Energy Model framework support modifications at runtime of the power
values. Use the new EM table which is protected with RCU. Align t

drivers/thermal/devfreq_cooling: Use new Energy Model interface

Energy Model framework support modifications at runtime of the power
values. Use the new EM table which is protected with RCU. Align the
code so that this RCU read section is short.

This change is not expected to alter the general functionality.

Reviewed-by: Dietmar Eggemann <[email protected]>
Tested-by: Dietmar Eggemann <[email protected]>
Signed-off-by: Lukasz Luba <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

thermal/core: Relocate the traces definition in thermal directory

The traces are exported but only local to the thermal core code. On
the other side, the traces take the thermal zone device structur

thermal/core: Relocate the traces definition in thermal directory

The traces are exported but only local to the thermal core code. On
the other side, the traces take the thermal zone device structure as
argument, thus they have to rely on the exported thermal.h header
file. As we want to move the structure to the private thermal core
header, first we have to relocate those traces to the same place as
many drivers do.

Cc: Steven Rostedt <[email protected]>
Suggested-by: Steven Rostedt <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Reviewed-by: Steven Rostedt (Google) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

drivers/thermal/devfreq_cooling: Extend the devfreq_cooling_device with ops

Remove unneeded global variable devfreq_cooling_ops which is used only
as a copy pattern. Instead, extend the struct devfr

drivers/thermal/devfreq_cooling: Extend the devfreq_cooling_device with ops

Remove unneeded global variable devfreq_cooling_ops which is used only
as a copy pattern. Instead, extend the struct devfreq_cooling_device with
the needed ops structure. This also simplifies the allocation/free code
during the setup/cleanup.

Signed-off-by: Lukasz Luba <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Daniel Lezcano <[email protected]>

show more ...

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

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 <[email protected]>
Acked-by: Daniel Lezcano <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

thermal: devfreq_cooling: use local ops instead of global ops

Fix access illegal address problem in following condition:

There are multiple devfreq cooling devices in system, some of them has
EM mo

thermal: devfreq_cooling: use local ops instead of global ops

Fix access illegal address problem in following condition:

There are multiple devfreq cooling devices in system, some of them has
EM model but others do not. Energy model ops such as state2power will
append to global devfreq_cooling_ops when the cooling device with
EM model is registered. It makes the cooling device without EM model
also use devfreq_cooling_ops after appending when registered later by
of_devfreq_cooling_register_power() or of_devfreq_cooling_register().

The IPA governor regards the cooling devices without EM model as a power
actor, because they also have energy model ops, and will access illegal
address at dfc->em_pd when execute cdev->ops->get_requested_power,
cdev->ops->state2power or cdev->ops->power2state.

Fixes: 615510fe13bd2 ("thermal: devfreq_cooling: remove old power model and use EM")
Cc: 5.13+ <[email protected]> # 5.13+
Signed-off-by: Kant Fan <[email protected]>
Reviewed-by: Lukasz Luba <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling

The Energy Model can now be artificial, which means the power values
are mathematically generated to leverage EAS whi

thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling

The Energy Model can now be artificial, which means the power values
are mathematically generated to leverage EAS while not expected to be on
an uniform scale with other devices providing power information. If this
EM type is in use, the thermal governor IPA should not be allowed to
operate, since the relation between cooling devices is not properly
defined. Thus, it might be possible that big GPU has lower power values
than a Little CPU. To mitigate a misbehaviour of the thermal control
algorithm, simply do not register the cooling device as IPA's power
actor.

Signed-off-by: Lukasz Luba <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Reviewed-by: Ionela Voinescu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

thermal/drivers/devfreq_cooling: use HZ macros

HZ unit conversion macros are available in units.h, use them and remove
the duplicate definition.

The new macro uses a unsigned long type which is alr

thermal/drivers/devfreq_cooling: use HZ macros

HZ unit conversion macros are available in units.h, use them and remove
the duplicate definition.

The new macro uses a unsigned long type which is already the type in the
current code via the 'freq' variable.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Daniel Lezcano <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Christian Eggers <[email protected]>
Cc: Chanwoo Choi <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jonathan Cameron <[email protected]>
Cc: Jonathan Cameron <[email protected]>
Cc: Kyungmin Park <[email protected]>
Cc: Lars-Peter Clausen <[email protected]>
Cc: Lukasz Luba <[email protected]>
Cc: Maxime Coquelin <[email protected]>
Cc: Miquel Raynal <[email protected]>
Cc: MyungJoo Ham <[email protected]>
Cc: Peter Meerwald <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Zhang Rui <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

thermal: devfreq_cooling: Fix kernel-doc

Fix function name in devfreq_cooling.c comment to remove a
warning found by kernel-doc.

drivers/thermal/devfreq_cooling.c:479: warning: expecting prototype

thermal: devfreq_cooling: Fix kernel-doc

Fix function name in devfreq_cooling.c comment to remove a
warning found by kernel-doc.

drivers/thermal/devfreq_cooling.c:479: warning: expecting prototype for
devfreq_cooling_em_register_power(). Prototype was for
devfreq_cooling_em_register() instead.

Reported-by: Abaci Robot <[email protected]>
Signed-off-by: Yang Li <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Reviewed-by: Lukasz Luba <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal/drivers/devfreq_cooling: Fix wrong return on error path

The following error is reported by kbuild:

smatch warnings:
drivers/thermal/devfreq_cooling.c:433 of_devfreq_cooling_register_power

thermal/drivers/devfreq_cooling: Fix wrong return on error path

The following error is reported by kbuild:

smatch warnings:
drivers/thermal/devfreq_cooling.c:433 of_devfreq_cooling_register_power() warn: passing zero to 'ERR_PTR'

Fix the error code by the setting the 'err' variable instead of 'cdev'.

Fixes: f8d354e821b2 ("thermal/drivers/devfreq_cooling: Use device name instead of auto-numbering")
Reported-by: kernel test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal/drivers/devfreq_cooling: Use device name instead of auto-numbering

Currently the naming of a cooling device is just a cooling technique
followed by a number. When there are multiple cooling

thermal/drivers/devfreq_cooling: Use device name instead of auto-numbering

Currently the naming of a cooling device is just a cooling technique
followed by a number. When there are multiple cooling devices using
the same technique, it is impossible to clearly identify the related
device as this one is just a number.

For instance:

thermal-devfreq-0
thermal-devfreq-1
etc ...

The 'thermal' prefix is redundant with the subsystem namespace. This
patch removes the 'thermal' prefix and changes the number by the device
name. So the naming above becomes:

devfreq-5000000.gpu
devfreq-1d84000.ufshc
etc ...

Signed-off-by: Daniel Lezcano <[email protected]>
Reviewed-by: Lukasz Luba <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal/drivers/devfreq_cooling: Fix the build when !ENERGY_MODEL

Prevent build failure if the option CONFIG_ENERGY_MODEL is not set. The
devfreq cooling is able to operate without the Energy Model.

thermal/drivers/devfreq_cooling: Fix the build when !ENERGY_MODEL

Prevent build failure if the option CONFIG_ENERGY_MODEL is not set. The
devfreq cooling is able to operate without the Energy Model.
Don't use dev->em_pd directly and use local pointer.

Fixes: 615510fe13bd2 ("thermal: devfreq_cooling: remove old power model and use EM")
Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Lukasz Luba <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: devfreq_cooling: remove old power model and use EM

Remove old power model and use new Energy Model to calculate the power
budget. It drops static + dynamic power calculations and power tabl

thermal: devfreq_cooling: remove old power model and use EM

Remove old power model and use new Energy Model to calculate the power
budget. It drops static + dynamic power calculations and power table
in order to use Energy Model performance domain data. This model
should be easy to use and could find more users. It is also less
complicated to setup the needed structures.

Reviewed-by: Ionela Voinescu <[email protected]>
Signed-off-by: Lukasz Luba <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: devfreq_cooling: add new registration functions with Energy Model

The Energy Model (EM) framework supports devices such as Devfreq. Create
new registration function which automatically regi

thermal: devfreq_cooling: add new registration functions with Energy Model

The Energy Model (EM) framework supports devices such as Devfreq. Create
new registration function which automatically register EM for the thermal
devfreq_cooling devices. This patch prepares the code for coming changes
which are going to replace old power model with the new EM.

Reviewed-by: Ionela Voinescu <[email protected]>
Signed-off-by: Lukasz Luba <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: devfreq_cooling: use a copy of device status

Devfreq cooling needs to now the correct status of the device in order
to operate. Devfreq framework can change the device status in the
backgro

thermal: devfreq_cooling: use a copy of device status

Devfreq cooling needs to now the correct status of the device in order
to operate. Devfreq framework can change the device status in the
background. To mitigate issues make a copy of the status structure and use
it for internal calculations.

In addition this patch adds normalization function, which also makes sure
that whatever data comes from the device, the load will be in range from 1
to 1024.

Reviewed-by: Ionela Voinescu <[email protected]>
Signed-off-by: Lukasz Luba <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: devfreq_cooling: change tracing function and arguments

Prepare for deleting the static and dynamic power calculation and clean
the trace function. These two fields are going to be removed i

thermal: devfreq_cooling: change tracing function and arguments

Prepare for deleting the static and dynamic power calculation and clean
the trace function. These two fields are going to be removed in the next
changes.

Reviewed-by: Ionela Voinescu <[email protected]>
Reviewed-by: Steven Rostedt (VMware) <[email protected]> # for tracing code
Signed-off-by: Lukasz Luba <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: cooling: Remove unused variable *tz

1. devfreq_cooling.c: The variable *tz is not used in
devfreq_cooling_get_requested_power(), devfreq_cooling_state2power()
and devfreq_cooling_power2stat

thermal: cooling: Remove unused variable *tz

1. devfreq_cooling.c: The variable *tz is not used in
devfreq_cooling_get_requested_power(), devfreq_cooling_state2power()
and devfreq_cooling_power2state().

2. cpufreq_cooling.c: After 84fe2cab48590, the variable *tz is not used
anymore in cpufreq_get_requested_power(), cpufreq_state2power() and
cpufreq_power2state().

Remove the variable *tz.

Signed-off-by: zhuguangqing <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: Update power allocator and devfreq cooling to SPDX licensing

Update the license to the SPDX licensing format.

Signed-off-by: Lukasz Luba <[email protected]>
Signed-off-by: Daniel Lezcano

thermal: Update power allocator and devfreq cooling to SPDX licensing

Update the license to the SPDX licensing format.

Signed-off-by: Lukasz Luba <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: devfreq_cooling: Use PM QoS to set frequency limits

Now that devfreq supports limiting the frequency range of a device
through PM QoS make use of it instead of disabling OPPs that should
no

thermal: devfreq_cooling: Use PM QoS to set frequency limits

Now that devfreq supports limiting the frequency range of a device
through PM QoS make use of it instead of disabling OPPs that should
not be used.

The switch from disabling OPPs to PM QoS introduces a subtle behavioral
change in case of conflicting requests (min > max): PM QoS gives
precedence to the MIN_FREQUENCY request, while higher OPPs disabled
with dev_pm_opp_disable() would override MIN_FREQUENCY.

Signed-off-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Lukasz Luba <[email protected]>
Reviewed-by: Chanwoo Choi <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

thermal: devfreq_cooling: Appease the kernel-doc deity

Fix up the following warnings with make W=1:

linux.git/drivers/thermal/devfreq_cooling.c:68: warning: Function
parameter or member 'capped_sta

thermal: devfreq_cooling: Appease the kernel-doc deity

Fix up the following warnings with make W=1:

linux.git/drivers/thermal/devfreq_cooling.c:68: warning: Function
parameter or member 'capped_state' not described in
'devfreq_cooling_device'
linux.git/drivers/thermal/devfreq_cooling.c:593: warning: Function
parameter or member 'cdev' not described in 'devfreq_cooling_unregister'
linux.git/drivers/thermal/devfreq_cooling.c:593: warning: Excess
function parameter 'dfc' description in 'devfreq_cooling_unregister'

Signed-off-by: Amit Kucheria <[email protected]>
Reviewed-by: Viresh Kumar <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/7059d82472fe12139fc7a3379c5b9716a23cce5c.1574242756.git.amit.kucheria@linaro.org

show more ...

trace: thermal: add another parameter 'power' to the tracing function

This patch adds another parameter to the trace function:
trace_thermal_power_devfreq_get_power().

In case when we call directly

trace: thermal: add another parameter 'power' to the tracing function

This patch adds another parameter to the trace function:
trace_thermal_power_devfreq_get_power().

In case when we call directly driver's code for the real power,
we do not have static/dynamic_power values. Instead we get total
power in the '*power' value. The 'static_power' and
'dynamic_power' are set to 0.

Therefore, we have to trace that '*power' value in this scenario.

CC: Steven Rostedt <[email protected]>
CC: Ingo Molnar <[email protected]>
CC: Zhang Rui <[email protected]>
CC: Eduardo Valentin <[email protected]>
Acked-by: Javi Merino <[email protected]>
Signed-off-by: Lukasz Luba <[email protected]>

show more ...

thermal: devfreq_cooling: add new interface for direct power read

This patch introduces a new interface for device drivers connected to
devfreq_cooling in the thermal framework: get_real_power().

S

thermal: devfreq_cooling: add new interface for direct power read

This patch introduces a new interface for device drivers connected to
devfreq_cooling in the thermal framework: get_real_power().

Some devices have more sophisticated methods (like power counters)
to approximate the actual power that they use.
In the previous implementation we had a pre-calculated power
table which was then scaled by 'utilization'
('busy_time' and 'total_time' taken from devfreq 'last_status').

With this new interface the driver can provide more precise data
regarding actual power to the thermal governor every time the power
budget is calculated. We then use this value and calculate the real
resource utilization scaling factor.

Reviewed-by: Chris Diamand <[email protected]>
Acked-by: Javi Merino <[email protected]>
Signed-off-by: Lukasz Luba <[email protected]>

show more ...

thermal: devfreq_cooling: refactor code and add get_voltage function

Move the code which gets the voltage for a given frequency.
This code will be resused in few places.

Acked-by: Javi Merino <javi

thermal: devfreq_cooling: refactor code and add get_voltage function

Move the code which gets the voltage for a given frequency.
This code will be resused in few places.

Acked-by: Javi Merino <[email protected]>
Signed-off-by: Lukasz Luba <[email protected]>

show more ...

thermal: devfreq: Check OPP for errors

It is possible for dev_pm_opp_find_freq_exact() to return errors. It was
all fine earlier as dev_pm_opp_get_voltage() had a check within it to
check for invali

thermal: devfreq: Check OPP for errors

It is possible for dev_pm_opp_find_freq_exact() to return errors. It was
all fine earlier as dev_pm_opp_get_voltage() had a check within it to
check for invalid OPPs, but dev_pm_opp_put() doesn't have any similar
checks and the callers need to make sure OPP is valid before calling
them.

Also update the later dev_warn_ratelimited() to not print the error
message as the OPP is guaranteed to be valid now.

Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Zhang Rui <[email protected]>

show more ...

thermal: devfreq_cooling: Replace dev_warn with dev_err

There isn't much the user can do on seeing this warning, as the hardware
is actually okay. dev_err suits much better here.

Signed-off-by: Vir

thermal: devfreq_cooling: Replace dev_warn with dev_err

There isn't much the user can do on seeing this warning, as the hardware
is actually okay. dev_err suits much better here.

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

show more ...