18 Jun, 2020

1 commit

  • Because period and duty cycle are defined as ints with units of
    nanoseconds, the maximum time duration that can be set is limited to
    ~2.147 seconds. Change their definitions to u64 in the structs of the
    PWM framework so that higher durations may be set.

    Also use the right format specifiers in debug prints in both core.c,
    pwm-stm32-lp.c as well as video/fbdev/ssd1307fb.c.

    Reported-by: kbuild test robot
    Signed-off-by: Guru Das Srinagesh
    Acked-by: Uwe Kleine-König
    Signed-off-by: Thierry Reding

    Guru Das Srinagesh
     

21 Sep, 2019

2 commits

  • LPTimer can use a 32KHz clock for counting. It depends on clock tree
    configuration. In such a case, PWM output frequency range is limited.
    Although unlikely, nothing prevents user from requesting a PWM frequency
    above counting clock (32KHz for instance):
    - This causes (prd - 1) = 0xffff to be written in ARR register later in
    the apply() routine.
    This results in badly configured PWM period (and also duty_cycle).
    Add a check to report an error is such a case.

    Signed-off-by: Fabrice Gasnier
    Reviewed-by: Uwe Kleine-König
    Signed-off-by: Thierry Reding

    Fabrice Gasnier
     
  • It is surprising for a PWM consumer when the variable holding the
    requested state is modified by pwm_apply_state(). Consider for example a
    driver doing:

    #define PERIOD 5000000
    #define DUTY_LITTLE 10
    ...
    struct pwm_state state = {
    .period = PERIOD,
    .duty_cycle = DUTY_LITTLE,
    .polarity = PWM_POLARITY_NORMAL,
    .enabled = true,
    };

    pwm_apply_state(mypwm, &state);
    ...
    state.duty_cycle = PERIOD / 2;
    pwm_apply_state(mypwm, &state);

    For sure the second call to pwm_apply_state() should still have
    state.period = PERIOD and not something the hardware driver chose for a
    reason that doesn't necessarily apply to the second call.

    So declare the state argument as a pointer to a const type and adapt all
    drivers' .apply callbacks.

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

    Uwe Kleine-König
     

25 Jun, 2019

1 commit

  • Add suspend/resume PM sleep ops. When going to low power, enforce the PWM
    channel isn't active. Let the PWM consumers disable it during their own
    suspend sequence. Only perform a check here, and handle the pinctrl states.
    See [1].
    [1] https://lkml.org/lkml/2019/2/5/770

    Signed-off-by: Fabrice Gasnier
    Signed-off-by: Thierry Reding

    Fabrice Gasnier
     

20 Aug, 2018

1 commit


28 Mar, 2018

2 commits


15 Nov, 2017

1 commit


04 Sep, 2017

1 commit