[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+V-a8t3VXvgnh50RftSPA7tYAipfuMC1E0gBfYD6etWqOGHRg@mail.gmail.com>
Date: Thu, 27 Jun 2024 14:27:34 +0100
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Magnus Damm <magnus.damm@...il.com>, linux-renesas-soc@...r.kernel.org,
linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org,
Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [RFC PATCH v2 4/4] clk: renesas: Add RZ/V2H(P) CPG driver
Hi Geert,
Thank you for the review.
On Wed, Jun 26, 2024 at 11:14 AM Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
>
> On Tue, Jun 11, 2024 at 1:32 AM Prabhakar <prabhakar.csengg@...il.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Add RZ/V2H(P) CPG driver.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > ---
> > v1->v2
> > - Updated commit description
> > - Dropped pll_clk1/clk2_offset
> > - Made r9a09g057_mod_clks/r9a09g057_resets as static const
> > - Now using register indexes
>
> Thanks for the update!
>
> > --- /dev/null
> > +++ b/drivers/clk/renesas/r9a09g057-cpg.c
>
> > +static const struct rzv2h_mod_clk r9a09g057_mod_clks[] = {
> > + DEF_MOD("scif_0_clk_pck", CLK_PLLCM33_DIV16, 8, 15, 4, 15),
>
> So this relates to module clock 8 * 16 + 15 = 143 in DTS...
>
Yep.
> > +};
> > +
> > +static const struct rzv2h_reset r9a09g057_resets[] = {
> > + DEF_RST(9, 5, 4, 6), /* SCIF_0_RST_SYSTEM_N */
> > +};
> > +
> > +static const unsigned int r9a09g057_crit_mod_clks[] __initconst = {
> > + MOD_CLK_BASE + 5, /* ICU_0_PCLK_I */
> > + MOD_CLK_BASE + 19, /* GIC_0_GICCLK */
>
> So these relate to module clocks 5 and 19 in DTS.
>
> Actually none of these clocks are created in the driver yet, so I think
> these critical clocks belong to the patch that will introduce them.
>
> I am wondering if critical clocks should just use a flag in DEF_MOD()
> instead...
>
Agreed, I will add a flag for it and have two macros like below,
#define DEF_MOD_BASE(_name, _parent, _id, _critical, _onindex, _onbit,
_monindex, _monbit) \
{ \
.name = (_name), \
.parent = (_parent), \
.id = (_id), \
.critical = (_critical), \
.on_index = (_onindex), \
.on_bit = (_onbit), \
.mon_index = (_monindex), \
.mon_bit = (_monbit), \
}
#define MOD_CLK_ID(x) (MOD_CLK_BASE + (x))
#define MOD_ID(x, y) ((((x) * 16)) + (y))
#define DEF_MOD(_name, _parent, _onindex, _onbit, _monindex, _monbit) \
DEF_MOD_BASE(_name, _parent, MOD_CLK_ID(MOD_ID(_onindex, _onbit)), \
false, _onindex, _onbit, _monindex, _monbit)
#define DEF_MOD_CRITICAL(_name, _parent, _onindex, _onbit, _monindex,
_monbit) \
DEF_MOD_BASE(_name, _parent, MOD_CLK_ID(MOD_ID(_onindex, _onbit)), \
true, _onindex, _onbit, _monindex, _monbit)
Cheers,
Prabhakar
Powered by blists - more mailing lists