22 Feb, 2021

2 commits

  • If duty cycle is first set to a value that is sufficiently high to
    enable the output (e.g. 10000 ns) but then lowered to a value that
    is quantized to zero (e.g. 1000 ns), the output is disabled as the
    device cannot drive a constant zero (as expected).

    However if the device is later re-initialized due to watchdog bite,
    the output is re-enabled at the next-to-last duty cycle (10000 ns).
    This is because the iqs620_pwm->out_en flag unconditionally tracks
    state->enabled instead of what was actually written to the device.

    To solve this problem, use one state variable that encodes all 257
    states of the output (duty_scale) with 0 representing tri-state, 1
    representing the minimum available duty cycle and 256 representing
    100% duty cycle.

    Signed-off-by: Jeff LaBundy
    Reviewed-by: Uwe Kleine-König
    Signed-off-by: Thierry Reding

    Jeff LaBundy
     
  • If state->duty_cycle is 0x100000000000000, the previous calculation of
    duty_scale overflows and yields a duty cycle ratio of 0% instead of
    100%. Fix this by clamping the requested duty cycle to the maximal
    possible duty cycle first. This way it is possible to use a native
    integer division instead of a (depending on the architecture) more
    expensive 64bit division.

    With this change in place duty_scale cannot be bigger than 256 which
    allows to simplify the calculation of duty_val.

    Fixes: 6f0841a8197b ("pwm: Add support for Azoteq IQS620A PWM generator")
    Tested-by: Jeff LaBundy
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Thierry Reding

    Uwe Kleine-König
     

17 Dec, 2020

1 commit


18 Jun, 2020

2 commits


14 Apr, 2020

1 commit