diff mbox series

[RESEND,v2,4/4] soc: samsung: exynos-asv: Update Energy Model after adjusting voltage

Message ID 20240322110850.77086-5-lukasz.luba@arm.com
State Superseded
Headers show
Series Update Energy Model after chip binning adjusted voltages | expand

Commit Message

Lukasz Luba March 22, 2024, 11:08 a.m. UTC
When the voltage for OPPs is adjusted there is a need to also update
Energy Model framework. The EM data contains power values which depend
on voltage values. The EM structure is used for thermal (IPA governor)
and in scheduler task placement (EAS) so it should reflect the real HW
model as best as possible to operate properly.

Based on data on Exynos5422 ASV tables the maximum power difference might
be ~29%. An Odroid-XU4 (with a random sample SoC in this chip lottery)
showed power difference for some OPPs ~20%. Therefore, it's worth to
update the EM.

Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
---
 drivers/soc/samsung/exynos-asv.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Comments

Lukasz Luba March 26, 2024, 8:28 a.m. UTC | #1
On 3/25/24 19:17, Krzysztof Kozlowski wrote:
> On 22/03/2024 12:08, Lukasz Luba wrote:
>> When the voltage for OPPs is adjusted there is a need to also update
>> Energy Model framework. The EM data contains power values which depend
>> on voltage values. The EM structure is used for thermal (IPA governor)
>> and in scheduler task placement (EAS) so it should reflect the real HW
>> model as best as possible to operate properly.
>>
>> Based on data on Exynos5422 ASV tables the maximum power difference might
>> be ~29%. An Odroid-XU4 (with a random sample SoC in this chip lottery)
>> showed power difference for some OPPs ~20%. Therefore, it's worth to
>> update the EM.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>>   drivers/soc/samsung/exynos-asv.c | 11 ++++++++++-
>>   1 file changed, 10 insertions(+), 1 deletion(-)
> 
> I assume there is dependency, even though cover letter did not mention
> it, so:
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Thanks Krzysztof for the review. Yes, it touches driver in your tree
indeed. Hopefully it can goes smoothly via Rafael's tree with your
tag.

Regards,
Lukasz
Dietmar Eggemann March 26, 2024, 11:20 a.m. UTC | #2
On 22/03/2024 12:08, Lukasz Luba wrote:

[...]

