| 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
| ||
|
Message-ID: <Z8CbSvlG856oxQRw@linaro.org> Date: Thu, 27 Feb 2025 19:05:14 +0200 From: Abel Vesa <abel.vesa@...aro.org> To: Uwe Kleine-König <u.kleine-koenig@...libre.com> 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 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. > > But still, the first pwm_apply() requests duty cycle of 5MHz: > > 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. > On top of that, the duty cycle in debugfs is also reported as 5000000ns when in fact it is 4266666ns, as the trace shows. > > > > 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. So this is what is wrong. > > And this is what actually happens. > > > > > > > > Best regards > > > Uwe > > > > > > >
Powered by blists - more mailing lists