[PATCH v8 2/4] pwm: sun8i: Add H616 PWM support

[James Hilliard]

On Wed, Sep 23, 2026 at 4:11 AM Uwe Kleine-König <ukleinek at kernel.org> wrote:
>
> On Wed, Sep 23, 2026 at 09:16:28AM +0200, Richard GENOUD wrote:
> > Le 22/09/2026 à 17:46, James Hilliard a écrit :
> > > The resolution tradeoff is real, but the waveform API currently specifies
> > > the ordering: choose the largest period not exceeding the request, then
> > > the largest compatible duty length not exceeding the request, then the
> > > offset. That's the ordering implemented in v9.
> >
> > The ordering stated by pwm_round_waveform_might_sleep() documentation is
> > period_length_ns, duty_length_ns and then duty_offset_ns, but what about
> > duty steps?
> > It's not stated in there because it's not a user input, but still, it's a
> > quite important value for a pulse width *modulator*.
>
> From my POV as someone who cares about many PWM lowlevel drivers, it
> would be ideal if there would be a generic function that only relies on
> conforming and ideally simple lowlevel drivers and work out a good
> period that makes the required amount of duty steps available.
>
> When I designed the requirements for the round-to-hw function I had in
> mind that it should be possible to find the next higher possible period
> for a given lower bound (and that works, only lacks implementation).
> Working out a period that has finegrained duty steps is harder but
> doable:
>
> But something like that should work:
>
>  - Pick a period P
>  - P*, D*, _ = round_to_hw(period=P, duty_cycle=P-1, duty_offset=0)
>  - Either take P* - D* as a measure for the finegrainedness, or continue
>    to research available steps using round_to_hw(period=P*,
>    duty_cycle=P*-1, duty_offset=0)
>  - If there are too little steps pick a different P and retry.

Thanks, that makes sense. A generic helper could build on the existing
rounding contract to select a period with the required duty resolution.

That looks fairly involved to get right across different controllers,
particularly defining the resolution requirement and keeping the search
bounded. I'd prefer to tackle it as a separate follow-up after the H616
series is merged, if that separation sounds reasonable to you.

For this series, I'll keep the driver following the existing period,
duty-length and offset rounding rules. Do you see any remaining issues
with v10 that need to be addressed before it can be merged?

>
> Best regards
> Uwe