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):
PWM backlight driver requests PWM with .period = 200 ns and .duty_cycle = 200 ns.
leds-qcom-lpg cannot pick 200 ns exactly and then chooses .period = 1000000000 / 4.26666 MHz = 234.375 ns
- 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?
Best regards Uwe