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

On Thu, Jun 01, 2023 at 09:41:30PM +0200, Jernej Škrabec wrote:

Dne četrtek, 01. junij 2023 ob 07:16:45 CEST je Frank Oltmanns napisal(a):

quoted

Re: Why speed up factor calculation?
====================================
I'm not aware that the current implementation of calculating n, k, and m
poses a bottleneck in any situation. Again, while going through the
code, I wondered why not save a few CPU cycles by precalculating the
meaningful combinations. In my opinion, it does not have any side
effects, so we might as well do it. (There is of course the side effect
of using a higher rate, but this is unrelated to precalculation as I
could as well employ a rate comparison that only allows lower rates, or
only optionally higher rates.)

quoted

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".

Sure, I get that.

As I stated in my cover letter:
"The motivation for these proposed changes lies in the current behavior
of rate selection for NKM clocks, which doesn't observe the
CLK_SET_RATE_PARENT flag. I.e. it does not select a different rate for
the parent clock to find the optimal rate."

I thought that this required this optimization to be implemented, but by
now, I'm no longer sure. I'll probably continue investigating different
paths for CLK_SET_RATE_PARENT for NKM clocks and follow up with new
findings.

Let's leave out any optimizations that are not apparently needed. Most clock
rates are set only once at boot and others, like video clocks, not that often,
so a suboptimal code speed doesn't hurt currently.

I'm not even sure we can make that assumption for video clocks. We might
for a panel, but for a more "dynamic" output like HDMI all bets are off
and depending on the monitor, the user settings and the userspace stack
we can definitely expect the video clock to change quite frequently.

Maxime