|
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@xxxxxxxxxxxxxx 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 |
