Re: [PATCH 2/2] backlight: pwm_bl: Don't disable the PWM to disable the backlight

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

Hello Daniel,

On Tue, Jan 10, 2023 at 04:26:14PM +0000, Daniel Thompson wrote:
> On Mon, Jan 09, 2023 at 09:47:58PM +0100, Uwe Kleine-König wrote:
> > Most but not all PWMs drive the PWM pin to its inactive state when
> > disabled. Rely on the lowlevel PWM implementation to implement
> > duty_cycle = 0 in an energy efficient way and don't disable the PWM.
> 
> I'm a little worried about this one.
> 
> I thought the PWM APIs allow the duty cycle to be rounded up or down
> slightly during the apply.

In my book only rounding down is correct, but in practise there is some
deviation.

Nearly all PWMs can implement a zero duty cycle. Those that cannot but
emit a constant inactive signal when disabled are expected to disable
when .duty_cycle = 0 is requested. (And for those that can neither
implement a zero duty_cycle nor emit the inactive level (not sure there
is any) all bets are lost with and without my patch.)
So if this case will be hit (and noticed) this is fixable.

However there are hardware PWMs that just freeze in their current state
when disabled (e.g. mxs). That's why .duty_cycle=0 + .enabled=true is
the safer bet. Only disable a PWM if you don't rely on the output state.
See also commit 80a22fde803af6f390be49ee5ced6ee75595ba05.

> So when you say "rely on the lowlevel to implement duty_cycle = 0 to..."
> is it confirmed that this is true (and that all PWMs *can* implement
> a duty_cycle of 0 without rounding up)?

The scenario I had in mind that can realistically go wrong here is that
a lowlevel driver that has the property that the inactive level is
emitted for a disabled HW doesn't actually disable when .duty_cycle=0 is
requested and so might consume slightly more energy. But I'm confident
my patch is an improvement and I don't expect regressions. (Famous last
words :-)

I suggest to amend the commit log and add something like:

   If this change results in a regression, the bug is in the lowlevel
   pwm driver.

Best regards
Uwe

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]