> @@ -97,9 +98,17 @@ static int exynos_asv_update_opps(struct exynos_asv *asv)
>  			last_opp_table = opp_table;
>  
>  			ret = exynos_asv_update_cpu_opps(asv, cpu);
> -			if (ret < 0)
> +			if (!ret) {
> +				/*
> +				 * When the voltage for OPPs successfully
> +				 * changed, update the EM power values to
> +				 * reflect the reality and not use stale data

At this point, can we really say that the voltage has changed?

  exynos_asv_update_cpu_opps()

    ...
    ret = dev_pm_opp_adjust_voltage()
    if (!ret)
      em_dev_update_chip_binning()
    ...

dev_pm_opp_adjust_voltage() also returns 0 when the voltage value stays
the same?

[...]
Lukasz Luba March 26, 2024, 8:12 p.m. UTC | #3
Hi Dietmar,

On 3/26/24 11:20, Dietmar Eggemann wrote:
> On 22/03/2024 12:08, Lukasz Luba wrote:
> 
> [...]
> 
>> @@ -97,9 +98,17 @@ static int exynos_asv_update_opps(struct exynos_asv *asv)
>>   			last_opp_table = opp_table;
>>   
>>   			ret = exynos_asv_update_cpu_opps(asv, cpu);
>> -			if (ret < 0)
>> +			if (!ret) {
>> +				/*
>> +				 * When the voltage for OPPs successfully
>> +				 * changed, update the EM power values to
>> +				 * reflect the reality and not use stale data
> 
> At this point, can we really say that the voltage has changed?
> 
>    exynos_asv_update_cpu_opps()
> 
>      ...
>      ret = dev_pm_opp_adjust_voltage()
>      if (!ret)
>        em_dev_update_chip_binning()
>      ...
> 
> dev_pm_opp_adjust_voltage() also returns 0 when the voltage value stays
> the same?
> 
> [...]

The comment for the dev_pm_opp_adjust_voltage() says that it
returns 0 if no modification was done or modification was
successful. So I cannot distinguish in that driver code, but
also there is no additional need to do it IMO (even framework
doesn't do this).

Regards,
Lukasz

[1] 
https://elixir.bootlin.com/linux/v6.9-rc1/source/drivers/opp/core.c#L2950
Dietmar Eggemann March 27, 2024, 12:56 p.m. UTC | #4
On 26/03/2024 21:12, Lukasz Luba wrote:
> Hi Dietmar,
> 
> On 3/26/24 11:20, Dietmar Eggemann wrote:
>> On 22/03/2024 12:08, Lukasz Luba wrote:
>>
>> [...]
>>
>>> @@ -97,9 +98,17 @@ static int exynos_asv_update_opps(struct
>>> exynos_asv *asv)
>>>               last_opp_table = opp_table;
>>>                 ret = exynos_asv_update_cpu_opps(asv, cpu);
>>> -            if (ret < 0)
>>> +            if (!ret) {
>>> +                /*
>>> +                 * When the voltage for OPPs successfully
>>> +                 * changed, update the EM power values to
>>> +                 * reflect the reality and not use stale data
>>
>> At this point, can we really say that the voltage has changed?
>>
>>    exynos_asv_update_cpu_opps()
>>
>>      ...
>>      ret = dev_pm_opp_adjust_voltage()
>>      if (!ret)
>>        em_dev_update_chip_binning()
>>      ...
>>
>> dev_pm_opp_adjust_voltage() also returns 0 when the voltage value stays
>> the same?
>>
>> [...]
> 
> The comment for the dev_pm_opp_adjust_voltage() says that it
> returns 0 if no modification was done or modification was
> successful. So I cannot distinguish in that driver code, but
> also there is no additional need to do it IMO (even framework
> doesn't do this).

Precisely. That's why the added comment in exynos_asv_update_opps():
"When the voltage for OPPs successfully __changed__, ..." is somehow
misleading IMHO.
Lukasz Luba March 27, 2024, 1:39 p.m. UTC | #5
On 3/27/24 12:56, Dietmar Eggemann wrote:
> On 26/03/2024 21:12, Lukasz Luba wrote:
>> Hi Dietmar,
>>
>> On 3/26/24 11:20, Dietmar Eggemann wrote:
>>> On 22/03/2024 12:08, Lukasz Luba wrote:
>>>
>>> [...]
>>>
>>>> @@ -97,9 +98,17 @@ static int exynos_asv_update_opps(struct
>>>> exynos_asv *asv)
>>>>                last_opp_table = opp_table;
>>>>                  ret = exynos_asv_update_cpu_opps(asv, cpu);
>>>> -            if (ret < 0)
>>>> +            if (!ret) {
>>>> +                /*
>>>> +                 * When the voltage for OPPs successfully
>>>> +                 * changed, update the EM power values to
>>>> +                 * reflect the reality and not use stale data
>>>
>>> At this point, can we really say that the voltage has changed?
>>>
>>>     exynos_asv_update_cpu_opps()
>>>
>>>       ...
>>>       ret = dev_pm_opp_adjust_voltage()
>>>       if (!ret)
>>>         em_dev_update_chip_binning()
>>>       ...
>>>
>>> dev_pm_opp_adjust_voltage() also returns 0 when the voltage value stays
>>> the same?
>>>
>>> [...]
>>
>> The comment for the dev_pm_opp_adjust_voltage() says that it
>> returns 0 if no modification was done or modification was
>> successful. So I cannot distinguish in that driver code, but
>> also there is no additional need to do it IMO (even framework
>> doesn't do this).
> 
> Precisely. That's why the added comment in exynos_asv_update_opps():
> "When the voltage for OPPs successfully __changed__, ..." is somehow
> misleading IMHO.
> 

I got your point. Let me re-phrase that comment to reflect this
OPP function return properly.
diff mbox series

Patch

diff --git a/drivers/soc/samsung/exynos-asv.c b/drivers/soc/samsung/exynos-asv.c
index d60af8acc3916..bd6bb2cab2cd8 100644
--- a/drivers/soc/samsung/exynos-asv.c
+++ b/drivers/soc/samsung/exynos-asv.c
@@ -11,6 +11,7 @@ 
 
 #include <linux/cpu.h>
 #include <linux/device.h>
+#include <linux/energy_model.h>
 #include <linux/errno.h>
 #include <linux/of.h>
 #include <linux/pm_opp.h>
@@ -97,9 +98,17 @@  static int exynos_asv_update_opps(struct exynos_asv *asv)
 			last_opp_table = opp_table;
 
 			ret = exynos_asv_update_cpu_opps(asv, cpu);
-			if (ret < 0)
+			if (!ret) {
+				/*
+				 * When the voltage for OPPs successfully
+				 * changed, update the EM power values to
+				 * reflect the reality and not use stale data
+				 */
+				em_dev_update_chip_binning(cpu);
+			} else {
 				dev_err(asv->dev, "Couldn't udate OPPs for cpu%d\n",
 					cpuid);
+			}
 		}
 
 		dev_pm_opp_put_opp_table(opp_table);