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 > <[email protected]> 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/ |
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web, visit
https://groups.google.com/d/msgid/linux-sunxi/20210430064145.nzlcw3lpayzapnbx%40pengutronix.de.
signature.asc
Description: PGP signature
