linux-kernel - Re: [PATCH] leds: rgb: leds-qcom-lpg: Fix pwm resolution for Hi-Res PWMs

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: <ioater5m23lhkmyik3hurozol6vtyx6ovac3phmvcphrmmprwb@igggmox3jz5m>
Date: Thu, 27 Feb 2025 19:09:39 +0100
From: Uwe Kleine-König <u.kleine-koenig@...libre.com>
To: Abel Vesa <abel.vesa@...aro.org>
Cc: Sebastian Reichel <sre@...nel.org>, Lee Jones <lee@...nel.org>, 
	Pavel Machek <pavel@...nel.org>, Anjelique Melendez <quic_amelende@...cinc.com>, 
	Kamal Wadhwa <quic_kamalw@...cinc.com>, Jishnu Prakash <jishnu.prakash@....qualcomm.com>, 
	Bjorn Andersson <andersson@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, 
	Johan Hovold <johan@...nel.org>, Pavel Machek <pavel@....cz>, linux-leds@...r.kernel.org, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] leds: rgb: leds-qcom-lpg: Fix pwm resolution for Hi-Res
 PWMs

Hello,

On Thu, Feb 27, 2025 at 07:05:14PM +0200, Abel Vesa wrote:
> On 25-02-27 18:32:41, Abel Vesa wrote:
> > On 25-02-27 17:44:35, Abel Vesa wrote:
> > > On 25-02-27 16:25:06, Uwe Kleine-König wrote:
> > > > Hello Abel,
> > > > 
> > > > On Thu, Feb 27, 2025 at 04:26:14PM +0200, Abel Vesa wrote:
> > > > > On 25-02-27 10:58:47, Uwe Kleine-König wrote:
> > > > > > Can you please enable CONFIG_PWM_DEBUG, enable pwm tracing (
> > > > > > 
> > > > > > 	echo 1 > /sys/kernel/debug/tracing/events/pwm/enable
> > > > > > 
> > > > > > ) then reproduce the problem and provide the output of
> > > > > > 
> > > > > > 	cat /sys/kernel/debug/tracing/trace
> > > > > > 
> > > > > > .
> > > > > 
> > > > > $ cat trace
> > > > > # tracer: nop
> > > > > #
> > > > > # entries-in-buffer/entries-written: 13/13   #P:12
> > > > > #
> > > > > #                                _-----=> irqs-off/BH-disabled
> > > > > #                               / _----=> need-resched
> > > > > #                              | / _---=> hardirq/softirq
> > > > > #                              || / _--=> preempt-depth
> > > > > #                              ||| / _-=> migrate-disable
> > > > > #                              |||| /     delay
> > > > > #           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
> > > > > #              | |         |   |||||     |         |
> > > > >         modprobe-203     [000] .....     0.938668: pwm_get: pwmchip0.0: period=1066407 duty_cycle=533334 polarity=0 enabled=1 err=0
> > > > >         modprobe-203     [000] .....     0.938775: pwm_apply: pwmchip0.0: period=5000000 duty_cycle=0 polarity=0 enabled=1 err=0
> > > > >         modprobe-203     [000] .....     0.938821: pwm_get: pwmchip0.0: period=4266537 duty_cycle=0 polarity=0 enabled=1 err=0
> > > > >         modprobe-203     [000] .....     0.938936: pwm_apply: pwmchip0.0: period=4266537 duty_cycle=0 polarity=0 enabled=1 err=0
> > > > >         modprobe-203     [000] .....     0.938982: pwm_get: pwmchip0.0: period=4266537 duty_cycle=0 polarity=0 enabled=1 err=0
> > > > >         modprobe-203     [000] .....     0.939274: pwm_apply: pwmchip0.0: period=5000000 duty_cycle=921458 polarity=0 enabled=1 err=0
> > > > >         modprobe-203     [000] .....     0.939320: pwm_get: pwmchip0.0: period=4266537 duty_cycle=921355 polarity=0 enabled=1 err=0
> > > > >         modprobe-203     [000] .....     0.939434: pwm_apply: pwmchip0.0: period=4266537 duty_cycle=921355 polarity=0 enabled=1 err=0
> > > > >         modprobe-203     [000] .....     0.939480: pwm_get: pwmchip0.0: period=4266537 duty_cycle=921355 polarity=0 enabled=1 err=0
> > > > >  systemd-backlig-724     [006] .....     9.079538: pwm_apply: pwmchip0.0: period=5000000 duty_cycle=5000000 polarity=0 enabled=1 err=0
> > > > >  systemd-backlig-724     [006] .....     9.079585: pwm_get: pwmchip0.0: period=4266537 duty_cycle=4266537 polarity=0 enabled=1 err=0
> > > > >  systemd-backlig-724     [006] .....     9.079698: pwm_apply: pwmchip0.0: period=4266537 duty_cycle=4266537 polarity=0 enabled=1 err=0
> > > > >  systemd-backlig-724     [006] .....     9.079750: pwm_get: pwmchip0.0: period=4266537 duty_cycle=4266537 polarity=0 enabled=1 err=0
> > > > > $
> > > > > 
> > > > > > 
> > > > > > I didn't take a deeper dive in this driver combination, but here is a
> > > > > > description about what *should* happen:
> > > > > > 
> > > > > > You're talking about period in MHz, the PWM abstraction uses
> > > > > > nanoseconds. So your summary translated to the PWM wording is (to the
> > > > > > best of my understanding):
> > > > > > 
> > > > > >   1. PWM backlight driver requests PWM with .period = 200 ns and
> > > > > >      .duty_cycle = 200 ns.
> > > > > > 
> > > > > >   2. leds-qcom-lpg cannot pick 200 ns exactly and then chooses .period =
> > > > > >      1000000000 / 4.26666 MHz = 234.375 ns
> > > > > >      
> > > > > >   3. leds-qcom-lpg then determines setting for requested .duty_cycle
> > > > > >      based on .period = 200 ns which then ends up with something bogus.
> > > > 
> > > > The trace looks better than what I expected. 2. is fine here because it
> > > > seems when Sebastian wrote "driver requests PWM with 5 MHz period" that
> > > > meant period = 5000000 ns. That was then rounded down to 4266537 ns. And
> > > > the request for period = 5000000 ns + duty_cycle = 5000000 ns was
> > > > serviced by configuring period = 4266537 ns + duty_cycle = 4266537 ns.
> > > > So that's a 100 % relative duty configuration as intended.
> > > > 
> > > > So just from the traces I don't spot a problem. Do these logs not match
> > > > what actually happens on the signal?
> > > 
> > > What I do not get is why do we expect 2 pwm_get() and 2 pwm_apply()
> > > calls each time ?
> > 
> > OK, so the second pwm_apply() is due to CONFIG_PWM_DEBUG.

