pwm: sun4i: pwm-backlight not working since 5.6-rc1

[Uwe Kleine-König]

Hello Pascal,

Hi all,
I am working on adding an old A10 device to mainline and noticed an
issue
when testing on 5.5.8 vs master.
Since 5.6-rc1, I can't control the brightness of my LCD backlight
anymore.
The backlight stays on full brightness instead. I am controlling the
brightness value via sysfs for testing.
I am not sure if this is a general pwm-sun4i issue or if it is
related to
fa4d81784681a26bcf7d2a43c6ac5cf991ef28f5
If I use pwm-sun4i.c from 5b090b430d750961305030232314b6acdb0102aa on
master, the backlight works fine. Unfortunately, due to my lack of
kernel
experience, I can't see how the commit above broke it.

Hmm, I cannot see how fa4d81784681a26bcf7d2a43c6ac5cf991ef28f5 breaks
this. Looking at the output of
git show -b fa4d81784681a26bcf7d2a43c6ac5cf991ef28f5
(i.e. ignoring whitespace changes) I don't see how the behaviour you're
reporting can be explained.
Are you sure that fa4d81784681a26bcf7d2a43c6ac5cf991ef28f5 is the bad
commit?
Can you install a tool to inspect register values and check how the
affected registers change if you switch kernel versions and/or pwm
settings?
(e.g.
memtool md 0x1c20e00+0xc
)
Best regards
Uwe

Thanks for your response.
Yes I am sure that is the commit. If I am on master, and replace pwm-sun4i.c
with the one from 5b090b43, everything works. If I then apply fa4d8178, it
stops working.
And strangely the output of the registers is exactly the same before and
01c20e00: 00000050 00130014 00000000 (full brightness)
01c20e00: 00000050 00130006 00000000 (min brightness)
Even when I'm on 5b090b43 and cherry-pick fa4d8178 can I reproduce the
issue.

- enable tracing in the kernel and boot with
trace_event=pwm
And then check after the problem occurred in
/sys/kernel/debug/tracing/trace if something sticks out.
- Try modifying the registers using memtool. E.g.
memtool mw 0x01c20e04 0x00130012
- Do you have equipment to check the actual output of the PWM hardware?
If so, what do you see?

I assume the sun4i-series you sent earlier today resolves the problems
you reported here?

Best regards
Uwe

[Pascal Roeleven]

Post by Uwe Kleine-König
Hello Pascal,

Hi all,
I am working on adding an old A10 device to mainline and noticed an
issue
when testing on 5.5.8 vs master.
Since 5.6-rc1, I can't control the brightness of my LCD backlight
anymore.
The backlight stays on full brightness instead. I am controlling the
brightness value via sysfs for testing.
I am not sure if this is a general pwm-sun4i issue or if it is
related to
fa4d81784681a26bcf7d2a43c6ac5cf991ef28f5
If I use pwm-sun4i.c from 5b090b430d750961305030232314b6acdb0102aa on
master, the backlight works fine. Unfortunately, due to my lack of
kernel
experience, I can't see how the commit above broke it.

Hmm, I cannot see how fa4d81784681a26bcf7d2a43c6ac5cf991ef28f5 breaks
this. Looking at the output of
git show -b fa4d81784681a26bcf7d2a43c6ac5cf991ef28f5
(i.e. ignoring whitespace changes) I don't see how the behaviour you're
reporting can be explained.
Are you sure that fa4d81784681a26bcf7d2a43c6ac5cf991ef28f5 is the bad
commit?
Can you install a tool to inspect register values and check how the
affected registers change if you switch kernel versions and/or pwm
settings?
(e.g.
memtool md 0x1c20e00+0xc
)
Best regards
Uwe

Thanks for your response.
Yes I am sure that is the commit. If I am on master, and replace pwm-sun4i.c
with the one from 5b090b43, everything works. If I then apply fa4d8178, it
stops working.
And strangely the output of the registers is exactly the same before and
01c20e00: 00000050 00130014 00000000 (full brightness)
01c20e00: 00000050 00130006 00000000 (min brightness)
Even when I'm on 5b090b43 and cherry-pick fa4d8178 can I reproduce the
issue.

- enable tracing in the kernel and boot with
trace_event=pwm
And then check after the problem occurred in
/sys/kernel/debug/tracing/trace if something sticks out.
- Try modifying the registers using memtool. E.g.
memtool mw 0x01c20e04 0x00130012
- Do you have equipment to check the actual output of the PWM
hardware?
If so, what do you see?

I assume the sun4i-series you sent earlier today resolves the problems
you reported here?
Best regards
Uwe

Hi Uwe,

Yes it does, but as Emil mentioned it's probably not complete. It's just
an RFC for now to make sure it doesn't cause a regression. Turns out the
Allwinner PWM controller is even more pickier than I thought.

Again, thank you for your help.