kernel/drivers/pwm, branch linux-6.9.y

pwm: stm32: Fix error message to not describe the previous error path

2024-07-05T07:38:17Z

commit f01af3022d4a46362c5dda3d35dea939f3246d10 upstream. "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 Link: https://lore.kernel.org/r/285182163211203fc823a65b180761f46e828dcb.1718979150.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman

pwm: stm32: Fix calculation of prescaler

2024-07-05T07:38:17Z

commit dab8f9f0fe3aada61c0eb013dcf7d3ff75a2c336 upstream. 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 Link: https://lore.kernel.org/r/b4d96b79917617434a540df45f20cb5de4142f88.1718979150.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman

pwm: stm32: Refuse too small period requests

2024-07-05T07:37:49Z

[ Upstream commit c45fcf46ca2368dafe7e5c513a711a6f0f974308 ] 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 Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/b86f62f099983646f97eeb6bfc0117bb2d0c340d.1718979150.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: stm32: Calculate prescaler with a division instead of a loop

2024-07-05T07:37:49Z

[ Upstream commit 8002fbeef1e469b2c397d5cd2940e37b32a17849 ] Instead of looping over increasing values for the prescaler and testing if it's big enough, calculate the value using a single division. Link: https://lore.kernel.org/r/498a44b313a6c0a84ccddd03cd67aadaaaf7daf2.1710711976.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König Stable-dep-of: c45fcf46ca23 ("pwm: stm32: Refuse too small period requests") Signed-off-by: Sasha Levin

pwm: stm32: Fix for settings using period > UINT32_MAX

2024-07-05T07:37:49Z

[ Upstream commit d44d635635a7192c773a75e674a8590a163e879e ] stm32_pwm_config() took the duty_cycle and period values with the type int, however stm32_pwm_apply() passed u64 values there. Expand the function parameters to u64 to not discard relevant bits and adapt the calculations to the wider type. To ensure the calculations won't overflow, check in .probe() the input clk doesn't run faster than 1 GHz. Link: https://lore.kernel.org/r/06b4a650a608d0887d934c1b2b8919e0f78e4db2.1710711976.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König Stable-dep-of: c45fcf46ca23 ("pwm: stm32: Refuse too small period requests") Signed-off-by: Sasha Levin

pwm: stm32: Improve precision of calculation in .apply()

2024-07-05T07:37:48Z

[ Upstream commit e419617847b688799a91126eb6c94b936bfb35ff ] While mathematically it's ok to calculate the number of cyles for the duty cycle as: duty_cycles = period_cycles * duty_ns / period_ns this doesn't always give the right result when doing integer math. This is best demonstrated using an example: With the input clock running at 208877930 Hz a request for duty_cycle = 383 ns and period = 49996 ns results in period_cycles = clkrate * period_ns / NSEC_PER_SEC = 10443.06098828 Now calculating duty_cycles with the above formula gives: duty_cycles = 10443.06098828 * 383 / 49996 = 80.00024719 However with period_cycle truncated to an integer results in: duty_cycles = 10443 * 383 / 49996 = 79.99977998239859 So while a value of (a little more than) 80 would be the right result, only 79 is used here. The problem here is that 14443 is a rounded result that should better not be used to do further math. So to fix that use the exact formular similar to how period_cycles is calculated. Link: https://lore.kernel.org/r/7628ecd8a7538aa5a7397f0fc4199a077168e8a6.1710711976.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König Stable-dep-of: c45fcf46ca23 ("pwm: stm32: Refuse too small period requests") Signed-off-by: Sasha Levin

pwm: meson: Use mul_u64_u64_div_u64() for frequency calculating

2024-05-30T07:44:28Z

[ Upstream commit 32c44e1fa921aebf8a5ef9f778534a30aab39313 ] While calculating frequency for the given period u64 numbers are multiplied before division what can lead to overflow in theory so use secure mul_u64_u64_div_u64() which handles overflow correctly. Fixes: 329db102a26d ("pwm: meson: make full use of common clock framework") Suggested-by: Uwe Kleine-König Signed-off-by: George Stark Link: https://lore.kernel.org/r/20240425171253.2752877-4-gnstark@salutedevices.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: meson: Add check for error from clk_round_rate()

2024-05-30T07:44:28Z

[ Upstream commit 3e551115aee079931b82e1ec78c05f3d5033473f ] clk_round_rate() can return not only zero if requested frequency can not be provided but also negative error code so add check for it too. Also change type of variable holding clk_round_rate() result from unsigned long to long. It's safe due to clk_round_rate() returns long. Fixes: 329db102a26d ("pwm: meson: make full use of common clock framework") Signed-off-by: Dmitry Rokosov Signed-off-by: George Stark Link: https://lore.kernel.org/r/20240425171253.2752877-3-gnstark@salutedevices.com Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: sti: Simplify probe function using devm functions

2024-05-30T07:44:26Z

[ Upstream commit 5bb0b194aeee5d5da6881232f4e9989b35957c25 ] Instead of of_clk_get_by_name() use devm_clk_get_prepared() which has several advantages: - Combines getting the clock and a call to clk_prepare(). The latter can be dropped from sti_pwm_probe() accordingly. - Cares for calling clk_put() which is missing in both probe's error path and the remove function. - Cares for calling clk_unprepare() which can be dropped from the error paths and the remove function. (Note that not all error path got this right.) With additionally using devm_pwmchip_add() instead of pwmchip_add() the remove callback can be dropped completely. With it the last user of platform_get_drvdata() goes away and so platform_set_drvdata() can be dropped from the probe function, too. Fixes: 378fe115d19d ("pwm: sti: Add new driver for ST's PWM IP") Link: https://lore.kernel.org/r/81f0e1d173652f435afda6719adaed1922fe059a.1710068192.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König Signed-off-by: Sasha Levin

pwm: dwc: allow suspend/resume for 16 channels

2024-04-15T15:28:13Z

With 16 channel pwm support, we're registering two instances of pwm_chip with 8 channels each. We need to update PM functions to use both instances of pwm_chip during power state transitions. Introduce struct dwc_pwm_drvdata and use it as driver_data, which will maintain both instances of pwm_chip along with dwc_pwm_info and allow us to use them inside suspend/resume handles. Fixes: ebf2c89eb95e ("pwm: dwc: Add 16 channel support for Intel Elkhart Lake") Signed-off-by: Raag Jadav Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240415074051.14681-1-raag.jadav@intel.com Signed-off-by: Uwe Kleine-König