[PATCH v6 1/4] gpio: mvebu: fix pwm get_state period calculation

[Uwe Kleine-König]

On Wed, Jan 06, 2021 at 09:37:37AM +0200, Baruch Siach wrote:
> The period is the sum of on and off values.
> 
> Reported-by: Russell King <linux at armlinux.org.uk>
> Fixes: 757642f9a584e ("gpio: mvebu: Add limited PWM support")
> Signed-off-by: Baruch Siach <baruch at tkos.co.il>
> ---
> v6: divide (on + off) sum to reduce rounding error (RMK)
> ---
>  drivers/gpio/gpio-mvebu.c | 19 ++++++++-----------
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index 672681a976f5..a912a8fed197 100644
> --- a/drivers/gpio/gpio-mvebu.c
> +++ b/drivers/gpio/gpio-mvebu.c
> @@ -676,20 +676,17 @@ static void mvebu_pwm_get_state(struct pwm_chip *chip,
>  	else
>  		state->duty_cycle = 1;
>  
> +	val = (unsigned long long) u; /* on duration */
>  	regmap_read(mvpwm->regs, mvebu_pwmreg_blink_off_duration(mvpwm), &u);
> -	val = (unsigned long long) u * NSEC_PER_SEC;
> +	val += (unsigned long long) u; /* period = on + off duration */
> +	val *= NSEC_PER_SEC;
>  	do_div(val, mvpwm->clk_rate);
> -	if (val < state->duty_cycle) {
> +	if (val > UINT_MAX)
> +		state->period = UINT_MAX;

state->period is an u64, so there is no reason to not use values greater
than UINT_MAX.

> +	else if (val)
> +		state->period = val;
> +	else
>  		state->period = 1;

This case assigning 1 looks strange. An explanation in a comment would
be great. I wonder if this is a hardware property or if it is only used
to not report 0 in case that mvpwm->clk_rate is high.

I found a few further shortcommings in the mvebu_pwm implementation while
looking through it:

 a) The rounding problem that RMK found is also present in .apply

    There we have:

    	val = clk_rate * (period - duty_cycle) / NSEC_PER_SEC

    while

    	val = clk_rate * period / NSEC_PER_SEC - on

    would be more exact.

 b) To make

 	pwm_get_state(pwm, &state);
	pwm_apply_state(pwm, &state);

    idempotent .get_state should round up the division results.

 c) .apply also has a check for val being zero and configures at least 1
    cycle for the on and off intervals. Is this a hardware imposed
    limitation? 

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20210107/529cb2e9/attachment-0001.sig>