On Fri, Jan 20, 2023 at 01:00:18PM +0100, Uwe Kleine-König wrote:
> Most but not all PWMs drive the PWM pin to its inactive state when
> disabled. However if there is no enable_gpio and no regulator the PWM
> must drive the inactive state to actually disable the backlight.
>
> So keep the PWM on in this case.
>
> Note that to determine if there is a regulator some effort is required
> because it might happen that there isn't actually one but the regulator
> core gave us a dummy. (A nice side effect is that this makes the
> regulator actually optional even on fully constrained systems.)
>
> This fixes backlight disabling e.g. on i.MX6 when an inverted PWM is
> used.
>
> Hint for the future: If this change results in a regression, the bug is
> in the lowlevel PWM driver.
> Signed-off-by: Uwe Kleine-König u.kleine-koenig@pengutronix.de<mailto:u.kleine-koenig@pengutronix.de>

This patch broke imx7ulp suspend resume and got the following error:
Freezing remaining freezable tasks
Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
printk: Suspending console(s) (use no_console_suspend to debug)
asix 1-1:1.0 eth0: Link is Down
imx7ulp-tpm-pwm 40250000.pwm: PM: dpm_run_callback(): platform_pm_suspend+0x0/0x48 returns -16
imx7ulp-tpm-pwm 40250000.pwm: PM: failed to suspend: error -16
...

It seems this patch changed the behavior of pwm_backlight_suspend a little bit in
pwm_backlight_power_off() that pwm state keep unchanged during suspend.
Then pwm_imx_tpm_suspend() will return -Ebusy due to tpm->enable_count > 0.
Was this intended behavior? Should we fix pwm core or the driver?

Regards
Aisheng