diff options
author | Uwe Kleine-König <u.kleine-koenig@pengutronix.de> | 2024-03-17 22:52:14 +0100 |
---|---|---|
committer | Uwe Kleine-König <u.kleine-koenig@pengutronix.de> | 2024-04-30 18:57:08 +0200 |
commit | e419617847b688799a91126eb6c94b936bfb35ff (patch) | |
tree | e2efb40c45efed6c1312b4e0f5682855e29f1a96 /drivers/pwm/pwm-meson.c | |
parent | 80bd81cb7a87e98c17f8faa31b0700c466c94e92 (diff) | |
download | linux-e419617847b688799a91126eb6c94b936bfb35ff.tar.gz linux-e419617847b688799a91126eb6c94b936bfb35ff.tar.bz2 linux-e419617847b688799a91126eb6c94b936bfb35ff.zip |
pwm: stm32: Improve precision of calculation in .apply()
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 <u.kleine-koenig@pengutronix.de>
Diffstat (limited to 'drivers/pwm/pwm-meson.c')
0 files changed, 0 insertions, 0 deletions