linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
	jbrunet@baylibre.com, narmstrong@baylibre.com
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, mturquette@baylibre.com,
	sboyd@kernel.org,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Subject: [RFC v1 3/7] clk: meson: clk-pll: check if the clock is already enabled
Date: Wed, 14 Nov 2018 23:57:21 +0100	[thread overview]
Message-ID: <20181114225725.2821-4-martin.blumenstingl@googlemail.com> (raw)
In-Reply-To: <20181114225725.2821-1-martin.blumenstingl@googlemail.com>

Since commit 6f888e7bc7bd58 ("clk: meson: clk-pll: add enable bit") our
PLLs also support the "enable" bit. Currently meson_clk_pll_enable
unconditionally resets the PLL, enables it, takes it out of reset and
waits until it is locked.

This works fine for our current clock trees. However, there will be a
problem once we allow modifications to sys_pll on Meson8, Meson8b and
Meson8m2 (which will be required for CPU frequency scaling):
the CPU clock is derived from the sys_pll clock. Once clk_enable is
called on the CPU clock this will be propagated by the common clock
framework up until the sys_pll clock. If we reset the PLL
unconditionally in meson_clk_pll_enable the CPU will be stopped (on
Meson8, Meson8b and Meson8m2).
To prevent this we simply check if the PLL is already enabled and do
reset the PLL if it's already enabled and locked.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
 drivers/clk/meson/clk-pll.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
index f5b5b3fabe3c..b46cca953f4f 100644
--- a/drivers/clk/meson/clk-pll.c
+++ b/drivers/clk/meson/clk-pll.c
@@ -200,11 +200,32 @@ static void meson_clk_pll_init(struct clk_hw *hw)
 	}
 }
 
+static int meson_clk_pll_is_enabled(struct clk_hw *hw)
+{
+	struct clk_regmap *clk = to_clk_regmap(hw);
+	struct meson_clk_pll_data *pll = meson_clk_pll_data(clk);
+
+	if (meson_parm_read(clk->map, &pll->rst))
+		return 0;
+
+	if (!meson_parm_read(clk->map, &pll->en))
+		return 0;
+
+	if (!meson_parm_read(clk->map, &pll->l))
+		return 0;
+
+	return 1;
+}
+
 static int meson_clk_pll_enable(struct clk_hw *hw)
 {
 	struct clk_regmap *clk = to_clk_regmap(hw);
 	struct meson_clk_pll_data *pll = meson_clk_pll_data(clk);
 
+	/* do nothing if the PLL is already enabled */
+	if (meson_clk_pll_is_enabled(hw))
+		return 0;
+
 	/* Make sure the pll is in reset */
 	meson_parm_write(clk->map, &pll->rst, 1);
 
-- 
2.19.1


  parent reply	other threads:[~2018-11-14 22:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-14 22:57 [RFC v1 0/7] Meson8b: make the CPU clock mutable Martin Blumenstingl
2018-11-14 22:57 ` [RFC v1 1/7] clk: meson: meson8b: run from the XTAL when changing the CPU frequency Martin Blumenstingl
2018-11-15  9:53   ` Jerome Brunet
2018-11-14 22:57 ` [RFC v1 2/7] clk: meson: meson8b: do not use cpu_div3 for cpu_scale_out_sel Martin Blumenstingl
2018-11-15  9:42   ` Jerome Brunet
2018-11-14 22:57 ` Martin Blumenstingl [this message]
2018-11-15  9:14   ` [RFC v1 3/7] clk: meson: clk-pll: check if the clock is already enabled Jerome Brunet
2018-11-14 22:57 ` [RFC v1 4/7] clk: meson: clk-pll: add the is_enabled function in the clk_ops Martin Blumenstingl
2018-11-15  9:16   ` Jerome Brunet
2018-11-14 22:57 ` [RFC v1 5/7] clk: meson: meson8b: mark the CPU clock as CLK_IS_CRITICAL Martin Blumenstingl
2018-11-15  9:46   ` Jerome Brunet
2018-11-14 22:57 ` [RFC v1 6/7] clk: meson: meson8b: add support for more M/N values in sys_pll Martin Blumenstingl
2018-11-15  9:41   ` Jerome Brunet
2018-11-14 22:57 ` [RFC v1 7/7] clk: meson: meson8b: allow changing the CPU clock tree Martin Blumenstingl
2018-11-15  9:46   ` Jerome Brunet
2018-11-15 10:08 ` [RFC v1 0/7] Meson8b: make the CPU clock mutable Neil Armstrong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181114225725.2821-4-martin.blumenstingl@googlemail.com \
    --to=martin.blumenstingl@googlemail.com \
    --cc=jbrunet@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=narmstrong@baylibre.com \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).