linux-kernel - Re: [PATCH 01/22] clk: renesas: rzv2h: Add PLLDSI clk mux support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aXOZKK7alxiHJRUk@tom-desktop>
Date: Fri, 23 Jan 2026 16:52:08 +0100
From: Tommaso Merciai <tommaso.merciai.xr@...renesas.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>
Cc: tomm.merciai@...il.com, linux-renesas-soc@...r.kernel.org,
	biju.das.jz@...renesas.com, Andrzej Hajda <andrzej.hajda@...el.com>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	Robert Foss <rfoss@...nel.org>,
	Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
	Jonas Karlman <jonas@...boo.se>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>,
	Magnus Damm <magnus.damm@...il.com>,
	dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH 01/22] clk: renesas: rzv2h: Add PLLDSI clk mux support

Hi Geert,
Thanks for your comment.

On Wed, Jan 14, 2026 at 02:07:49PM +0100, Geert Uytterhoeven wrote:
> Hi Tommaso,
> 
> On Mon, 12 Jan 2026 at 09:13, Tommaso Merciai
> <tommaso.merciai.xr@...renesas.com> wrote:
> > On Fri, Jan 09, 2026 at 07:27:04PM +0100, Geert Uytterhoeven wrote:
> > > On Wed, 26 Nov 2025 at 15:08, Tommaso Merciai
> > > <tommaso.merciai.xr@...renesas.com> wrote:
> > > > Add PLLDSI clk mux support to select PLLDSI clock from different clock
> > > > sources.
> > > >
> > > > Introduce the DEF_PLLDSI_SMUX() macro to define these muxes and register
> > > > them in the clock driver.
> > > >
> > > > Extend the determine_rate callback to calculate and propagate PLL
> > > > parameters via rzv2h_get_pll_dtable_pars() when LVDS output is selected,
> > > > using a new helper function rzv2h_cpg_plldsi_smux_lvds_determine_rate().
> > > >
> > > > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@...renesas.com>
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/drivers/clk/renesas/rzv2h-cpg.c
> > > > +++ b/drivers/clk/renesas/rzv2h-cpg.c
> > >
> > > [...]
> > >
> > > >  static int rzv2h_cpg_pll_clk_is_enabled(struct clk_hw *hw)
> > > >  {
> > > >         struct pll_clk *pll_clk = to_pll(hw);
> > > > @@ -1085,6 +1213,9 @@ rzv2h_cpg_register_core_clk(const struct cpg_core_clk *core,
> > > >         case CLK_TYPE_PLLDSI_DIV:
> > > >                 clk = rzv2h_cpg_plldsi_div_clk_register(core, priv);
> > > >                 break;
> > > > +       case CLK_TYPE_PLLDSI_SMUX:
> > > > +               clk = rzv2h_cpg_plldsi_smux_clk_register(core, priv);
> > > > +               break;
> > > >         default:
> > > >                 goto fail;
> > > >         }
> > > > diff --git a/drivers/clk/renesas/rzv2h-cpg.h b/drivers/clk/renesas/rzv2h-cpg.h
> > > > index dc957bdaf5e9..5f6e775612e7 100644
> > > > --- a/drivers/clk/renesas/rzv2h-cpg.h
> > > > +++ b/drivers/clk/renesas/rzv2h-cpg.h
> > > > @@ -203,6 +203,7 @@ enum clk_types {
> > > >         CLK_TYPE_SMUX,          /* Static Mux */
> > > >         CLK_TYPE_PLLDSI,        /* PLLDSI */
> > > >         CLK_TYPE_PLLDSI_DIV,    /* PLLDSI divider */
> > > > +       CLK_TYPE_PLLDSI_SMUX,   /* PLLDSI Static Mux */
> > > >  };
> > > >
> > > >  #define DEF_TYPE(_name, _id, _type...) \
> > > > @@ -241,6 +242,13 @@ enum clk_types {
> > > >                  .dtable = _dtable, \
> > > >                  .parent = _parent, \
> > > >                  .flag = CLK_SET_RATE_PARENT)
> > > > +#define DEF_PLLDSI_SMUX(_name, _id, _smux_packed, _parent_names) \
> > > > +       DEF_TYPE(_name, _id, CLK_TYPE_PLLDSI_SMUX, \
> > > > +                .cfg.smux = _smux_packed, \
> > > > +                .parent_names = _parent_names, \
> > > > +                .num_parents = ARRAY_SIZE(_parent_names), \
> > > > +                .flag = CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT, \
> > > > +                .mux_flags = CLK_MUX_HIWORD_MASK)
> > > >
> > > >  /**
> > > >   * struct rzv2h_mod_clk - Module Clocks definitions
> > >
> > > Why do you need a completely new clock type, and can't you just use
> > > the existing CLK_TYPE_SMUX?
> >
> > From reference manual (Table 4.4-10 Specifications of the CPG_SSELm
> > Registers)
> >
> > We have the following:
> >
> >  - SMUX2_DSI0_CLK*2
> >         0b: CDIV7_DSI0_CLK (default)
> >         1b: CSDIV_2to16_PLLDSI0
> >
> >  - SMUX2_DSI1_CLK*2
> >         0b: CDIV7_DSI1_CLK (default)
> >         1b: CSDIV_2to16_PLLDSI1
> >
> > Note 2.If LVDS0 / LVDS1 is used, be sure to set 0b.
> >
> > For this reason these clocks needs an ad hoc determine_rate function:
> >         - rzv2h_cpg_plldsi_smux_determine_rate()
> >
> > For that CLK_TYPE_PLLDSI_SMUX has been introduced.
> > What do you think?
> 
> OK, your solution sounds good to me.  Still, as this is used from the
> DRM driver, I would like to get some feedback from the DRM people, too.
> 
> BTW, I just noticed in the RZ/G3E clock system diagram that
> CDIV7_DSI0_CLK has a duty cycle "DUTY H/L=4/3", while all other clocks
> use the symmetrical 50%.  Perhaps the DRM driver can request a duty
> cycle of 4/7 when using LVDS? Currently the DRM driver communicates
> its requirements by explicitly setting the parent.

Based on your idea we can add at cpg lvl:

	.get_duty_cycle = rzv2h_cpg_plldsi_smux_get_duty_cycle,
	.set_duty_cycle = rzv2h_cpg_plldsi_smux_set_duty_cycle,

That select parent based on requested duty cycle:

  - If duty > 50% (num/den > 1/2), select LVDS path (parent 0)
  - Otherwise, select DSI/RGB path (parent 1)

Then at DRM lvl we can go for:

	if (rzg2l_du_has(rcdu, RG2L_DU_FEATURE_SMUX2_DSI_CLK)) {
	    struct clk *clk_parent;

	    clk_parent = clk_get_parent(rcrtc->rzg2l_clocks.dclk);

	    /*
	     * Request appropriate duty cycle to let clock driver select
	     * the correct parent:
	     * - CDIV7_DSIx_CLK (LVDS path) has DUTY H/L=4/3, 4/7 duty cycle.
	     * - CSDIV_2to16_PLLDSIx (DSI/RGB path) has symmetric 50% duty cycle.
	     */
	    if (rstate->outputs == BIT(RZG2L_DU_OUTPUT_LVDS0) ||
    		rstate->outputs == BIT(RZG2L_DU_OUTPUT_LVDS1))
	      clk_set_duty_cycle(clk_parent, 4, 7);
	    else
	      clk_set_duty_cycle(clk_parent, 1, 2);
	  }

What do you think? Please correct me if I'm wrong.
Glad to hear from Laurent's input too.

Thank you both in advance.

Kind Regards,
Tommaso


> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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
>