From: Conor Dooley <conor@kernel.org>
To: Xingyu Wu <xingyu.wu@starfivetech.com>
Cc: Emil Renner Berthing <emil.renner.berthing@canonical.com>,
Hal Feng <hal.feng@starfivetech.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>
Subject: Re: [PATCH v6] clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz
Date: Sun, 18 Aug 2024 14:44:19 +0100 [thread overview]
Message-ID: <20240818-flip-excusably-c89021683d20@spud> (raw)
In-Reply-To: <NTZPR01MB09563DBA6F76281EB06914859FB92@NTZPR01MB0956.CHNPR01.prod.partner.outlook.cn>
[-- Attachment #1: Type: text/plain, Size: 5701 bytes --]
On Thu, Aug 08, 2024 at 03:44:49AM +0000, Xingyu Wu wrote:
> On 06/08/2024 17:58, Emil Renner Berthing wrote:
> >
> > Xingyu Wu wrote:
> > > CPUfreq supports 4 cpu frequency loads on 375/500/750/1500MHz. But now
> > > PLL0 rate is 1GHz and the cpu frequency loads become
> > > 250/333/500/1000MHz in fact. The PLL0 rate should be default set to
> > > 1.5GHz and set the divider of cpu_core clock to 2 in safe.
> > >
> > > To keeo the cpu frequency stable when setting PLL0, the parent clock
> > > of the cpu_root clock needs to be switched from PLL0 to another parent
> > > clock and add notifier function to do this for PLL0 clock. In the
> > > function, the cpu_root clock should be operated by saving its current
> > > parent and setting a new safe parent (osc clock) before setting the
> > > PLL0 clock rate. After setting PLL0 rate, it should be switched back
> > > to the original parent clock.
> > >
> > > To keep the DTS same in Linux and U-Boot and the PLL0 rate is 1GHz in
> > > U-Boot, the PLL0 rate should be set to 1.5GHz in the driver instead of
> > > DTS.
> > >
> > > Fixes: e2c510d6d630 ("riscv: dts: starfive: Add cpu scaling for JH7110
> > > SoC")
> > > Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
> > > ---
> > >
> > > Hi Stephen and Emil,
> > >
> > > This patch is to fix the lower rate of CPUfreq by adding the notifier
> > > for PLL0 clock and changing the PLL0 rate to 1.5GHz.
> > >
> > > To keep the DTS same in Linux and U-Boot as Conor wants[1] and the
> > > PLL0 rate is 1GHz in U-Boot, the PLL0 rate should be set to 1.5GHz in
> > > the driver instead of DTS.
> > >
> > > [1]:
> > > https://lore.kernel.org/all/20240515-reorder-even-8b9eebd91b45@spud/
> > >
> > > Thanks,
> > > Xingyu Wu
> > >
> > > ---
> > > .../clk/starfive/clk-starfive-jh7110-sys.c | 54 ++++++++++++++++++-
> > > drivers/clk/starfive/clk-starfive-jh71x0.h | 2 +
> > > 2 files changed, 54 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/clk/starfive/clk-starfive-jh7110-sys.c
> > > b/drivers/clk/starfive/clk-starfive-jh7110-sys.c
> > > index 8f5e5abfa178..7469981fb405 100644
> > > --- a/drivers/clk/starfive/clk-starfive-jh7110-sys.c
> > > +++ b/drivers/clk/starfive/clk-starfive-jh7110-sys.c
> > > @@ -385,6 +385,32 @@ int jh7110_reset_controller_register(struct
> > > jh71x0_clk_priv *priv, }
> > > EXPORT_SYMBOL_GPL(jh7110_reset_controller_register);
> > >
> > > +/*
> > > + * This clock notifier is called when the rate of PLL0 clock is to be changed.
> > > + * The cpu_root clock should save the curent parent clock and swicth
> > > +its parent
> > > + * clock to osc before PLL0 rate will be changed. Then swicth its
> > > +parent clock
> > > + * back after the PLL0 rate is completed.
> > > + */
> > > +static int jh7110_pll0_clk_notifier_cb(struct notifier_block *nb,
> > > + unsigned long action, void *data) {
> > > + struct jh71x0_clk_priv *priv = container_of(nb, struct jh71x0_clk_priv,
> > pll_clk_nb);
> > > + struct clk *cpu_root = priv->reg[JH7110_SYSCLK_CPU_ROOT].hw.clk;
> > > + int ret = 0;
> > > +
> > > + if (action == PRE_RATE_CHANGE) {
> > > + struct clk *osc = clk_get(priv->dev, "osc");
> > > +
> > > + priv->original_clk = clk_get_parent(cpu_root);
> > > + ret = clk_set_parent(cpu_root, osc);
> > > + clk_put(osc);
> > > + } else if (action == POST_RATE_CHANGE) {
> > > + ret = clk_set_parent(cpu_root, priv->original_clk);
> > > + }
> > > +
> > > + return notifier_from_errno(ret);
> > > +}
> > > +
> > > static int __init jh7110_syscrg_probe(struct platform_device *pdev)
> > > {
> > > struct jh71x0_clk_priv *priv;
> > > @@ -413,7 +439,11 @@ static int __init jh7110_syscrg_probe(struct
> > platform_device *pdev)
> > > if (IS_ERR(priv->pll[0]))
> > > return PTR_ERR(priv->pll[0]);
> > > } else {
> > > - clk_put(pllclk);
> > > + priv->pll_clk_nb.notifier_call = jh7110_pll0_clk_notifier_cb;
> > > + ret = clk_notifier_register(pllclk, &priv->pll_clk_nb);
> > > + if (ret)
> > > + return ret;
> > > +
> > > priv->pll[0] = NULL;
> > > }
> > >
> > > @@ -501,7 +531,27 @@ static int __init jh7110_syscrg_probe(struct
> > platform_device *pdev)
> > > if (ret)
> > > return ret;
> > >
> > > - return jh7110_reset_controller_register(priv, "rst-sys", 0);
> > > + ret = jh7110_reset_controller_register(priv, "rst-sys", 0);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /* Set the divider cpu_core to 2 and set the PLL0 rate to 1.5G. */
> > > + pllclk = clk_get(priv->dev, "pll0_out");
> > > + if (!IS_ERR(pllclk)) {
> > > + struct clk *cpu_core = priv-
> > >reg[JH7110_SYSCLK_CPU_CORE].hw.clk;
> > > +
> > > + ret = clk_set_rate(cpu_core, clk_get_rate(cpu_core) / 2);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = clk_set_rate(pllclk, 1500000000);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + clk_put(pllclk);
> > > + }
> > > +
> > > + return 0;
> >
> > I'm still not a fan of hardcoding cpu frequencies in the driver. You've added the
> > notifiers exactly so that we can use the standard device tree settings for this.
> >
> > In other words I much prefer v5 of this patchset.
> >
> > /Emil
> >
>
> Thanks, Emil.
>
> Hi Conor, what do you think about this issue?
Apologies for the delay replying, I didn't realise there was a question
here directed at me. My only real thought on the patchset is that what
is done should not cause problems when the same devicetree is used for
both U-Boot and for the kernel. As long as that's satisfied, I don't
mind how you choose to implement it.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-08-18 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 2:06 [PATCH v6] clk: starfive: jh7110-sys: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz Xingyu Wu
2024-07-02 6:28 ` Xingyu Wu
2024-08-06 9:58 ` Emil Renner Berthing
2024-08-08 3:44 ` Xingyu Wu
2024-08-18 13:44 ` Conor Dooley [this message]
2024-08-23 3:41 ` Hal Feng
2024-08-23 8:34 ` Xingyu Wu
2024-08-23 15:34 ` Conor Dooley
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=20240818-flip-excusably-c89021683d20@spud \
--to=conor@kernel.org \
--cc=emil.renner.berthing@canonical.com \
--cc=hal.feng@starfivetech.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.org \
--cc=xingyu.wu@starfivetech.com \
/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.