From: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Stephen Boyd <sboyd@kernel.org>,
Brian Masney <bmasney+clk@redhat.com>,
Jerome Brunet <jbrunet+clk@baylibre.com>,
linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, biju.das.jz@bp.renesas.com,
tomm.merciai@gmail.com
Subject: Re: [PATCH 2/2] clk: renesas: rzv2h: Report the DSI duty cycle from the LVDS divider
Date: Wed, 4 Nov 2026 17:05:32 +0100 [thread overview]
Message-ID: <autXzHgNjFVf9Oyn@tom-desktop> (raw)
In-Reply-To: <CAMuHMdX5XuDpdmcUhPHU_uNggpXq_L=6DRSN3ftWEApubu+VMw@mail.gmail.com>
Hi Geert,
On Mon, Nov 02, 2026 at 05:16:09PM +0100, Geert Uytterhoeven wrote:
> Hi Tommaso,
>
> Thanks for your patch!
>
> On Thu, 29 Oct 2026 at 15:26, Tommaso Merciai
> <tommaso.merciai.xr@bp.renesas.com> wrote:
> > The 4/7 duty cycle of the LVDS path comes from the division by 7, not from
> > the PLLDSI mux, as an odd divider cannot produce a 50% duty cycle.
>
> Note that the latter is not true in general: if an odd divider looks
> at both edges of the parent clock signal, the output will have a 50%
> duty cycle (assumed the parent has a 50% duty cycle).
> If an odd divider looks only at rising or falling edges, the output
> will indeed have a non-50% duty cycle.
Thanks for sharing.
>
> > Report it from a dedicated LVDS divider clock type and let the core walk up
> > to the selected parent through CLK_DUTY_CYCLE_PARENT. The reported values
> > do not change, the mux keeps selecting the path, and its duty cycle
> > constants go away.
> >
> > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> i.e. will queue in renesas-clk for v7.5.
>
> > --- a/drivers/clk/renesas/rzv2h-cpg.c
> > +++ b/drivers/clk/renesas/rzv2h-cpg.c
>
> > @@ -890,6 +863,94 @@ rzv2h_cpg_fixed_mod_status_clk_register(const struct cpg_core_clk *core,
> > return &clk_hw_data->fix.hw;
> > }
> >
> > +static int rzv2h_cpg_plldsi_div_lvds_get_duty_cycle(struct clk_hw *hw,
> > + struct clk_duty *duty)
> > +{
> > + struct clk_fixed_factor *fix = to_clk_fixed_factor(hw);
> > +
> > + /*
> > + * An odd divider cannot generate a 50% duty cycle: the output stays
> > + * high for (div + 1) / 2 input clock cycles out of div, e.g. a divider
> > + * of 7 gives a duty cycle of 4/7.
> > + */
> > + duty->num = DIV_ROUND_UP(fix->div, 2);
> > + duty->den = fix->div;
> > +
> > + return 0;
> > +}
> > +
> > +static int rzv2h_cpg_plldsi_div_lvds_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req)
> > +{
> > + return clk_fixed_factor_ops.determine_rate(hw, req);
> > +}
> > +
> > +static int rzv2h_cpg_plldsi_div_lvds_set_rate(struct clk_hw *hw,
> > + unsigned long rate,
> > + unsigned long parent_rate)
> > +{
> > + return clk_fixed_factor_ops.set_rate(hw, rate, parent_rate);
> > +}
> > +
> > +static unsigned long rzv2h_cpg_plldsi_div_lvds_recalc_rate(struct clk_hw *hw,
> > + unsigned long parent_rate)
> > +{
> > + return clk_fixed_factor_ops.recalc_rate(hw, parent_rate);
> > +}
> > +
> > +static unsigned long
> > +rzv2h_cpg_plldsi_div_lvds_recalc_accuracy(struct clk_hw *hw,
> > + unsigned long parent_accuracy)
> > +{
> > + return clk_fixed_factor_ops.recalc_accuracy(hw, parent_accuracy);
> > +}
> > +
> > +static const struct clk_ops rzv2h_cpg_plldsi_div_lvds_ops = {
> > + .determine_rate = rzv2h_cpg_plldsi_div_lvds_determine_rate,
> > + .set_rate = rzv2h_cpg_plldsi_div_lvds_set_rate,
> > + .recalc_rate = rzv2h_cpg_plldsi_div_lvds_recalc_rate,
> > + .recalc_accuracy = rzv2h_cpg_plldsi_div_lvds_recalc_accuracy,
> > + .get_duty_cycle = rzv2h_cpg_plldsi_div_lvds_get_duty_cycle,
> > +};
> > +
> > +static struct clk_hw * __init
> > +rzv2h_cpg_plldsi_div_lvds_clk_register(const struct cpg_core_clk *core,
> > + struct rzv2h_cpg_priv *priv)
> > +{
> > + struct clk_init_data init = { };
> > + struct clk_fixed_factor *fix;
> > + const struct clk_hw *parent;
> > + const char *parent_name;
> > + int ret;
> > +
> > + WARN_DEBUG(core->parent >= priv->num_core_clks);
> > + parent = priv->clks[core->parent];
> > + if (IS_ERR(parent))
> > + return ERR_CAST(parent);
> > +
> > + parent_name = clk_hw_get_name(parent);
> > +
> > + fix = devm_kzalloc(priv->dev, sizeof(*fix), GFP_KERNEL);
> > + if (!fix)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + init.name = core->name;
> > + init.ops = &rzv2h_cpg_plldsi_div_lvds_ops;
> > + init.flags = CLK_SET_RATE_PARENT;
> > + init.parent_names = &parent_name;
> > + init.num_parents = 1;
> > +
> > + fix->hw.init = &init;
> > + fix->mult = core->mult;
> > + fix->div = core->div;
> > +
> > + ret = devm_clk_hw_register(priv->dev, &fix->hw);
> > + if (ret)
> > + return ERR_PTR(ret);
> > +
> > + return &fix->hw;
> > +}
> > +
> > static struct clk_hw
> > *rzv2h_cpg_clk_src_twocell_get(struct of_phandle_args *clkspec,
> > void *data)
>
> Since there are now two copies of this code (see rzg3l_cpg_lvds_div_*),
> perhaps the time is ripe to add odd duty cycle support to
> clk_fixed_factor? As duty->num can be rounded up or down, I am
> envisioning two new mutually-exclusive fixflags parameters, e.g.:
>
> CLK_FIXED_FACTOR_ODD_DUTY_DOWN
> CLK_FIXED_FACTOR_ODD_DUTY_UP
>
> What do you think?
Agreed, thanks. I can send send a separate series, adding both flags
into:
- drivers/clk/clk-fixed-factor.c
In thi way later we can converts:
- drivers/clk/renesas/rzv2h-cpg.c
- drivers/clk/renesas/rzg2l-cpg.c
To the newly added CLK_FIXED_FACTOR_ODD_DUTY_UP.
Not sure about CLK_FIXED_FACTOR_ODD_DUTY_DOWN which has nos users for
now. Please correct me if I'm wrong.
Kind regards,
Tommaso
> Thanks!
>
> 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
prev parent reply other threads:[~2026-11-04 16:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 14:25 [PATCH 0/2] Renesas RZ/G3E DSI/LVDS clk improvements Tommaso Merciai
2026-10-29 14:25 ` [PATCH 1/2] clk: renesas: rzv2h: Forward PLLDSI mux rate requests to the parent Tommaso Merciai
2026-11-02 16:03 ` Geert Uytterhoeven
2026-10-29 14:25 ` [PATCH 2/2] clk: renesas: rzv2h: Report the DSI duty cycle from the LVDS divider Tommaso Merciai
2026-11-02 16:16 ` Geert Uytterhoeven
2026-11-04 16:05 ` Tommaso Merciai [this message]
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=autXzHgNjFVf9Oyn@tom-desktop \
--to=tommaso.merciai.xr@bp.renesas.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=bmasney+clk@redhat.com \
--cc=geert@linux-m68k.org \
--cc=jbrunet+clk@baylibre.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=sboyd@kernel.org \
--cc=tomm.merciai@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®