Skip to contentSkip to conversation

OMAP3+: PM: VP: fix integer truncation error

PATCH New Nishanth Menon 3 participants 3 messages Mar 6, 2012 – Mar 7, 2012

Subsystems (3)
Arm (32-bit) Arm sub-architectures OMAP2+ support
lore
Share & tools
lore

Nishanth Menon

author
#0 lore raw

PATCH v2 1/1 OMAP3+: PM: VP: fix integer truncation error

From: Yuan Jiangli <[email protected]>

commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957
(OMAP3: PM: Adding voltage driver support.)
introduced runtime computation of waittime to handle all potential sys clocks available.

In the voltage processor, the SPMSUpdateWait is calculated based on the slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step). After the voltage processor receives the SMPS_Ack signal, the Voltage Controller will wait for SMPSUpdateWait clock cycles for the voltage to settle to the new value. For all practical purposes, the waittime parameter is the OMAP hardware translation of what the slew rate on the PMIC is.

As an example, with TPS62361 on OMAP4460,
step_size = 10000
slew_rate = 32000
sys_clk_rate = 38400

Our current computation results in the following:
= ((step_size / slew_rate) * sys_clk_rate) / 1000 = ((10000 / 32000) * 38400 / 1000
= 0

Fix the same using DIV_ROUND_UP as an extra wait clock cycle is better than lesser clock cycle. For the above example, this translates to:
= (10000 * 38400) / (1000 * 32000)
= 12

Acked-by Jon Hunter <[email protected]>
[[email protected]: slightly better implementation]
Signed-off-by Nishanth Menon <[email protected]>
Signed-off-by Yuan Jiangli <[email protected]>
---
 arch/arm/mach-omap2/vp.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/vp.c +2 -2
index 0df8882..f95c1ba 100644
@@ -61,8 +61,8 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
 	vddmin = voltdm->pmic->vp_vddmin;
 	vddmax = voltdm->pmic->vp_vddmax;
 
-	waittime = ((voltdm->pmic->step_size / voltdm->pmic->slew_rate) *
-		    sys_clk_rate) / 1000;
+	waittime = DIV_ROUND_UP(voltdm->pmic->step_size * sys_clk_rate,
+				1000 * voltdm->pmic->slew_rate);
 	vstepmin = voltdm->pmic->vp_vstepmin;
 	vstepmax = voltdm->pmic->vp_vstepmax;
Signature · 1 line
1.7.5.4
#1 lore raw

PATCH v2 1/1 OMAP3+: PM: VP: fix integer truncation error

Quoted 31 lines · Nishanth Menon

From: Yuan Jiangli <[email protected]>

commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957
(OMAP3: PM: Adding voltage driver support.)
introduced runtime computation of waittime to handle all potential sys clocks available.

In the voltage processor, the SPMSUpdateWait is calculated based on the slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step). After the voltage processor receives the SMPS_Ack signal, the Voltage Controller will wait for SMPSUpdateWait clock cycles for the voltage to settle to the new value. For all practical purposes, the waittime parameter is the OMAP hardware translation of what the slew rate on the PMIC is.

As an example, with TPS62361 on OMAP4460,
step_size = 10000
slew_rate = 32000
sys_clk_rate = 38400

Our current computation results in the following:
= ((step_size / slew_rate) * sys_clk_rate) / 1000 = ((10000 / 32000) * 38400 / 1000
= 0

Fix the same using DIV_ROUND_UP as an extra wait clock cycle is better than lesser clock cycle. For the above example, this translates to:
= (10000 * 38400) / (1000 * 32000)
= 12

Quoted 4 lines
Acked-by Jon Hunter <[email protected]>
[nm at ti.com: slightly better implementation]
Signed-off-by Nishanth Menon <[email protected]>
Signed-off-by Yuan Jiangli <[email protected]>
Acked-by Kevin Hilman <[email protected]>

Tony, I don't have any more PM fixes for this cycle, so feel free to add this to fixes-non-critical-part2.

This is an important fix, but since we're not doing active voltage scaling in mainline today, I don't think it's 3.3 material.

Kevin

Quoted 18 lines
---
 arch/arm/mach-omap2/vp.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-omap2/vp.c +2 -2
index 0df8882..f95c1ba 100644
@@ -61,8 +61,8 @@ void __init omap_vp_init(struct voltagedomain *voltdm)
 	vddmin = voltdm->pmic->vp_vddmin;
 	vddmax = voltdm->pmic->vp_vddmax;
 
-	waittime = ((voltdm->pmic->step_size / voltdm->pmic->slew_rate) *
-		    sys_clk_rate) / 1000;
+	waittime = DIV_ROUND_UP(voltdm->pmic->step_size * sys_clk_rate,
+				1000 * voltdm->pmic->slew_rate);
 	vstepmin = voltdm->pmic->vp_vstepmin;
 	vstepmax = voltdm->pmic->vp_vstepmax;
maintainer
#2 lore raw

PATCH v2 1/1 OMAP3+: PM: VP: fix integer truncation error

Quoted 38 lines · Kevin Hilman
Quoted 31 lines · Nishanth Menon

From: Yuan Jiangli <[email protected]>

commit 2f34ce81b8c05c900e45bd88595cc154f7bb5957
(OMAP3: PM: Adding voltage driver support.)
introduced runtime computation of waittime to handle all potential sys clocks available.

In the voltage processor, the SPMSUpdateWait is calculated based on the slew rate and the voltage step (SMPSUpdateWait = slew rate * Voltage Step). After the voltage processor receives the SMPS_Ack signal, the Voltage Controller will wait for SMPSUpdateWait clock cycles for the voltage to settle to the new value. For all practical purposes, the waittime parameter is the OMAP hardware translation of what the slew rate on the PMIC is.

As an example, with TPS62361 on OMAP4460,
step_size = 10000
slew_rate = 32000
sys_clk_rate = 38400

Our current computation results in the following:
= ((step_size / slew_rate) * sys_clk_rate) / 1000 = ((10000 / 32000) * 38400 / 1000
= 0

Fix the same using DIV_ROUND_UP as an extra wait clock cycle is better than lesser clock cycle. For the above example, this translates to:
= (10000 * 38400) / (1000 * 32000)
= 12

Quoted 4 lines
Acked-by Jon Hunter <[email protected]>
[nm at ti.com: slightly better implementation]
Signed-off-by Nishanth Menon <[email protected]>
Signed-off-by Yuan Jiangli <[email protected]>
Quoted 7 lines
Acked-by Kevin Hilman <[email protected]>

Tony, I don't have any more PM fixes for this cycle, so feel free to add this to fixes-non-critical-part2.

This is an important fix, but since we're not doing active voltage scaling in mainline today, I don't think it's 3.3 material.

OK, adding.

Thanks,

Tony