Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
References: <20230527132747.83196-1-frank@oltmanns.dev>
 <flngzi4henkzcpzwdexencdkw77h52g3nduup7pwctpwfiuznk@eewnnut5mvsq>
 <87mt1jbf18.fsf@oltmanns.dev> <4831731.31r3eYUQgx@jernej-laptop>
 <bhjq4yxo7fvddq3kvvvbgefhyaygb5bwkzhsjp3adc5kp7ohtx@iclghpep3zkw>
From:   Frank Oltmanns <frank@oltmanns.dev>
To:     Jernej =?utf-8?Q?=C5=A0krabec?= <jernej.skrabec@gmail.com>,
        Maxime Ripard <mripard@kernel.org>
Cc:     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
In-reply-to: <bhjq4yxo7fvddq3kvvvbgefhyaygb5bwkzhsjp3adc5kp7ohtx@iclghpep3zkw>
Date:   Mon, 05 Jun 2023 13:41:17 +0200
Message-ID: <877csi9lwi.fsf@oltmanns.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Jernej,
hi Maxime,

On 2023-06-02 at 09:34:03 +0200, Maxime Ripard <mripard@kernel.org> wrote:
> [[PGP Signed Part:Undecided]]
> On Thu, Jun 01, 2023 at 09:41:30PM +0200, Jernej =C5=A0krabec wrote:
>> Dne =C4=8Detrtek, 01. junij 2023 ob 07:16:45 CEST je Frank Oltmanns napi=
sal(a):
>> > Re: Why speed up factor calculation?
>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> > 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 c=
lock
>> 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]]