[PATCH v2 0/3] pwm: stm32: Three fixes

[PATCH v2 0/3] pwm: stm32: Three fixes

[Uwe Kleine-König]

Hello,

this series contains two fixes for the .apply() callback and a trivial
change to fix an error message in probe.

(Implicit) v1 can be found at
https://lore.kernel.org/linux-pwm/cover.1718788826.git.u.kleine-koenig@baylibre.com
Changes since then:

 - Improve working of the commit log of patch #2 (as noticed by myself
   after submission of v1)
 - Drop Cc: stable on patch #2, as the faulty commit isn't in a release
   yet.
 - patch #3 is new (but was sent out already separately)
 - Fix .apply in patch #2 for some more corner cases.
 - Added Trevor's Reviewed-by for patch #1. (I didn't apply it to patch
   #2 as this changed since then.)

The issue in patch #2 was found with CONFIG_PWM_DEBUG enabled. The
problematic setting was period = 941244 ns with input clk rate =
208877930 Hz. For this setting these hardware register values were
calculated:

	PSC = 3
	ARR = 0xbffe

resulting in a real period of 941238.741689943 ns. However a request for
941239 ns resulted in

	PSC = 2
	ARR = 0xfffd

which corresponds to 941229.1667195285 Hz. My error in reasoning was
that I thought I'd need

        period_ns * clkrate
   ------------------------------ ≤ max_arr
   NSEC_PER_SEC * (prescaler + 1)

but in fact the necessary equation is

        period_ns * clkrate
   ------------------------------ < max_arr + 1
   NSEC_PER_SEC * (prescaler + 1)

The value of the LHS fraction for the above mentioned request
(period = 941244 ns, clk rate = 208877930) with PSC = 2 is

	941244 * 208877930 / (1000000000 * 3) = 65535.03278164 > 0xffff = max_arr

But as it's still rounded down to 65535 it's a valid configuration.

Best regards
Uwe

Uwe Kleine-König (3):
  pwm: stm32: Refuse too small period requests
  pwm: stm32: Fix calculation of prescaler
  pwm: stm32: Fix error message to not describe the previous error path

 drivers/pwm/pwm-stm32.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)


base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
-- 
2.43.0

[PATCH v2 1/3] 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
Reviewed-by: Trevor Gamblin <tgamblin@baylibre.com>
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 v2 2/3] 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

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

This value is bigger than 65535 however and so doesn't fit into the
respective register field. 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")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 drivers/pwm/pwm-stm32.c | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 3e7b2a8e34e7..a7ff39e9fc28 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -321,17 +321,23 @@ 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 + 1
 	 *   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 + 1)
+	 *
+	 * Using integer division and knowing that the right hand side is
+	 * integer, this is further equivalent to
+	 *
+	 *   (period_ns * clkrate) // (NSEC_PER_SEC * (max_arr + 1)) ≤ prescaler
 	 */
 
 	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;
-
+					(u64)NSEC_PER_SEC * (priv->max_arr + 1));
 	if (prescaler > MAX_TIM_PSC)
 		return -EINVAL;
 
-- 
2.43.0

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

[Uwe Kleine-König]

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

Hello,

[Dropping Benjamin Gaignard, his address doesn't work]

On Fri, Jun 21, 2024 at 04:37:13PM +0200, Uwe Kleine-König wrote:
>  	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;
> -
> +					(u64)NSEC_PER_SEC * (priv->max_arr + 1));

priv->max_arr + 1 needs a cast to u64 as max_arr is an u32 that for some
hardware is 0xffffffff.

I fix that when applying.

Best regards
Uwe

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

[PATCH v2 3/3] pwm: stm32: Fix error message to not describe the previous error path

[Uwe Kleine-König]

"Failed to lock the clock" is an appropriate error message for
clk_rate_exclusive_get() failing, but not for the clock running too
fast for the driver's calculations.

Adapt the error message accordingly.

Fixes: d44d635635a7 ("pwm: stm32: Fix for settings using period > UINT32_MAX")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 drivers/pwm/pwm-stm32.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index a7ff39e9fc28..bc32e9abf2b1 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -681,7 +681,8 @@ static int stm32_pwm_probe(struct platform_device *pdev)
 	 * .apply() won't overflow.
 	 */
 	if (clk_get_rate(priv->clk) > 1000000000)
-		return dev_err_probe(dev, -EINVAL, "Failed to lock clock\n");
+		return dev_err_probe(dev, -EINVAL, "Clock freq too high (%lu)\n",
+				     clk_get_rate(priv->clk));
 
 	chip->ops = &stm32pwm_ops;
 
-- 
2.43.0