Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp25828125rwd; Mon, 3 Jul 2023 01:22:22 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7mQYfKY9pBz6oWYPrTLEA2ONDY+pZZ0luGrTm7GJ5VD7ZAUMgHIfUWVKgZGd+f486bkAs6 X-Received: by 2002:a05:6808:23d3:b0:3a3:7c33:9a0d with SMTP id bq19-20020a05680823d300b003a37c339a0dmr8754677oib.48.1688372541954; Mon, 03 Jul 2023 01:22:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688372541; cv=none; d=google.com; s=arc-20160816; b=zuey1C9rjOAbGKO7OY9lIuy4wwQygSlXcstzm0LdxLioNWhRRLQqm31erDSZiqj9z/ wOYdXwzmXv+OJHWHetT1HzCpV+GDCtBOAnRlr+wpNtuzaZ9kis2IT6jx2mQ2ISK/zLmZ oe4OWtHrJ7ru8S2Q8hxdwp6hOYiN+zuO81SIHKkHIcJ1lMqcdIc+AzUL9voG6RhxxNHn Fwexfnl4UN/ta4XxYd9d//f+E/MmSbmrw3S/UVfNSemN3wM+kq8sIHssXHM5JqrlbG6U isAAErxuIBMTt4IF41Pol8mhgKCLcarCbCmHTUYC89ogrrorFMIox9ZxqhRRle52U3nX RzAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:in-reply-to:subject :cc:to:from:references:dkim-signature; bh=eJqGcK86nu+Tj/k/Nnx0V17iyu2NlxwPh1TXpPUIkuI=; fh=x0Sr7i4tdKzpSyMcbWiDYTry/Z4x5er71rbOC3DCB9M=; b=KVxWLO6gw8kQv6vAGUDZxe8oBsNYJXwNCV4fPcPYBhAwZHpI/wDjBLxfHv7dgPD9+T XqIwi+dS+QJVvIbS3s9IqLRCQJwQun4VYz2NGRY02ghp8Zb+0HFK+8LZv323XtWAHFVA kx7FGJ7lvuKJ0N7CVjlYnbudwaCEPngH6qx9w8FNJbDTjJQI3ZzoT+a3s2AT8VMB3K1e H63/71Sox4Y9w2SrK7ioOeLEF6eOziDnCxL8W3TZqU3skIYrNGCofVIbxVLZ5UO8O+jX TPjsTh/FyCSUdXv5FFz5um9hxtv5/GUBfoDwReo2ZnkIqvNQEd/IWdtuF98smJkGBJGj o61Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oltmanns.dev header.s=MBO0001 header.b=TiBzr8Cj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m9-20020a654389000000b0053f3d04e66csi17329109pgp.699.2023.07.03.01.22.07; Mon, 03 Jul 2023 01:22:21 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@oltmanns.dev header.s=MBO0001 header.b=TiBzr8Cj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oltmanns.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230363AbjGCIDL (ORCPT + 99 others); Mon, 3 Jul 2023 04:03:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231126AbjGCICn (ORCPT ); Mon, 3 Jul 2023 04:02:43 -0400 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [IPv6:2001:67c:2050:0:465::101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9E8B1994; Mon, 3 Jul 2023 01:02:20 -0700 (PDT) Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4QvdgX1rWXz9smc; Mon, 3 Jul 2023 10:02:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1688371336; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eJqGcK86nu+Tj/k/Nnx0V17iyu2NlxwPh1TXpPUIkuI=; b=TiBzr8CjGgz8pvWu3Eh6dO/ajYlZTZAIzZ7DqPZog9OojLFxJDXquWD2onATkCrhscI3ds aofx4mW9TDYwXadTnlfnA4+SoqztiVWUWEym7hE8ugNzBSOcMIzPHDWWmMtia6TtILYQ3P GgeTlk1PEbdLqx62ajGk4PbEo+BCcqljdxgVdmyN6xRta5WEDIdws2ukTOcfzGRE0fqUr7 fGd7DmJzUq5h8KhOr6ndmKqXEfgjBW677pAHmsv8aBzvYfDRUqiQ/o8UtK8Iejk43JHuzW BAJXL6RNPoClDboSCysw7FeCdjO2K4ZzUOfeoGG5fFAThb3y9a/EKdTbJq2j0A== References: <20230702-pll-mipi_set_rate_parent-v3-0-46dcb8aa9cbc@oltmanns.dev> <20230702-pll-mipi_set_rate_parent-v3-1-46dcb8aa9cbc@oltmanns.dev> From: Frank Oltmanns To: Maxime Ripard Cc: Michael Turquette , Stephen Boyd , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Andre Przywara , Roman Beranek , linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/8] clk: sunxi-ng: nkm: consider alternative parent rates when determining rate In-reply-to: Date: Mon, 03 Jul 2023 10:02:12 +0200 Message-ID: <87sfa5s9rv.fsf@oltmanns.dev> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-07-03 at 08:47:43 +0200, Maxime Ripard wrote: > [[PGP Signed Part:Undecided]] > Hi, > > On Sun, Jul 02, 2023 at 07:55:20PM +0200, Frank Oltmanns wrote: >> In case the CLK_SET_RATE_PARENT flag is set, consider using a different >> parent rate when determining a new rate. >> >> To find the best match for the requested rate, perform the following >> steps for each NKM combination: >> - calculate the optimal parent rate, >> - find the best parent rate that the parent clock actually supports >> - use that parent rate to calculate the effective rate. >> >> In case the clk does not support setting the parent rate, use the same >> algorithm as before. >> >> Signed-off-by: Frank Oltmanns >> --- >> drivers/clk/sunxi-ng/ccu_nkm.c | 48 +++++++++++++++++++++++++++++++++++++++--- >> 1 file changed, 45 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c >> index a0978a50edae..d83843e69c25 100644 >> --- a/drivers/clk/sunxi-ng/ccu_nkm.c >> +++ b/drivers/clk/sunxi-ng/ccu_nkm.c >> @@ -6,6 +6,7 @@ >> >> #include >> #include >> +#include >> >> #include "ccu_gate.h" >> #include "ccu_nkm.h" >> @@ -16,6 +17,44 @@ struct _ccu_nkm { >> unsigned long m, min_m, max_m; >> }; >> >> +static unsigned long ccu_nkm_find_best_with_parent_adj(unsigned long *parent, unsigned long rate, >> + struct _ccu_nkm *nkm, struct clk_hw *phw) > > The usual order in that driver (and Linux in general) would make the > clk_hw and nkm structure pointers first, and then the parent rate and > rate. I'll address that in v4. > > But something looks off to me: ccu_nkm_find_best_with_parent_adj takes a > pointer to the parent rate which makes sense since we're going to modify > it. > >> +{ >> + unsigned long best_rate = 0, best_parent_rate = *parent, tmp_parent = *parent; >> + unsigned long best_n = 0, best_k = 0, best_m = 0; >> + unsigned long _n, _k, _m; >> + >> + for (_k = nkm->min_k; _k <= nkm->max_k; _k++) { >> + for (_n = nkm->min_n; _n <= nkm->max_n; _n++) { >> + for (_m = nkm->min_m; _m <= nkm->max_m; _m++) { >> + unsigned long tmp_rate; >> + >> + tmp_parent = clk_hw_round_rate(phw, rate * _m / (_n * _k)); >> + >> + tmp_rate = tmp_parent * _n * _k / _m; >> + if (tmp_rate > rate) >> + continue; >> + >> + if ((rate - tmp_rate) < (rate - best_rate)) { >> + best_rate = tmp_rate; >> + best_parent_rate = tmp_parent; >> + best_n = _n; >> + best_k = _k; >> + best_m = _m; >> + } >> + } >> + } >> + } >> + >> + nkm->n = best_n; >> + nkm->k = best_k; >> + nkm->m = best_m; >> + >> + *parent = best_parent_rate; >> + >> + return best_rate; >> +} >> + >> static unsigned long ccu_nkm_find_best(unsigned long parent, unsigned long rate, >> struct _ccu_nkm *nkm) > > You haven't modified ccu_nkm_find_best though, and it still takes the > parent rate value. > >> { >> @@ -106,7 +145,7 @@ static unsigned long ccu_nkm_recalc_rate(struct clk_hw *hw, >> } >> >> static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux, >> - struct clk_hw *hw, >> + struct clk_hw *parent_hw, > > (This should be another patch) Ok, will do in v4. > >> unsigned long *parent_rate, >> unsigned long rate, >> void *data) >> @@ -124,7 +163,10 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux, >> if (nkm->common.features & CCU_FEATURE_FIXED_POSTDIV) >> rate *= nkm->fixed_post_div; >> >> - rate = ccu_nkm_find_best(*parent_rate, rate, &_nkm); > > parent_rate is a pointer, we were dereferencing it to pass its value to > ccu_nkm_find_best. All good so far. > >> + if (!clk_hw_can_set_rate_parent(&nkm->common.hw)) >> + rate = ccu_nkm_find_best(*parent_rate, rate, &_nkm); > > Still passing by value > >> + else >> + rate = ccu_nkm_find_best_with_parent_adj(parent_rate, rate, &_nkm, parent_hw); > > And passing the pointer there since it takes a pointer. Still good. > >> >> if (nkm->common.features & CCU_FEATURE_FIXED_POSTDIV) >> rate /= nkm->fixed_post_div; >> @@ -159,7 +201,7 @@ static int ccu_nkm_set_rate(struct clk_hw *hw, unsigned long rate, >> _nkm.min_m = 1; >> _nkm.max_m = nkm->m.max ?: 1 << nkm->m.width; >> >> - ccu_nkm_find_best(parent_rate, rate, &_nkm); >> + ccu_nkm_find_best(&parent_rate, rate, &_nkm); > > But here, we're passing a pointer to parent_rate to ccu_nkm_find_best, > while it's still supposed to take it by value? Ugh. Yeah, sorry. I had that error in V2 but squashed the correction into patch 5 instead of patch 1. I'll fix that in v4. Thanks, Frank > > Maxime > > [[End of PGP Signed Part]]