Re: [PATCH v5 1/4] gpio: mvebu: fix pwm get_state period calculation
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: 2021-01-05 12:50:48
Also in:
linux-devicetree, linux-gpio, linux-pwm
On Tue, Jan 05, 2021 at 02:42:28PM +0200, Baruch Siach wrote:
quoted hunk ↗ jump to hunk
The period is the sum of on and off values. Reported-by: Russell King <linux@armlinux.org.uk> Fixes: 757642f9a584e ("gpio: mvebu: Add limited PWM support") Signed-off-by: Baruch Siach <baruch@tkos.co.il> --- drivers/gpio/gpio-mvebu.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-)diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c index 672681a976f5..ac7cb6d3702e 100644 --- a/drivers/gpio/gpio-mvebu.c +++ b/drivers/gpio/gpio-mvebu.c@@ -679,17 +679,13 @@ static void mvebu_pwm_get_state(struct pwm_chip *chip, regmap_read(mvpwm->regs, mvebu_pwmreg_blink_off_duration(mvpwm), &u); val = (unsigned long long) u * NSEC_PER_SEC; do_div(val, mvpwm->clk_rate); - if (val < state->duty_cycle) { + val += state->duty_cycle; + if (val > UINT_MAX) + state->period = UINT_MAX; + else if (val) + state->period = val; + else state->period = 1;
Are you sure this is the correct solution? Aren't you introducing rounding errors? The hardware will count to (on + off) clock ticks, so the right way to convert that is to add the two together and then convert to nanoseconds, which may result in a single rounding error. If you convert each individually to nanoseconds, then you can end up with two sets of rounding errors. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel