Hello Uwe,
> From: Uwe Kleine-Konig, Sent: Tuesday, January 8, 2019 4:48 PM
> > diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
> > index ba70e83..4987c12 100644
> > --- a/drivers/pwm/pwm-rcar.c
> > +++ b/drivers/pwm/pwm-rcar.c
> > @@ -316,18 +316,16 @@ static int rcar_pwm_suspend(struct device *dev)
> > static int rcar_pwm_resume(struct device *dev)
> > {
> > struct pwm_device *pwm = rcar_pwm_dev_to_pwm_dev(dev);
> > + struct pwm_state state;
> >
> > if (!test_bit(PWMF_REQUESTED, &pwm->flags))
> > return 0;
> >
> > pm_runtime_get_sync(dev);
> >
> > - rcar_pwm_config(pwm->chip, pwm, pwm->state.duty_cycle,
> > - pwm->state.period);
> > - if (pwm_is_enabled(pwm))
> > - rcar_pwm_enable(pwm->chip, pwm);
> > + pwm_get_state(pwm, &state);
> >
> > - return 0;
> > + return rcar_pwm_apply(pwm->chip, pwm, &state);
> > }
>
> Orthogonal to this patch I wonder what the intended behaviour for a pwm
> is on suspend. Should it stop oscilating unconditionally? Or should it
> only stop if the consumer stops it as part of its own suspend callback?
I think the second one is better. I checked drivers/video/backlight/pwm_bl.c
and it is possible to call pwm_apply_state() by the driver after
rcar_pwm_suspend()
was called. So, I'll fix this as other patch.
> As the patch only reworks and improves the code without a change in
> behaviour, it is fine for me.
>
> Acked-by: Uwe Kleine-König <[email protected]>
Thanks!
Best regards,
Yoshihiro Shimoda
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
