Hello,

first of all thanks for your extensive testing, very appreciated.

On Sun, Apr 26, 2026 at 05:44:46PM +0800, Damon Ding wrote:
> On 4/20/2026 9:52 PM, Nicolas Frattaroli wrote:
> > The Rockchip RK3576 brings with it a new PWM IP, in downstream code
> > referred to as "v4". This new IP is different enough from the previous
> > Rockchip IP that I felt it necessary to add a new driver for it, instead
> > of shoehorning it in the old one.
> > 
> > Add this new driver, based on the PWM core's waveform APIs. Its platform
> > device is registered by the parent mfpwm driver, from which it also
> > receives a little platform data struct, so that mfpwm can guarantee that
> > all the platform device drivers spread across different subsystems for
> > this specific hardware IP do not interfere with each other.
> > 
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Tested-by: Damon Ding <damon.ding@rock-chips.com>
> 
> The continuous mode of all PWM channels has been preliminarily tested
> and verified working on the RK3576 IoT board.
> 
> I have tested with several typical period and duty cycle configurations.
> 
> Following Uwe's suggestion [0], I also tested with libpwm using commands
> similar to the following:
> 
> ./pwmset -c 0 -p 0 -P 1000000 -D 500000 -s 5000

This one is good if you have an oscilloscope (or something similar) to
verify the output. Without that (or additionally) pwmtestperf creates a
series of requests that in combination with PWM_DEBUG should uncover
rounding errors in the .tohw and .fromhw callbacks.

A good set of calls then is:

	pwmtestperf -p ... -c ... -P 50000 -S1
	pwmtestperf -p ... -c ... -P 50000 -S1 -I

	pwmtestperf -p ... -c ... -P 50000 -S-1
	pwmtestperf -p ... -c ... -P 50000 -S-1 -I

(Assuming that 50000 is a sensible period for the device under test.)

And yes, I know, I need to document that using something more permanent
than a mailing list post.

Best regards
Uwe