From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DA6E4EB64DC for ; Mon, 3 Jul 2023 09:18:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date: In-reply-to:Subject:Cc:To:From:References:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=sqqTcoyqO2mIZ68WdsYvbZbxNpUTxHGM+bkbKYEgv8k=; b=NS0k535+M8OFiVvWtVcMZU76cU BuHs9wuUWeBxqHvyBVkPu7jJD8M+ICTvQYvq94ICyymwIv4FaR3/lTYkyt9bFWFzCcqBhSNBeBAAl VBXv5DrQ7sq4UGAMY5hpDmqe4H28+tPfdjc4PJ2rIs6zUn2fWJUmU798URQUvviMdOK8muvrfevSs RRDr5UzKyBBUzp/FOJZxKYmB+lgvRr9zhmhUwwlJLa0h/MlB6CXLtfTkZPoe3CYL+5McfYiLJU5Dy Xr6aUasTk4HjB7ydzzuEVEQ7o6qUopnx6n9W+QpVJ/Q+U2uoTuTp0DXB5QG1WwqRGo9dhKJVLOeGq Yk8iOiBw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qGFh4-009tqk-2J; Mon, 03 Jul 2023 09:18:02 +0000 Received: from mout-p-101.mailbox.org ([2001:67c:2050:0:465::101]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qGFh1-009tod-2h for linux-arm-kernel@lists.infradead.org; Mon, 03 Jul 2023 09:18:01 +0000 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (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 4QvgLZ490vz9sqJ; Mon, 3 Jul 2023 11:17:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oltmanns.dev; s=MBO0001; t=1688375862; 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=wzL5L1lBY5rqvf78gNGZQXkCiKNDPWm58F8aOJ0dj7I=; b=G0ywYUvJ5zFc39jBJU87AUoesBe8B95rVsm9BKiVgv+kPdQO/Ep9vKlEOKYnlQnH/UYifx twGWoW8qkjEYbiQEg1riRhCP85B/BW/XuyAlMMf9nLprqZD+B+hxCRnNcJgfP6bCi/Ev50 iShVRoQxQZ3LF0Jnxl277TobXcWIOhyLhL7dJ3F60jENETfxIkaNLnN7vVtjkLpEAEloCs nchnT5/G3+XyrSTUGFsDx6nSbcArbr06pX1eLKJliPorsBMKYlmujMFi8o7mihP2rv8wob tIEiq6uZyKMbAjZujN4L0h6iDcWRlLTIb7ak1O3cwHiHCnQ4DZdKLfAAt2A4bQ== References: <20230702-pll-mipi_set_rate_parent-v3-0-46dcb8aa9cbc@oltmanns.dev> <20230702-pll-mipi_set_rate_parent-v3-6-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 6/8] clk: sunxi-ng: mux: Support finding closest rate In-reply-to: Date: Mon, 03 Jul 2023 11:17:24 +0200 Message-ID: <87fs65s6aj.fsf@oltmanns.dev> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230703_021800_086713_5FAF30CD X-CRM114-Status: GOOD ( 25.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2023-07-03 at 09:38:48 +0200, Maxime Ripard wrote: > [[PGP Signed Part:Undecided]] > On Sun, Jul 02, 2023 at 07:55:25PM +0200, Frank Oltmanns wrote: >> When finding the best rate for a mux clock, consider rates that are >> higher than the requested rate by introducing a new clk_ops structure >> that uses the existing __clk_mux_determine_rate_closest function. >> Furthermore introduce an initialization macro that uses this new >> structure. >> >> Signed-off-by: Frank Oltmanns >> --- >> drivers/clk/sunxi-ng/ccu_mux.c | 13 +++++++++++++ >> drivers/clk/sunxi-ng/ccu_mux.h | 17 +++++++++++++++++ >> 2 files changed, 30 insertions(+) >> >> diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c >> index 8594d6a4addd..49a592bdeacf 100644 >> --- a/drivers/clk/sunxi-ng/ccu_mux.c >> +++ b/drivers/clk/sunxi-ng/ccu_mux.c >> @@ -264,6 +264,19 @@ static unsigned long ccu_mux_recalc_rate(struct clk_hw *hw, >> parent_rate); >> } >> >> +const struct clk_ops ccu_mux_closest_ops = { >> + .disable = ccu_mux_disable, >> + .enable = ccu_mux_enable, >> + .is_enabled = ccu_mux_is_enabled, >> + >> + .get_parent = ccu_mux_get_parent, >> + .set_parent = ccu_mux_set_parent, >> + >> + .determine_rate = __clk_mux_determine_rate_closest, >> + .recalc_rate = ccu_mux_recalc_rate, >> +}; >> +EXPORT_SYMBOL_NS_GPL(ccu_mux_closest_ops, SUNXI_CCU); >> + > > This is also a bit inconsistent with the other clocks: most (all?) of > them will simply handle this through a flag, but this one requires a new > set of clk_ops as well? > > I think we should create our own wrapper here around > __clk_mux_determine_rate and either call > __clk_mux_determine_rate_closest or __clk_mux_determine_rate depending > on the state of the flags, or call __clk_mux_determine_rate_flags with > the proper flags set for our clock. > > The former is probably slightly simpler. Ok, I will address that in v4. > >> const struct clk_ops ccu_mux_ops = { >> .disable = ccu_mux_disable, >> .enable = ccu_mux_enable, >> diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h >> index 2c1811a445b0..c4ee14e43719 100644 >> --- a/drivers/clk/sunxi-ng/ccu_mux.h >> +++ b/drivers/clk/sunxi-ng/ccu_mux.h >> @@ -46,6 +46,22 @@ struct ccu_mux { >> struct ccu_common common; >> }; >> >> +#define SUNXI_CCU_MUX_TABLE_WITH_GATE_CLOSEST(_struct, _name, _parents, _table, \ >> + _reg, _shift, _width, _gate, \ >> + _flags) \ >> + struct ccu_mux _struct = { \ >> + .enable = _gate, \ >> + .mux = _SUNXI_CCU_MUX_TABLE(_shift, _width, _table), \ >> + .common = { \ >> + .reg = _reg, \ >> + .hw.init = CLK_HW_INIT_PARENTS(_name, \ >> + _parents, \ >> + &ccu_mux_closest_ops, \ >> + _flags), \ >> + .features = CCU_FEATURE_CLOSEST_RATE, \ >> + } \ >> + } >> + > > I'm fine with that one, but like we discussed on the NM (I think?) patch > already, this creates some clocks and macros that will use the feature > as a flag, and some will encode it into their name. > > Given that we need it here too, I'm really inclined to prefer what you > did there, and thus create a new macro for pll-video0 instead of > modifying the existing one. Ok. Just to be clear: What I did in this patch is fine and I should use the same approach for NM. Did I get that right? Thanks, Frank > > Maxime > > [[End of PGP Signed Part]] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel