Re: [PATCH RFC 2/4] clk: rockchip: pll: use round-nearest in determine_rate

[Heiko Stuebner <heiko@sntech.de>]

Hi Alexey,

Am Freitag, 17. April 2026, 17:11:45 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> rockchip_pll_determine_rate() walks the rate table in descending order
> and picks the first entry <= the requested rate. This floor-rounding
> interacts poorly with consumers that use CLK_SET_RATE_PARENT: a divider
> iterating candidates asks the PLL for rate*div, and a tiny undershoot
> causes the PLL to snap to a much lower entry.
> 
> For example, requesting 1991.04 MHz (248.88 MHz * 8) causes the PLL to
> return 1968 MHz instead of 1992 MHz — a 24 MHz table gap that produces
> a 1.2% pixel clock error when divided back down.
> 
> Change to round-to-nearest: for each table entry compute the absolute
> distance from the request, and pick the entry with the smallest delta.
> The CCF's divider and composite logic handle over/undershoot preferences
> via their own ROUND_CLOSEST flags.
> 
> Signed-off-by: Alexey Charkov <alchark@flipper.net>

as Sebastian said, this could cause overclocking in a number of areas.
The rate you get should always be lower or equal to the requested rate.

Additionally, such a core behaviour change, would affect 13 years of
SoCs with unknown side-effects.

If you're missing specific clock rates, you can always add them to the
list :-) . The vendor-kernel does have code that can calculate the
rate params itself, so this could give you a hint where to start.

======= just to explain =======

Though I still don't think that code should be in the mainline-kernel,
as a curated PLL rates allows more control, where that algorithm
creates parameters that are programmatically correct, but essentially
untested.

On the two Chromebook projects, they actually measured things like
clock jitter, which got us more specific params for some rates.


Heiko