| Message ID | 20240322110850.77086-5-lukasz.luba@arm.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | Update Energy Model after chip binning adjusted voltages | expand |
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> Best regards, Krzysztof
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
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? [...]
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
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.
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 --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);
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(-)