linux-kernel - Re: [PATCH v17] pwm: opencores: Add PWM driver support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7kfpvipnkirfacy3ro3qb3cmbw5fv5dlyjh3qowc4juvmcb2jj@43zpytio2273>
Date: Tue, 7 Jan 2025 06:07:35 +0100
From: Uwe Kleine-König <ukleinek@...nel.org>
To: Maud Spierings <maud_spierings@...mail.com>
Cc: william.qiu@...rfivetech.com, hal.feng@...rfivetech.com, 
	linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org, p.zabel@...gutronix.de
Subject: Re: [PATCH v17] pwm: opencores: Add PWM driver support

Hello Maud,

On Mon, Jan 06, 2025 at 07:59:23PM +0100, Maud Spierings wrote:
> Hello William,
> 
> I've once again put the patch to the test, and it seems the oops is
> resolved.
> 
> I did notice something odd though, when controlling the backlight  bl_power
> 0 means the backlight is on and controllable, 1 seems like off, but instead
> sets the screen to maximum brightness and then stops listening to any value
> echoed into brightness.

Note that for bl_power 0 is on and 4 is off. Still the behaviour you
report sounds wrong. Quickly looking in the pwm_bl driver, I don't spot
something obvious.

> 
> The brightness is also reversed from what would be logical, so 255 is off
> and 0 is maximum.
> 
> Now the little text at the top specifies that the hardware only does
> inverted polarity, which I guess explains this, but I don't understand it.

The backlight's operation should still be fine, its usage be independent
of the PWM's details.

> I also encountered this when I got an error to start with so I had to add
> PWM_POLARITY_INVERTED to my pwm-backlight definition.

That makes me suspect the problem is on your end. If you add
PWM_POLARITY_INVERTED the result is that the pwm_bl driver still
configures duty_cycle=0 for backlight off, but you then get a constant
high output.

So with the hardware capabilities (i.e. not being able to emit a
constant low output) I think you need to not use PWM_POLARITY_INVERTED
and accept that completely off doesn't work (unless you have an
additional GPIO or regulator to disable the backlight).

> But I don't understand why it isn't supported. Wouldn't supporting non
> inverted polarity be a very simple calculation? 40% negative duty cycle is
> of course equal to 60% positive duty cycle, 20% N == 80% P etc. I don't see
> why the hardware would specifically have to support this.

If you only care about the mean voltage level (as is the case for a
backlight), that's right. But only then. And if the hardware cannot emit
a constant low signal, this doesn't help you.

Best regards
Uwe

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)