[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <07a8ac42184f440fae1b0d13db4e43cc@EXMBX066.cuchost.com>
Date: Wed, 20 Dec 2023 01:39:36 +0000
From: JeeHeng Sia <jeeheng.sia@...rfivetech.com>
To: Emil Renner Berthing <emil.renner.berthing@...onical.com>,
"kernel@...il.dk" <kernel@...il.dk>, "conor@...nel.org" <conor@...nel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
"paul.walmsley@...ive.com" <paul.walmsley@...ive.com>, "palmer@...belt.com"
<palmer@...belt.com>, "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
"mturquette@...libre.com" <mturquette@...libre.com>, "sboyd@...nel.org"
<sboyd@...nel.org>, "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>, "Hal
Feng" <hal.feng@...rfivetech.com>, Xingyu Wu <xingyu.wu@...rfivetech.com>
CC: "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>, Leyfoon Tan
<leyfoon.tan@...rfivetech.com>
Subject: RE: [PATCH v1 06/16] clk: starfive: Add JH8100 System clock generator
driver
> -----Original Message-----
> From: Emil Renner Berthing <emil.renner.berthing@...onical.com>
> Sent: Wednesday, December 13, 2023 7:57 PM
> To: JeeHeng Sia <jeeheng.sia@...rfivetech.com>; Emil Renner Berthing <emil.renner.berthing@...onical.com>; kernel@...il.dk;
> conor@...nel.org; robh+dt@...nel.org; krzysztof.kozlowski+dt@...aro.org; paul.walmsley@...ive.com; palmer@...belt.com;
> aou@...s.berkeley.edu; mturquette@...libre.com; sboyd@...nel.org; p.zabel@...gutronix.de; Hal Feng
> <hal.feng@...rfivetech.com>; Xingyu Wu <xingyu.wu@...rfivetech.com>
> Cc: linux-riscv@...ts.infradead.org; devicetree@...r.kernel.org; linux-kernel@...r.kernel.org; linux-clk@...r.kernel.org; Leyfoon Tan
> <leyfoon.tan@...rfivetech.com>
> Subject: RE: [PATCH v1 06/16] clk: starfive: Add JH8100 System clock generator driver
>
> JeeHeng Sia wrote:
> > > -----Original Message-----
> > > From: Emil Renner Berthing <emil.renner.berthing@...onical.com>
> > > Sent: Saturday, December 9, 2023 12:25 AM
> > > To: JeeHeng Sia <jeeheng.sia@...rfivetech.com>; kernel@...il.dk; conor@...nel.org; robh+dt@...nel.org;
> > > krzysztof.kozlowski+dt@...aro.org; paul.walmsley@...ive.com; palmer@...belt.com; aou@...s.berkeley.edu;
> > > mturquette@...libre.com; sboyd@...nel.org; p.zabel@...gutronix.de; emil.renner.berthing@...onical.com; Hal Feng
> > > <hal.feng@...rfivetech.com>; Xingyu Wu <xingyu.wu@...rfivetech.com>
> > > Cc: linux-riscv@...ts.infradead.org; devicetree@...r.kernel.org; linux-kernel@...r.kernel.org; linux-clk@...r.kernel.org; Leyfoon
> Tan
> > > <leyfoon.tan@...rfivetech.com>
> > > Subject: Re: [PATCH v1 06/16] clk: starfive: Add JH8100 System clock generator driver
> > >
> > > Sia Jee Heng wrote:
> > > > Add support for JH8100 System clock generator.
> > > >
> > > > Signed-off-by: Sia Jee Heng <jeeheng.sia@...rfivetech.com>
> > > > Reviewed-by: Ley Foon Tan <leyfoon.tan@...rfivetech.com>
> > > > ---
> > > > MAINTAINERS | 8 +
> > > > drivers/clk/starfive/Kconfig | 9 +
> > > > drivers/clk/starfive/Makefile | 1 +
> > > > drivers/clk/starfive/clk-starfive-common.h | 9 +-
> > > > drivers/clk/starfive/jh8100/Makefile | 3 +
> > > > .../clk/starfive/jh8100/clk-starfive-jh8100.h | 11 +
> > > > drivers/clk/starfive/jh8100/clk-sys.c | 455 ++++++++++++++++++
> > > > 7 files changed, 495 insertions(+), 1 deletion(-)
> > > > create mode 100644 drivers/clk/starfive/jh8100/Makefile
> > > > create mode 100644 drivers/clk/starfive/jh8100/clk-starfive-jh8100.h
> > > > create mode 100644 drivers/clk/starfive/jh8100/clk-sys.c
> ...
> > > > diff --git a/drivers/clk/starfive/Makefile b/drivers/clk/starfive/Makefile
> > > > index 012f7ee83f8e..6cb3ce823330 100644
> > > > --- a/drivers/clk/starfive/Makefile
> > > > +++ b/drivers/clk/starfive/Makefile
> > > > @@ -10,3 +10,4 @@ obj-$(CONFIG_CLK_STARFIVE_JH7110_AON) += clk-starfive-jh7110-aon.o
> > > > obj-$(CONFIG_CLK_STARFIVE_JH7110_STG) += clk-starfive-jh7110-stg.o
> > > > obj-$(CONFIG_CLK_STARFIVE_JH7110_ISP) += clk-starfive-jh7110-isp.o
> > > > obj-$(CONFIG_CLK_STARFIVE_JH7110_VOUT) += clk-starfive-jh7110-vout.o
> > > > +obj-$(CONFIG_CLK_STARFIVE_JH8100_SYS) += jh8100/
> > >
> > > I don't really see why do you need a special subdirectory for the JH8100? The
> > > JH7110 drivers do fine without it.
> > Each subfolder can represent a different platform, making it easier to
> > locate and maintain platform-specific code. Since the code is expected
> > to grow in the future, let's start organizing it in a folder-based structure
> > for easier maintenance at a later stage.
>
> Yes, but that's not what you're doing here. You're making just one of the 3
> almost identical drivers be different for no good reason.
>
> > > > diff --git a/drivers/clk/starfive/clk-starfive-common.h b/drivers/clk/starfive/clk-starfive-common.h
> > > > index fed45311360c..ec30af0658cf 100644
> > > > --- a/drivers/clk/starfive/clk-starfive-common.h
> > > > +++ b/drivers/clk/starfive/clk-starfive-common.h
> > > > @@ -103,6 +103,13 @@ struct starfive_clk_data {
> > > > .parents = { [0] = _parent }, \
> > > > }
> > > >
> > > > +#define STARFIVE_GINV(_idx, _name, _flags, _parent)[_idx] = { \
> > > > + .name = _name, \
> > > > + .flags = _flags, \
> > > > + .max = STARFIVE_CLK_ENABLE | STARFIVE_CLK_INVERT, \
> > > > + .parents = { [0] = _parent }, \
> > > > +}
> > > > +
> > > > struct starfive_clk {
> > > > struct clk_hw hw;
> > > > unsigned int idx;
> > > > @@ -114,7 +121,7 @@ struct starfive_clk_priv {
> > > > spinlock_t rmw_lock;
> > > > struct device *dev;
> > > > void __iomem *base;
> > > > - struct clk_hw *pll[3];
> > > > + struct clk_hw *pll[8];
> > >
> > > These extra slots are just used for fixed factor dummy PLLs right now, similar
> > > to how the JH7110 first used them and later had to rework drivers and device
> > > trees for the proper PLL driver.
> > Yes, its intention is similar to JH8100. We will submit other clock
> > domains and PLL at later stage but not so soon.
> > >
> > > This time around I'd much rather you work on getting the PLL driver in first,
> > > so we don't need all that churn.
> > I am sorry but we started development on FPGA. Unfortunately, the PLL driver
> > and other domains are planned to be finished at a later stage. I have tried
> > to minimize the churn as much as possible.
>
> It's awesome that you're beginning upstreaming early, but if you don't have
> this in silicon yet, how do you even know that this driver works?
>
> If you're just using this for testing on FPGAs you can create dummy fixed
> clocks in the device tree for the PLLs that this driver can consume. Then
> later when you have a PLL driver you can replace those fixed clocks with the
> output of that driver.
The PLL fixed clocks were created in the C code. I interpret this message
as a suggestion to create a PLL fixed clock in the DT?
>
> /Emil
Powered by blists - more mailing lists