From patchwork Fri May 5 11:25:11 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxime Ripard X-Patchwork-Id: 13232472 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 23759C7EE22 for ; Fri, 5 May 2023 11:27:23 +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:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id: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=87/AYbA5zGrDjsEZym0v2gQOJdu8FWwIvYxfxHjQ6s8=; b=QSMhru1zfUQUu+ LkxwOzga06WGwfOMVJ0GkJNYyDX31/0NB4frS9LgJZkQ5oh3kAITYUk20ZtpuN01X4UJbI57HqlRa 7qYHyRWOLNUpMcRt9UIWTtOntPEC2S1QpWEbxy8f8rypkIZPpCsFePinsu/5b8At3/rMVQpHuIKUG dzcwX3vonT58RRqYd3vbXwWoonboV+LrLcE6EGZ48PDR4bTWJigAvWIuOj9W54RF+Vbdp3bFBWhbS SRpwgo+2iK2iayZ4MYQnVMFcYhCm9w08E8J/FKyOO9Ii8CZAPiFJuaQgNf8Kb3bEAKegAlYUOMu/C DdD/ESnnbnRKbHv+Qg6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1putZp-00AfBe-05; Fri, 05 May 2023 11:26:17 +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 1putZl-00AfAU-1E for linux-arm-kernel@lists.infradead.org; Fri, 05 May 2023 11:26:14 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 5D98E3200A52; Fri, 5 May 2023 07:26:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 05 May 2023 07:26:12 -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= 1683285971; x=1683372371; bh=m1472fUUYrOyi0qUKoAVXtkZC+K8EvbFPKp eLfxLubU=; b=fpwsbb5lKPLNI7c/qNIPRgSDx0XoUyspS0B5SnZ/0vhrAoEfGM6 aQ1TDIe+eMlLH0+EJmmMnxDy9rd+EGRA6PbqoiQ5sX/NaS3vyx9epQ5S3JmzDZ8s tBEGPIOZA+4mle3kSIT/JTWCKr/+UO+yKerQ3NPiiEO5Noy3LY8GuXGjKisgtjcH hpis+Yyg6KJFZFbbmFeHRJFStx9tov0jEnbuhbt20uJNz4OXPV07omL1X8sIyMst XFN87RutrZRqFB2VpDuig+erbbwrWa5OoQgPjWwMTkD8OXKSqBZgiAFxeKAU/Q7B h1Tl2gSq6p4Dy/xD0IzeH8gQ95vTVnLwAsA== 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= 1683285971; x=1683372371; bh=m1472fUUYrOyi0qUKoAVXtkZC+K8EvbFPKp eLfxLubU=; b=YRWl3QNiuTiEZ48r8tvAIs4j05BqYHsuVj+RbxhQ790wIJaFS0r CtD+vUtZUlaTIftC8NAPUCDC1eKGsSqtX5ChYhTZROA81O4T868O3UJZc+VbYIpx 5LjWDk3lBvkmgHi1QT5jO0pIO7bJPgtoHGInMRdMKunua4dHZj6lpfjW1nKCcuWF 4/f0tckUAbxB6LMY96A1RS4Kv2FzgNkC9vYj5txJI4Pd0XDHL60fecIBRPbhL7V6 ouwIfoj8KFHJG9Ru8ufKLxjIE+5Hdo0eUysr9Uq+k55T7927+AJGlbrsyFJqov6d tGhixYfOy7oLE5NPQNQhm95/XQIwk5NSK2w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeefvddggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfffufggtgfgkfhfjgfvvefosehtjeertdertdejnecuhfhrohhmpeforgig ihhmvgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrf grthhtvghrnhepvedvleeijeegvdekffehkeehieelhfeggfffheetkeeuledvtdeuffeh teeltdffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Feedback-ID: i8771445c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 5 May 2023 07:26:11 -0400 (EDT) From: Maxime Ripard Date: Fri, 05 May 2023 13:25:11 +0200 Subject: [PATCH v4 09/68] clk: at91: main: Add a determine_rate hook MIME-Version: 1.0 Message-Id: <20221018-clk-range-checks-fixes-v4-9-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 X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=openpgp-sha256; l=2380; i=maxime@cerno.tech; h=from:subject:message-id; bh=H9KRPCBcjEpoRfMcvh/lzMCqJMQ8acMLWyrCaLBibMo=; b=owGbwMvMwCX2+D1vfrpE4FHG02pJDCkhzxfVnr+w79OKe/psdqxlidpxlXEX/ab4R368c/aJ18MP S9XXdpSyMIhxMciKKbLECJsviTs163UnG988mDmsTCBDGLg4BWAixxgZ/oe08q/2sRJ/zNO++GXkBb 4FoXtumXwVt7h5Xfn9Gtu2Q7YM/51jra9wLnFfvn56ud4yk8byX5vrZS8FaZpOkCi+OeONNQ8A 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_042613_445606_B88F52E5 X-CRM114-Status: GOOD ( 16.36 ) 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: , Cc: Alexandre Belloni , linux-clk@vger.kernel.org, Maxime Ripard , Claudiu Beznea , linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The SAM9x5 main 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: Alexandre Belloni Cc: Claudiu Beznea Cc: Nicolas Ferre Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Maxime Ripard --- drivers/clk/at91/clk-main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c index 8601b27c1ae0..4966e0f9e92c 100644 --- a/drivers/clk/at91/clk-main.c +++ b/drivers/clk/at91/clk-main.c @@ -533,6 +533,7 @@ static const struct clk_ops sam9x5_main_ops = { .prepare = clk_sam9x5_main_prepare, .is_prepared = clk_sam9x5_main_is_prepared, .recalc_rate = clk_sam9x5_main_recalc_rate, + .determine_rate = clk_hw_determine_rate_no_reparent, .set_parent = clk_sam9x5_main_set_parent, .get_parent = clk_sam9x5_main_get_parent, .save_context = clk_sam9x5_main_save_context,