[PATCH 0/2] pwm: stm32: Two fixes

[PATCH 0/2] pwm: stm32: Two fixes

[Uwe Kleine-König]

Hello,

this series contains two fixes for the .apply() callback where bogous
periods were calculated.

I intend to send these to Linus before v6.10, so please if you have
concerns don't hesitate to express them.

Best regards
Uwe

Uwe Kleine-König (2):
  pwm: stm32: Refuse too small period requests
  pwm: stm32: Fix calculation of prescaler

 drivers/pwm/pwm-stm32.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
-- 
2.43.0

[PATCH 1/2] pwm: stm32: Refuse too small period requests

[Uwe Kleine-König]

If period_ns is small, prd might well become 0. Catch that case because
otherwise with

	regmap_write(priv->regmap, TIM_ARR, prd - 1);

a few lines down quite a big period is configured.

Fixes: 7edf7369205b ("pwm: Add driver for STM32 plaftorm")
Cc: stable@vger.kernel.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 drivers/pwm/pwm-stm32.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index a2f231d13a9f..3e7b2a8e34e7 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -337,6 +337,8 @@ static int stm32_pwm_config(struct stm32_pwm *priv, unsigned int ch,
 
 	prd = mul_u64_u64_div_u64(period_ns, clk_get_rate(priv->clk),
 				  (u64)NSEC_PER_SEC * (prescaler + 1));
+	if (!prd)
+		return -EINVAL;
 
 	/*
 	 * All channels share the same prescaler and counter so when two
-- 
2.43.0

[PATCH 2/2] pwm: stm32: Fix calculation of prescaler

[Uwe Kleine-König]

A small prescaler is beneficial, as this improves the resolution of the
duty_cycle configuration. However if the prescaler is too small, the
maximal possible period becomes considerably smaller than the requested
value.

One situation where this goes wrong is the following: With a parent
clock rate of 208877930 Hz and max_arr = 0xffff = 65535, a request for
period = 941243 ns currently results in PSC = 1. The value for ARR is
then calculated to

	PSC = 941243 * 208877930 / (1000000000 * 2) - 1 = 98301

This value is bigger than 65535 however and so doesn't fit into the
respective register. In this particular case the PWM was configured for
a period of 313733.4806027616 ns (with ARR = 98301 & 0xffff). Even if
ARR was configured to its maximal value, only period = 627495.6861167669
ns would be achievable.

Fix the calculation accordingly and adapt the comment to match the new
algorithm.

With the calculation fixed the above case results in PSC = 2 and so an
actual period of 941229.1667195285 ns.

Fixes: 8002fbeef1e4 ("pwm: stm32: Calculate prescaler with a division instead of a loop")
Cc: stable@vger.kernel.org
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 drivers/pwm/pwm-stm32.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 3e7b2a8e34e7..2de7195e43a9 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -321,17 +321,24 @@ static int stm32_pwm_config(struct stm32_pwm *priv, unsigned int ch,
 	 * First we need to find the minimal value for prescaler such that
 	 *
 	 *        period_ns * clkrate
-	 *   ------------------------------
+	 *   ------------------------------ ≤ max_arr
 	 *   NSEC_PER_SEC * (prescaler + 1)
 	 *
-	 * isn't bigger than max_arr.
+	 * This equation is equivalent to
+	 *
+	 *     period_ns * clkrate
+	 *   ---------------------- ≤ prescaler + 1
+	 *   NSEC_PER_SEC * max_arr
+	 *
+	 * As the left hand side might not be integer but the right hand side
+	 * is, the division must be rounded up when doing integer math. There
+	 * is no variant of mul_u64_u64_div_u64() that rounds up, so we're
+	 * trading that against the +1 which results in a non-optimal prescaler
+	 * only if the division's result is integer.
 	 */
 
 	prescaler = mul_u64_u64_div_u64(period_ns, clk_get_rate(priv->clk),
 					(u64)NSEC_PER_SEC * priv->max_arr);
-	if (prescaler > 0)
-		prescaler -= 1;
-
 	if (prescaler > MAX_TIM_PSC)
 		return -EINVAL;
 
-- 
2.43.0

Re: [PATCH 2/2] pwm: stm32: Fix calculation of prescaler

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Wed, Jun 19, 2024 at 11:26:25AM +0200, Uwe Kleine-König wrote:
> A small prescaler is beneficial, as this improves the resolution of the
> duty_cycle configuration. However if the prescaler is too small, the
> maximal possible period becomes considerably smaller than the requested
> value.
> 
> One situation where this goes wrong is the following: With a parent
> clock rate of 208877930 Hz and max_arr = 0xffff = 65535, a request for
> period = 941243 ns currently results in PSC = 1. The value for ARR is
> then calculated to
> 
> 	PSC = 941243 * 208877930 / (1000000000 * 2) - 1 = 98301
         ^
This ----' must be ARR of course.
 
> This value is bigger than 65535 however and so doesn't fit into the
> respective register. In this particular case the PWM was configured for

While improving the commit log, I'll do s/register/register field/, too.

> a period of 313733.4806027616 ns (with ARR = 98301 & 0xffff). Even if
> ARR was configured to its maximal value, only period = 627495.6861167669
> ns would be achievable.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 0/2] pwm: stm32: Two fixes

[Trevor Gamblin]

On 2024-06-19 5:26 a.m., Uwe Kleine-König wrote:
> Hello,
>
> this series contains two fixes for the .apply() callback where bogous
> periods were calculated.
>
> I intend to send these to Linus before v6.10, so please if you have
> concerns don't hesitate to express them.
Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com>
>
> Best regards
> Uwe
>
> Uwe Kleine-König (2):
>    pwm: stm32: Refuse too small period requests
>    pwm: stm32: Fix calculation of prescaler
>
>   drivers/pwm/pwm-stm32.c | 19 ++++++++++++++-----
>   1 file changed, 14 insertions(+), 5 deletions(-)
>
> base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0