ack. This is done just for the tests implemented in CONFIG_PWM_DEBUG, as
are the two pwm_get()s.

> > But still, the first pwm_apply() requests duty cycle of 5MHz:

5 ms, yes. But it cannot give you 5 ms and so you get 4.266 ns.

> > systemd-backlig-724     [006] .....     9.079538: pwm_apply: pwmchip0.0: period=5000000 duty_cycle=5000000 polarity=0 enabled=1 err=0
> > 
> > So since the period is 4.26MHz, due to the knobs selected by the
> > provider, this duty cycle will result in a PWM value that is above the
> > selected resolution, as I already mentioned.

"above the selected resolution"? Do you mean you don't get the exact
value that you requested?

> On top of that, the duty cycle in debugfs is also reported as 5000000ns
> when in fact it is 4266666ns, as the trace shows.

Yes. Consider that a relict from the times when there was no
pwm_get_state_hw(). Both values are interesting in different situations.
So just telling the real parameters isn't the optimal way forward
either.

Something like the patch I showed in
https://lore.kernel.org/all/7bcnckef23w6g47ll5l3bktygedrcfvr7fk3qjuq2swtoffhec@zs4w4tuh6qvm/
would make you a bit luckier I guess. Feel free to polish that one a bit
(e.g.  by checking the return value of pwm_get_state_hw() and acting
sensible in reply to it) and send a proper patch. (A Suggested-by for me
is enough for such a patch, grab authorship yourself.)

> > > Need to dig a bit further.
> > > 
> > > But meanwhile, if the first pwm_apply() call goes all the way to the
> > > provider, then the duty cycle value, when translated to the actual PWM
> > > value that gets written to reg, will overflow.

No it will not. The .duty_cycle value (also 5000000 ns) will reach the
lowlevel PWM driver together with .period = 5000000 ns. Both are rounded
down to 4266666ns. I see no overflow. 

Best regards
Uwe

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