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

From: Maxime Ripard <mripard@kernel.org>
To: "Jernej Škrabec" <jernej.skrabec@gmail.com>
Cc: Frank Oltmanns <frank@oltmanns.dev>,
	 linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org,  linux-sunxi@lists.linux.dev,
	Andre Przywara <andre.przywara@arm.com>,
	 Chen-Yu Tsai <wens@csie.org>, Icenowy Zheng <icenowy@aosc.io>,
	 Michael Turquette <mturquette@baylibre.com>,
	Rob Herring <robh@kernel.org>,
	 Samuel Holland <samuel@sholland.org>,
	Stephen Boyd <sboyd@kernel.org>
Subject: Re: [RFC PATCH 0/3] clk: sunxi-ng: Optimize rate selection for NKM clocks
Date: Fri, 2 Jun 2023 09:34:03 +0200	[thread overview]
Message-ID: <bhjq4yxo7fvddq3kvvvbgefhyaygb5bwkzhsjp3adc5kp7ohtx@iclghpep3zkw> (raw)
In-Reply-To: <4831731.31r3eYUQgx@jernej-laptop>

[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]

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.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]