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

On 7/31/26 9:05 AM, Stephane Lepain wrote:
> From: Kenneth Kasilag <[email protected]>
> 
> 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