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;
Feedback-ID: i8771445c:Fastmail
Date:   Tue, 13 Jun 2023 17:30:06 +0200
To:     Frank Oltmanns <frank@oltmanns.dev>
Cc:     Andre Przywara <andre.przywara@arm.com>,
        Chen-Yu Tsai <wens@csie.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Michael Turquette <mturquette@baylibre.com>,
        Roman Beranek <me@crly.cz>,
        Samuel Holland <samuel@sholland.org>,
        Stephen Boyd <sboyd@kernel.org>,
        linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH 1/2] clk: sunxi-ng: nkm: consider alternative parent
 rates when finding rate
Message-ID: <wnxjbbjfcnrg7ogwkfwbnldvyqbpt23b6mnrieb2zffooaojts@sudsbfjbjt64>
From:   Maxime Ripard <maxime@cerno.tech>
References: <20230605190745.366882-1-frank@oltmanns.dev>
 <20230605190745.366882-2-frank@oltmanns.dev>
 <2bvcukogzhcdbfsrruylgw5fbezaqjpcojqaambfoiv5fc2upy@ffumn5sevbeb>
 <875y7y1f0d.fsf@oltmanns.dev>
 <sijbhopoxuw5wodyry3smg7tm4wzoc7k6xakt4qdvxqsok32mv@u7rh4dct5ya6>
 <87a5x41w5r.fsf@oltmanns.dev>
 <unoskbtcteluxj7g3xkwc7ngcmglvcbm5ah25m7huhqxwd4dj3@nmfxbedwyu54>
 <87wn07zmxp.fsf@oltmanns.dev>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="cghg4gjbgxgwxw55"
Content-Disposition: inline
In-Reply-To: <87wn07zmxp.fsf@oltmanns.dev>
Precedence: bulk


--cghg4gjbgxgwxw55
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 13, 2023 at 12:17:06PM +0200, Frank Oltmanns wrote:
> Hi Maxime,
>=20
> I'll now only respond to one aspect of your mail, because it's the
> foundation for the whole behaviour.
>=20
> On 2023-06-13 at 11:10:08 +0200, Maxime Ripard <maxime@cerno.tech> wrote:
> [...]
> >> >> ccu_nkm_find_best is called in the following two situations:
> >> >>  a. from ccu_nkm_set_rate when setting the rate
> >> >>  b. from ccu_nkm_round_rate when determining the rate
> >> >>
> >> >> In situation a. we never want ccu_nkm_find_best to try different pa=
rent
> >> >> rates because setting the parent rate is a done deal (at least that=
's my
> >> >> understanding).
> >> >>
> >> >> In situation b. we only want ccu_nkm_find_best to try different par=
ent
> >> >> rates when, as you mentioned, the CLK_SET_RATE_PARENT flag is set.
> >> >
> >> > It doesn't really matter though. The output of that function must be
> >> > stable and must return the same set of factors and parent rate for a
> >> > given target rate.
> >> >
> >>
> >> I'm not sure if we're talking about the same thing here. Of course the
> >> set of factors and parent rate for a given target rate will be differe=
nt
> >> depending on the fact if we can or cannot adjust the parent rate,
> >> agreed?
> >
> > Yes, but here you also have a different behaviour in clk_round_rate()
> > and in clk_set_rate(), which isn't ok.
> >
> > Basically, clk_set_rate() + clk_get_rate() must be equal to
> > clk_round_rate().
> >
> > If you change if you look for parents depending on whether you're being
> > called in clk_round_rate() and clk_set_rate(), then you're breaking that
> > expectation.
> >
> >> Let me compare my implementation to ccu_mp.
> >>
> >> ccu_mp_round_rate either calls the function ccu_mp_find_best or
> >> ccu_mp_find_best_with_parent_adj, depending on CLK_SET_RATE_PARENT.
> >
> > Yes, and it's fine: the flag is per-clock, and the output is the same
> > depending on whether we're being called by clk_round_rate() and
> > clk_set_rate().
> >
>=20
> The output is really not the same.
>=20
> ccu_mp_set_rate() always calls ccu_mp_find_best(). It never (!) considers
> changing the parent, independent of any flags.
>=20
> ccu_mp_round_rate() is calling ccu_mp_find_best() OR
> ccu_mp_find_best_with_parent_adj() depending on the flag.
>=20
> If I understand you correctly, you consider that a bug.

No, sorry, you're right.

clk_set_rate will call round_rate first, which will (possibly) pick up a
new parent, and by the time set_rate is called our parent will have been
changed already so we will just call find_best again considering only
that parent.

The set of factors and dividers should remain the same there, but I
don't think that's a concern.

That leaves us with the rounding stuff, and the overall function
arguments. I like the structure of ccu_mp better, is there a reason to
deviate from it?

Maxime

--cghg4gjbgxgwxw55
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZIiLeQAKCRDj7w1vZxhR
xZwOAP0V27baWBPmfpGaKZQrnd/GOqaGcGGZZuCPI3ZDiH4lzAD/RqTkEXmNCeP+
vkcuc67x9IsePwvMFq3jBor1njpnVgc=
=84G2
-----END PGP SIGNATURE-----

--cghg4gjbgxgwxw55--