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

[Frank Oltmanns]

Hi Jernej,
hi Maxime,

On 2023-06-02 at 09:34:03 +0200, Maxime Ripard <mripard at kernel.org> wrote:
> [[PGP Signed Part:Undecided]]
> 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):
>> > 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.)
>> >
>> > > 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.

Thank you both for your valuable feedback!

The goal I head in mind was adjusting pll-video0's clock when setting
DCLK on Allwinner A64. And you're both right, I got sidetracked by
premature optimizations.

As I wrote elsewhere in this thread, I will submit a patchset for the
original goal and we can discuss potential needs for optimization there.

Thanks,
  Frank

>
> Maxime
>
> [[End of PGP Signed Part]]