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:   Mon, 12 Jun 2023 10:53:05 +0200
From:   Maxime Ripard <maxime@cerno.tech>
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 0/2] clk: sunxi-ng: Consider alternative parent rates
 when determining NKM clock rate
Message-ID: <pk3som3qkrs66hk3hf6zczmd5hqsrb5u2pkmolngqinjm7b753@27vlqdbxemwa>
References: <20230605190745.366882-1-frank@oltmanns.dev>
 <87legv2093.fsf@oltmanns.dev>
 <vvmdk3fqtjt3jspxgvlbypdxajchymydshya5b5ivk3wfodwwr@yyi26m6toosh>
 <871qim1eow.fsf@oltmanns.dev>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <871qim1eow.fsf@oltmanns.dev>
Precedence: bulk

On Thu, Jun 08, 2023 at 11:29:05AM +0200, Frank Oltmanns wrote:
> On 2023-06-07 at 14:27:46 +0200, Maxime Ripard <maxime@cerno.tech> wrote:
> > [[PGP Signed Part:Undecided]]
> > On Wed, Jun 07, 2023 at 09:35:20AM +0200, Frank Oltmanns wrote:
> >> So, my question: Is spending the 30 ms fine or do I need to optimize f=
or
> >> speed in order for this patchset to be accepted? Or is 2 ms also too
> >> much of an increase, in which case I'm out of ideas. :-)
> >
> > You keep mentioning it, but it's really not clear to me why you think
> > that both are intertwined, or depend on one another?
>=20
> I'm sorry about that. I guess, I got carried away. And furthermore I
> took your mentioning of all bets being of how often setting rates
> happens when HDMI comes into play as encouragement to optimize for
> speed, which it clearly wasn't.
>=20
> I saw the increase in time as a regression, because it might break
> boards that I don't have access to. But since you say it's fine, I'll
> speak no more of it.

I'm not really saying it's fine, I guess I'm saying it's fine until
proven otherwise :)

Maxime