Re: [PATCH] pwm: ipq: fix period calculation

From: Konrad Dybcio

Date: Fri Jul 31 2026 - 11:34:48 EST


On 7/31/26 9:05 AM, Stephane Lepain wrote:
> From: Kenneth Kasilag <kenneth@xxxxxxxxxx>
>
> ipq_pwm_apply() fixes pwm_div at its maximum and derives only pre_div
> from the requested period. Since the period spans
> (pre_div + 1) * (pwm_div + 1) input clocks, pinning pwm_div near its
> maximum forces pre_div towards zero for short periods: once pre_div
> rounds to 0 the shortest representable period is (pwm_div + 1) / clk_rate,
> and any shorter request is rejected outright:

[...]

> /*
> - * Pick the maximal value for PWM_DIV that still allows a
> - * 100% relative duty cycle. This allows a fine grained
> - * selection of duty cycles.
> + * The period spans (pre_div + 1) * (pwm_div + 1) input clocks. Rather
> + * than fixing pwm_div at its maximum (which gives usable duty
> + * resolution only for long periods and collapses to ~0% for short
> + * periods) search for the (pre_div, pwm_div) split whose period best
> + * approximates the request while leaving pwm_div large enough to
> + * resolve the duty cycle.
> */

I think the comment can just go

> - pwm_div = IPQ_PWM_MAX_DIV - 1;
> + if (ipq_chip->clk_rate > 16ULL * GIGA)
> + return -EINVAL;

That's a very fast clock..

[...]

> - hi_div = hi_dur * (pre_div + 1);
> + hi_div = (u64)hi_dur * (pre_div + 1);

This looks like a separate fix

Konrad