From patchwork Fri May 5 11:25:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxime Ripard X-Patchwork-Id: 13232483 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 A4284C77B7F for ; Fri, 5 May 2023 11:29:09 +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:Cc:To:In-Reply-To:References:Message-Id :MIME-Version:Subject:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=uJjCaFgBeMEQfIVejWss9ThEcDxHv7kOL6vdYzPpshY=; b=enf1WcnOczDCF7 Y3ieMGw5ytfHLk3+6oKiS00PFN9QQo5tUm7vveAcDNrvoTeECQTIFbCYmui0VpaYARl4lUKl3sf4D uh78ZfdUruapyJSIYgWN1/ne5ZdtgNOEokPXdlfKysirBMyhwnYBs74zOyCk4YJZN1JTqC9ZjiF0b lSt22eN90zojtFaPu3rxTN6BazwaO0yLx9+yjmSHnMlXdX0g0P5oLZ2vRHQKWIHxQnG+mTcmvfDgF IhR0aFAVQxGtidjt/Q8YdQM4BetuRgDyOoaNRc09xBMm0zY38OAqJnqmbsQQXs3bIsnnLyxmcsws1 eFTQeExBRewEh1Q/jwtg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1putbb-00Ag5u-2q; Fri, 05 May 2023 11:28:07 +0000 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1putbV-00Ag2D-1b for linux-arm-kernel@lists.infradead.org; Fri, 05 May 2023 11:28:05 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 115943200A60; Fri, 5 May 2023 07:28:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 05 May 2023 07:28:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1683286079; x=1683372479; bh=GKKf9EhaXnod3gyBbs+J+eUBVfhftHN+tr+ h5ZiCjC8=; b=kbHFdePpG/Gw+jbXUa3N+59OdNbjWCGnY7Cu7w0JiZJ7pLYILm8 vDbvyTjq6fOcKNHwATv7V+Punxh0CEHbch7BiOgl3RaNUBzvoPNEFEH1g2Yey8DW eoJd6FzbUTmDkEjPwbRhhNR0oR3azfNoEjurtDQKkW8Kx5vjH1khLn21NkqGX6Tq TSR3ohItxvZOm83oKxY5iW9ioy5Cslx5EAx2BMpWT31BYk+RuqfMQ8mtMkLtK+Cs Umbqm8XbvLq3hlHI6U6cVUpv1Z1joElbamz/yXjbtatdOpSd8QwUXeSlW5YvuUMV VJiwciI726CKODf5gxYmTtLb7m4FpO2neNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1683286079; x=1683372479; bh=GKKf9EhaXnod3gyBbs+J+eUBVfhftHN+tr+ h5ZiCjC8=; b=VQSdl3StcDi4VuqmS+qnbmXi42yDUbAbtTyVcx41J8Gv1C7x0yg v3BNe1khACFWAEBGnkPioylZPKsVrRbbjlXuxXzLS+rhvQqrQ6/L9sM4dEuIwPpm kg9U8dCxMMV8n3zrO27NJ8Cucqvl9Lgl+xsHXphesxlaE+Qd9gIVfMao6gccfSyM icIIRxM5IwBmrFqjnXeAS2bynlJiXwoAc0aRh3y3/Co7tJo0g5wvqUCY5+xr/lzO ZM2towkOZJbPBRMXGJikzv/I2Lf78+kogii1ERuKTftPfRFqBMPkDicU9BpIqh03 0IKVu3ngYN8x6x4wGZLGACEF02+RYhw+bLA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeefvddggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfffufggtgfgkfhfjgfvvefosehtjeertdertdejnecuhfhrohhmpeforgig ihhmvgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrf grthhtvghrnhepvedvleeijeegvdekffehkeehieelhfeggfffheetkeeuledvtdeuffeh teeltdffnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomh epmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 5 May 2023 07:27:58 -0400 (EDT) From: Maxime Ripard Date: Fri, 05 May 2023 13:25:47 +0200 Subject: [PATCH v4 45/68] rtc: sun6i: Add a determine_rate hook MIME-Version: 1.0 Message-Id: <20221018-clk-range-checks-fixes-v4-45-971d5077e7d2@cerno.tech> References: <20221018-clk-range-checks-fixes-v4-0-971d5077e7d2@cerno.tech> In-Reply-To: <20221018-clk-range-checks-fixes-v4-0-971d5077e7d2@cerno.tech> To: Michael Turquette , Stephen Boyd Cc: linux-clk@vger.kernel.org, Maxime Ripard , Alessandro Zummo , Alexandre Belloni , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , linux-arm-kernel@lists.infradead.org, linux-rtc@vger.kernel.org, linux-sunxi@lists.linux.dev X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2434; i=maxime@cerno.tech; h=from:subject:message-id; bh=3Q4a/GiK9m4nbc17ziwEKJILlFgG0TnxAPcyIHI/6dg=; b=owGbwMvMwCX2+D1vfrpE4FHG02pJDCkhz5d0iC+vOvuh+erPO47+UwKe3ag7Ne8JU2d16s92qaZV Fyd2dZSyMIhxMciKKbLECJsviTs163UnG988mDmsTCBDGLg4BWAihmcZGS6u8GTslXq+ppOt98rWyZ rF7BL521e7spZwuO4U2HO6N5DhF/ObEiW/j/GiF9QK5k5bEOchfrrjZcKpmf139+jI7dW/wgwA X-Developer-Key: i=maxime@cerno.tech; a=openpgp; fpr=BE5675C37E818C8B5764241C254BCFC56BF6CE8D X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230505_042801_620065_525EEF43 X-CRM114-Status: GOOD ( 18.91 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The Allwinner sun6i RTC clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation. This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate. The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock. Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock. So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent(). The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise. And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line. Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: Chen-Yu Tsai Cc: Jernej Skrabec Cc: Samuel Holland Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rtc@vger.kernel.org Cc: linux-sunxi@lists.linux.dev Signed-off-by: Maxime Ripard Acked-by: Jernej Skrabec --- drivers/rtc/rtc-sun6i.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c index dc76537f1b62..71548dd59a3a 100644 --- a/drivers/rtc/rtc-sun6i.c +++ b/drivers/rtc/rtc-sun6i.c @@ -214,6 +214,7 @@ static int sun6i_rtc_osc_set_parent(struct clk_hw *hw, u8 index) static const struct clk_ops sun6i_rtc_osc_ops = { .recalc_rate = sun6i_rtc_osc_recalc_rate, + .determine_rate = clk_hw_determine_rate_no_reparent, .get_parent = sun6i_rtc_osc_get_parent, .set_parent = sun6i_rtc_osc_set_parent,