[RFC PATCH 0/3] clk: sunxi-ng: Optimize rate selection for NKM clocks

[Maxime Ripard]

Hi Frank,

On Sat, May 27, 2023 at 03:27:44PM +0200, Frank Oltmanns wrote:
> I would like to bring your attention to the current process of setting
> the rate of an NKM clock. As it stands, when setting the rate of an
> NKM clock, the rate nearest but less than or equal to the requested
> rate is found, instead of the nearest rate.

Yeah, it's actually pretty common, see clk_mux_determine_rate_flags()
for example. Some devices require that we don't overshoot, while some
prefer to have the closest rate.

Both are fine, and it's a bit context specific which one we should
favour. If we were to do anything, it would be to support both and let
the clock driver select which behaviour it wants.

> Moreover, ccu_nkm_find_best() is called multiple times (footnote [1])
> when setting a rate, each time iterating over all combinations of n,
> k, and m.

Yeah, that's expected as well.

> In response to this, I propose the following refinements to optimize the NKM
> clock setting:
>  a. when finding the best rate use the nearest rate, even if it is greater than
>     the requested rate (PATCH 1)
>  b. utilize binary search to find the best rate by going through a
>     precalculated, ordered list of all meaningful combinations of n, k, and m
>     (PATCH 2)

One thing you haven't really addressed is why we would be doing this? Is
there some clocks that require a more precise clock and don't? Is the
factor calculation a bottleneck for some workloads?

Clocks in general are very regression-prone, so I'd rather be a bit
conservative there, and "if it ain't broke, don't fix it".

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230531/c3aa13a3/attachment-0001.sig>