All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abel Vesa <abel.vesa@linaro.org>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: Abel Vesa <abelvesa@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Aisheng Dong <aisheng.dong@nxp.com>,
	linux-clk@vger.kernel.org, imx@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Peng Fan <peng.fan@nxp.com>,
	Jacky Bai <ping.bai@nxp.com>
Subject: Re: [PATCH v3 3/5] clk: imx: fracn-gppll: fix pll power up
Date: Tue, 5 Nov 2024 12:00:50 +0200	[thread overview]
Message-ID: <Zyns0qfYpO3mZ4fa@linaro.org> (raw)
In-Reply-To: <20241027-imx-clk-v1-v3-3-89152574d1d7@nxp.com>

On 24-10-27 20:00:09, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> To i.MX93 which features dual Cortex-A55 cores and DSU, when using
> writel_relaxed to write value to PLL registers, the value might be
> buffered. To make sure the value has been written into the hardware,
> using readl to read back the register could achieve the goal.
> 
> current PLL power up flow can be simplified as below:
>   1. writel_relaxed to set the PLL POWERUP bit;
>   2. readl_poll_timeout to check the PLL lock bit:
>      a). timeout = ktime_add_us(ktime_get(), timeout_us);
>      b). readl the pll the lock reg;
>      c). check if the pll lock bit ready
>      d). check if timeout
> 
> But in some corner cases, both the write in step 1 and read in
> step 2 will be blocked by other bus transaction in the SoC for a
> long time, saying the value into real hardware is just before step b).
> That means the timeout counting has begins for quite sometime since
> step a), but value still not written into real hardware until bus
> released just at a point before step b).
> 
> Then there maybe chances that the pll lock bit is not ready
> when readl done but the timeout happens. readl_poll_timeout will
> err return due to timeout. To avoid such unexpected failure,
> read back the reg to make sure the write has been done in HW
> reg.
> 
> So use readl after writel_relaxed to fix the issue.
> 
> Since we are here, to avoid udelay to run before writel_relaxed, use
> readl before udelay.
> 
> Fixes: 1b26cb8a77a4 ("clk: imx: support fracn gppll")
> Co-developed-by: Jacky Bai <ping.bai@nxp.com>
> Signed-off-by: Jacky Bai <ping.bai@nxp.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>

Reviewed-by: Abel Vesa <abel.vesa@linaro.org>

> ---
>  drivers/clk/imx/clk-fracn-gppll.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/clk/imx/clk-fracn-gppll.c b/drivers/clk/imx/clk-fracn-gppll.c
> index 4749c3e0b7051cf53876664808aa28742f6861f7..85771afd4698ae6a0d8a7e82193301e187049255 100644
> --- a/drivers/clk/imx/clk-fracn-gppll.c
> +++ b/drivers/clk/imx/clk-fracn-gppll.c
> @@ -254,9 +254,11 @@ static int clk_fracn_gppll_set_rate(struct clk_hw *hw, unsigned long drate,
>  	pll_div = FIELD_PREP(PLL_RDIV_MASK, rate->rdiv) | rate->odiv |
>  		FIELD_PREP(PLL_MFI_MASK, rate->mfi);
>  	writel_relaxed(pll_div, pll->base + PLL_DIV);
> +	readl(pll->base + PLL_DIV);
>  	if (pll->flags & CLK_FRACN_GPPLL_FRACN) {
>  		writel_relaxed(rate->mfd, pll->base + PLL_DENOMINATOR);
>  		writel_relaxed(FIELD_PREP(PLL_MFN_MASK, rate->mfn), pll->base + PLL_NUMERATOR);
> +		readl(pll->base + PLL_NUMERATOR);
>  	}
>  
>  	/* Wait for 5us according to fracn mode pll doc */
> @@ -265,6 +267,7 @@ static int clk_fracn_gppll_set_rate(struct clk_hw *hw, unsigned long drate,
>  	/* Enable Powerup */
>  	tmp |= POWERUP_MASK;
>  	writel_relaxed(tmp, pll->base + PLL_CTRL);
> +	readl(pll->base + PLL_CTRL);
>  
>  	/* Wait Lock */
>  	ret = clk_fracn_gppll_wait_lock(pll);
> @@ -302,6 +305,7 @@ static int clk_fracn_gppll_prepare(struct clk_hw *hw)
>  
>  	val |= POWERUP_MASK;
>  	writel_relaxed(val, pll->base + PLL_CTRL);
> +	readl(pll->base + PLL_CTRL);
>  
>  	ret = clk_fracn_gppll_wait_lock(pll);
>  	if (ret)
> 
> -- 
> 2.37.1
> 

  reply	other threads:[~2024-11-05 10:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-27 12:00 [PATCH v3 0/5] clk: imx: scu and fracn pll update Peng Fan (OSS)
2024-10-27 12:00 ` [PATCH v3 1/5] clk: imx: lpcg-scu: SW workaround for errata (e10858) Peng Fan (OSS)
2024-11-05  9:58   ` Abel Vesa
2024-10-27 12:00 ` [PATCH v3 2/5] clk: imx: fracn-gppll: correct PLL initialization flow Peng Fan (OSS)
2024-11-05  9:59   ` Abel Vesa
2024-10-27 12:00 ` [PATCH v3 3/5] clk: imx: fracn-gppll: fix pll power up Peng Fan (OSS)
2024-11-05 10:00   ` Abel Vesa [this message]
2024-10-27 12:00 ` [PATCH v3 4/5] clk: imx: clk-scu: fix clk enable state save and restore Peng Fan (OSS)
2024-10-27 12:00 ` [PATCH v3 5/5] clk: imx: lpcg-scu: Skip HDMI LPCG clock save/restore Peng Fan (OSS)
2024-11-05 10:21 ` [PATCH v3 0/5] clk: imx: scu and fracn pll update Abel Vesa

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=Zyns0qfYpO3mZ4fa@linaro.org \
    --to=abel.vesa@linaro.org \
    --cc=abelvesa@kernel.org \
    --cc=aisheng.dong@nxp.com \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=ping.bai@nxp.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sboyd@kernel.org \
    --cc=shawnguo@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.