Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp10123611ybl; Thu, 26 Dec 2019 11:14:43 -0800 (PST) X-Google-Smtp-Source: APXvYqzuSbNSYAmiydAiECjaMwLmzGCJPYZ0ZdtTg7GN8GfLT7wjleO+ghyZ5yYudZMZlqgKtLAR X-Received: by 2002:a9d:c02:: with SMTP id 2mr53597473otr.183.1577387683556; Thu, 26 Dec 2019 11:14:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577387683; cv=none; d=google.com; s=arc-20160816; b=t/PhshprxwwQiEBDbK0pCZI1P1vjGskYTjwwed9LKXPqKcx6nAao2ScIRdDE/P0Avd LmqSLS/YBY0F6KtArPIUlQdXWH8O5VZh+pznB+jbkZJ7h5FXErdM/JB90+vfuKmBsCJk dNhjTaZ+oAx9hrHDCY4311qNAKvN4IHItoDOYh76fgbl3hnpQrJkYCwwR10e/SlL2TlU HhKyXlLkS9TRaZwlAX8D38aVEyMz2WFpfWYpFTNdx1EjN7ZC6WJrzZxudWV4RYyhclK0 vIFRWF8toccd/lReY7TteohHGYEPe9nEAxdgHna00G/GqdlGONLr3VMzSI93C4EdMS7G iIig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=mmT0zF9OrkbiD8lj/0dOwJG0ayj5vgSHBwzc+nFQ5Gg=; b=pboWH+LyOx1KyWMMshIfJPmIm8YNWePLv1r8dnY5Wb+m/oBvyhIdcx0o+K1Y5icUPa 2bwreN5uKr1FnceFyR0aTuJVIhKmjzBx+ffjR0LWOKXZorH3IIcM7SYfLKUI2pvoLNsV +0K5WjbjpKnUplo7Ddwg9FozQJPlHOwLeVUydUFzQ2oMCif+BbXF5GaQGVZr1rOJAu7x PcAeNT82NyTp1hmY4tEDzKVpiMFbo3x5ypRxfUO3hnPLELsbTvmfiamp2fBTsGV2RPWm EDmiKnYdYIZU/4jKpUDwfceTe9aGvyfGFpFRjX0+wffncONlidWLPVWqHIKNeUTxT5lD TCEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b="klF/ucA9"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g2si16495281otn.117.2019.12.26.11.14.31; Thu, 26 Dec 2019 11:14:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b="klF/ucA9"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726984AbfLZTMv (ORCPT + 99 others); Thu, 26 Dec 2019 14:12:51 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:34830 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726812AbfLZTMr (ORCPT ); Thu, 26 Dec 2019 14:12:47 -0500 Received: by mail-wr1-f65.google.com with SMTP id g17so24330184wro.2; Thu, 26 Dec 2019 11:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=mmT0zF9OrkbiD8lj/0dOwJG0ayj5vgSHBwzc+nFQ5Gg=; b=klF/ucA9NSUXwoHRk1+Si9sfnX9CSLC+s/ebG98azsGLVJj1eJB4Gh6K3XoDxFlgwf e4nZ54SihxAA0YFfk6F238dYP9TkFDlIdBWYh29QftbkX6XICz13muXv7qfEFCaUuUQp CoschbCdrD2XhSLd6SH9cxWtcrwocY4bonRfJDgF/CSuyvksP5uvGZLJz34FGSHXsrYg zsLYDYhhxGFxKmdmRKvL1TWzEJnbemd/PDUm2ivSnrRB7Y9/J1HMeXM/nofk/edIPYUi LHC/Mn0XfMUpeWAegjzOMgII4GO2Y5c/8pyPTtVL95QBAq4GwW17CZ6pacVbQsAwGKv0 faqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mmT0zF9OrkbiD8lj/0dOwJG0ayj5vgSHBwzc+nFQ5Gg=; b=qljpTyowgcev/GpTKpIF1bbKMxxMJBHBfQTJwUrOsrX0sSjGHasmclpp+PMK7l6KZP 6U1I2tp8hd2AsYh3EQh9GguTjbDOOw69TknhWue/slRheRSWixFHlbgM5hQqg/nJksPR YyMY/Qcj1wkbwkg+SMLiKG1qF39WzqsYN7AdUBWV/Z3M2VBykz08yC2A0a80fM6VpyxV q3KZn9FtAkuJRmqGZO+ImA7P+Ta9saxlM407jsUr2lcfmt+/H46YYHfy4zjMzCyIveiF k446i4r6wnH6MYXG/7n8nmVsRsOq207ozdZcgKGW3aGisCcJtaYcpx73lwqz9ZBhalgY /tsg== X-Gm-Message-State: APjAAAURew1Zp+M336YWrlF1KybZmgRAxkSaZhH2GwmFru1jU0JaVs43 FqSFw+F4+w32wed9jHaznT8= X-Received: by 2002:a5d:4085:: with SMTP id o5mr45964730wrp.321.1577387565138; Thu, 26 Dec 2019 11:12:45 -0800 (PST) Received: from localhost.localdomain (p200300F1373A1900428D5CFFFEB99DB8.dip0.t-ipconnect.de. [2003:f1:373a:1900:428d:5cff:feb9:9db8]) by smtp.googlemail.com with ESMTPSA id o7sm8965937wmh.11.2019.12.26.11.12.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Dec 2019 11:12:44 -0800 (PST) From: Martin Blumenstingl To: linux-amlogic@lists.infradead.org, jbrunet@baylibre.com, sboyd@kernel.org Cc: narmstrong@baylibre.com, mturquette@baylibre.com, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Martin Blumenstingl Subject: [PATCH v2 2/2] clk: clarify that clk_set_rate() does updates from top to bottom Date: Thu, 26 Dec 2019 20:12:24 +0100 Message-Id: <20191226191224.3785282-3-martin.blumenstingl@googlemail.com> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191226191224.3785282-1-martin.blumenstingl@googlemail.com> References: <20191226191224.3785282-1-martin.blumenstingl@googlemail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org clk_set_rate() currently starts updating the rate for a clock at the top-most affected clock and then walks down the tree to update the bottom-most affected clock last. This behavior is important for protected clocks where we can switch between multiple parents to achieve the same output. An example for this is the mali clock tree on Amlogic SoCs: mali_0_mux (must not change when enabled) mali_0_div (must not change when enabled) mali_0 (gate) mali_1_mux (must not change when enabled) mali_1_div (must not change when enabled) mali_1 (gate) The final output can either use mali_0_gate or mali_1. To change the final output we must switch to the "inactive" tree. Assuming mali_0 is active, then we need to prepare mali_1 with the new desired rate and finally switch the output to the mali_1 tree. This process will then protect the mali_1 tree and at the same time unprotect the mali_0 tree. The next call to clk_set_rate() will then switch from the mali_1 tree back to mali_0. Signed-off-by: Martin Blumenstingl --- include/linux/clk.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/clk.h b/include/linux/clk.h index 18b7b95a8253..7fd6a1febcf4 100644 --- a/include/linux/clk.h +++ b/include/linux/clk.h @@ -627,6 +627,9 @@ long clk_round_rate(struct clk *clk, unsigned long rate); * @clk: clock source * @rate: desired clock rate in Hz * + * Updating the rate starts at the top-most affected clock and then + * walks the tree down to the bottom-most clock that needs updating. + * * Returns success (0) or negative errno. */ int clk_set_rate(struct clk *clk, unsigned long rate); -- 2.24.1