[PATCH] pwm: sun4i: Round delay time up to a nearest jiffy

[Uwe Kleine-König]

Hello Roman,

On Fri, Apr 30, 2021 at 04:19:32AM +0200, Roman Beránek wrote:
> On Thu, Apr 29, 2021 at 2:04 PM Uwe Kleine-König
> <u.kleine-koenig at pengutronix.de> wrote:
> > On Wed, Apr 28, 2021 at 02:14:31PM +0200, Roman Beránek wrote:
> > > Correct, the output may stay in an active state. I only discovered this
> > > bug as I investigated a report of unreliable screen timeout. The period
> > > we use the PWM with is 50 us.
> >
> > What I don't like here is that the delay is quite coarse and might still
> > be too short. (Maybe I miss something, but consider the current period
> > is quite long, then you configure a short one and then disable. In this
> > case the inital long setting might still be active.)
> 
> The delay is calculated from the original period (cstate.period),
> not the one that was just written into PWM_CHx_PRD 2 lines above.

Yes, but that's not good enough. Consider the PWM is running with a
period of 4s and the period just started. Then you call

	pwm_apply_state(mypwm, &(struct pwm_state){
			.period = 20,
			.enabled = 1,
			...
			})

This doesn't result into the waiting code being run, because
.enabled = 1. Then immidiately after that call:

	pwm_apply_state(mypwm, &(struct pwm_state){
			.period = 20,
			.enabled = 0,
			...
			})

which triggers the waiting but only based on a period of 20 ns while the
4s period is still active.

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/20210430/cfef57c5/attachment.sig>