RE: [PATCH v2 07/11] drivers: clk: renesas: r9a07g044-cpg: Update {GIC,IA55,SCIF} clock/reset entries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH v2 07/11] drivers: clk: renesas: r9a07g044-cpg: Update
> {GIC,IA55,SCIF} clock/reset entries
> 
> Hi Biju,
> 
> On Thu, Jun 24, 2021 at 3:03 PM Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> wrote:
> > Update {GIC,IA55,SCIF} clock and reset entries to CPG driver to match
> > with RZ/G2L clock list hardware manual(RZG2L_clock_list_r02_02.xlsx)
> > and RZ/G2L HW manual(Rev.0.50).
> >
> > Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > ---
> > v1->v2:
> >    * Updated reset entries.
> 
> Thanks for the update!
> 
> I think this patch can be merged with the previous one ("[PATCH
> v2 06/11] drivers: clk: renesas: renesas-rzg2l-cpg: Separate reset from
> module clocks").  The previous patch defined the infrastructure, and this
> patch implements it.  All files touched by the previous patch are also
> touched by this patch.

OK. Will do.

> 
> > --- a/drivers/clk/renesas/renesas-rzg2l-cpg.c
> > +++ b/drivers/clk/renesas/renesas-rzg2l-cpg.c
> > @@ -47,9 +47,9 @@
> >  #define SDIV(val)              DIV_RSMASK(val, 0, 0x7)
> >
> >  #define CLK_ON_R(reg)          (reg)
> > -#define CLK_MON_R(reg)         (0x680 - 0x500 + (reg))
> > -#define CLK_RST_R(reg)         (0x800 - 0x500 + (reg))
> > -#define CLK_MRST_R(reg)                (0x980 - 0x500 + (reg))
> > +#define CLK_MON_R(reg)         (0x180 + (reg))
> > +#define CLK_RST_R(reg)         (reg)
> > +#define CLK_MRST_R(reg)                (0x180 + (reg))
> >
> >  #define GET_REG_OFFSET(val)            ((val >> 20) & 0xfff)
> >  #define GET_REG_SAMPLL_CLK1(val)       ((val >> 22) & 0xfff)
> > @@ -310,14 +310,12 @@ rzg2l_cpg_register_core_clk(const struct
> cpg_core_clk *core,
> >   * @hw: handle between common and hardware-specific interfaces
> >   * @off: register offset
> >   * @onoff: ON/MON bits
> > - * @reset: reset bits
> >   * @priv: CPG/MSTP private data
> >   */
> >  struct mstp_clock {
> >         struct clk_hw hw;
> >         u16 off;
> >         u8 onoff;
> > -       u8 reset;
> >         struct rzg2l_cpg_priv *priv;
> >  };
> >
> > @@ -451,8 +449,7 @@ rzg2l_cpg_register_mod_clk(const struct
> rzg2l_mod_clk *mod,
> >         init.num_parents = 1;
> >
> >         clock->off = mod->off;
> > -       clock->onoff = mod->onoff;
> > -       clock->reset = mod->reset;
> > +       clock->onoff = BIT(mod->onoff);
> 
> I find it a bit confusing to have two members (albeit in different
> structures) named the same with different semantics.
> Moreover, mstp_clock.onoff is too small to hold anything beyond bit 7.
> While RZ/G2{L,LC} don't have any clock bit definitions beyond bit 7 (there
> are reset bit definitions up to bit 12), future SoCs in the series may
> have them.
> So I'd just store the bit offset (which always fits in u8) in both
> structures, and perhaps rename it to "bit", as it is no longer a bitmask
> of multiple bits to control on/off.

OK will use bit. And store the bit offset value.
> 
> Same for "reset"?
OK. Will use the name bit.

> 
> >         clock->priv = priv;
> >         clock->hw.init = &init;
> >
> > @@ -476,12 +473,11 @@ static int rzg2l_cpg_reset(struct
> > reset_controller_dev *rcdev,  {
> >         struct rzg2l_cpg_priv *priv = rcdev_to_priv(rcdev);
> >         const struct rzg2l_cpg_info *info = priv->info;
> > -       unsigned int reg = info->mod_clks[id].off;
> > -       u32 dis = info->mod_clks[id].reset;
> > +       unsigned int reg = info->resets[id].off;
> > +       u32 dis = BIT(info->resets[id].reset);
> >         u32 we = dis << 16;
> >
> > -       dev_dbg(rcdev->dev, "reset name:%s id:%ld offset:0x%x\n",
> > -               info->mod_clks[id].name, id, CLK_RST_R(reg));
> > +       dev_dbg(rcdev->dev, "reset id:%ld offset:0x%x\n", id,
> > + CLK_RST_R(reg));
> >
> >         /* Reset module */
> >         writel(we, priv->base + CLK_RST_R(reg)); @@ -500,11 +496,10 @@
> > static int rzg2l_cpg_assert(struct reset_controller_dev *rcdev,  {
> >         struct rzg2l_cpg_priv *priv = rcdev_to_priv(rcdev);
> >         const struct rzg2l_cpg_info *info = priv->info;
> > -       unsigned int reg = info->mod_clks[id].off;
> > -       u32 value = info->mod_clks[id].reset << 16;
> > +       unsigned int reg = info->resets[id].off;
> > +       u32 value = BIT(info->resets[id].reset) << 16;
> 
> I just realize there's no checking if "id" points to a filled entry in
> info->resets[], except for a range check against nr_resets.
> Perhaps rzg2l_cpg_reset_xlate() (which is BTW identical to
> of_reset_simple_xlate()) can check for a non-zero .off field?  In the
> (long) end, we should have all entries filled in, but until then, a resets
> property in DT pointing to a non-filled entry may cause havoc.

OK. Will check for non zero .off field.
 
> > --- a/drivers/clk/renesas/renesas-rzg2l-cpg.h
> > +++ b/drivers/clk/renesas/renesas-rzg2l-cpg.h
> > @@ -78,7 +78,6 @@ enum clk_types {
> >   * @parent: id of parent clock
> >   * @off: register offset
> >   * @onoff: ON/MON bits
> > - * @reset: reset bits
> >   */
> >  struct rzg2l_mod_clk {
> >         const char *name;
> > @@ -86,17 +85,15 @@ struct rzg2l_mod_clk {
> >         unsigned int parent;
> >         u16 off;
> >         u8 onoff;
> > -       u8 reset;
> >  };
> >
> > -#define DEF_MOD(_name, _id, _parent, _off, _onoff, _reset)     \
> > +#define DEF_MOD(_name, _id, _parent, _off, _onoff)     \
> >         [_id] = { \
> 
> Hadn't realized this before, but do you need the "[_id] ="?
> rzg2l_cpg_info.mod_clks[] is only indexed during initialization.
> If there are gaps due to not all clocks being implemented yet, they are
> skipped by the .name check in rzg2l_cpg_register_mod_clk().
> But I think you can just remove the gaps instead, decreasing kernel size
> (for now).

That means we need to loop through the array and find out the index corresponding to the ID.

Current implementation, we don't need to find out ID iterating through LUT. But as you
said it is at the expense of kernel memory.

Speed vs memory. Long term any way we will fill the holes. The max index now is 96.

What is your preference here? Please share your views.

Regards,
Biju

> >                 .name = _name, \
> >                 .id = MOD_CLK_BASE + _id, \
> >                 .parent = (_parent), \
> >                 .off = (_off), \
> >                 .onoff = (_onoff), \
> > -               .reset = (_reset) \
> >         }
> >
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
> 
> In personal conversations with technical people, I call myself a hacker.
> But when I'm talking to journalists I just say "programmer" or something
> like that.
>                                 -- Linus Torvalds




[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux