Hello Roman,

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 PWMx_RDY bit stays 0 well after the last period ends, so if the bit
> has any function at all, this one is certainly not it.

OK.

A way out could be to not disable the clock on .enable = 0. This might
(or might not) have an impact on power consumption, but it improves
correctness and simplifies the driver as the delay just goes away. So
you might consider it a good trade-off, too. Maybe there is also a nice
solution with runtime-PM?!

> Note: my apologies for the previous HTML message

I didn't notice (because the message also contained a txt part). Another
thing to improve is to reply inline instead of top posting :-)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |