Re: [PATCH v2 6/9] clk: renesas: rzv2h-cpg: Ignore monitoring CLK_MON bits for external clocks

From: Lad, Prabhakar
Date: Tue Apr 15 2025 - 15:10:59 EST


Hi Geert,

Thank you for the review.

On Tue, Apr 15, 2025 at 3:36 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>
> Hi Prabhakar,
>
> Thanks for your patch!
>
> On Mon, 7 Apr 2025 at 18:52, Prabhakar <prabhakar.csengg@xxxxxxxxx> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> >
> > Ignore CLK_MON bits when turning on/off module clocks that use an external
> > clock source.
> >
> > Introduce the `DEF_MOD_EXTERNAL()` macro for defining module clocks that
> > may have an external clock source. Update `rzv2h_cpg_register_mod_clk()`
> > to update mon_index.
>
> So I guess you implemented this because the external clock was not
> running, and you got into an infinite loop?
>
Yes, partially right but we didn't enter an infinite loop as we have a timeout.

For the CLK_MON, the HW manual for RZ/V2H section 4.4.4.8 CGC Control
Registers and 4.4.4.10 CGC Monitor Registers will be updated to below
in the next version.
"The clock gating cells require source clocks to operate correctly.
If the source clocks are stopped, these registers cannot be used."

Currently without the series when we turn ON the clock the CLK_ON bit
gets set and to make sure it's turned ON the corresponding CLK_MON bit
is checked to ensure it's ON. When a request is made to turn ON the
clock first we check the CLK_MON bit and if it's being set we return
early as the clock was ON. This worked OK up until now where the
clocks used were internally generated.

In the case of RGMII interface where the Rx/Rx-180 clock was coming
from an PHY on an external pin the above didn't work as expected. When
we issued an unbind request on the glue driver all the clocks were
gated to OFF state i.e CLK_ON bits were set to '0'. Now when the bind
operation was requested the clocks were requested to be turned ON, ie
when CLK_MON bits for RX/Rx-180 reported to be '1' that is because
PHY was providing the clock and due to which the CLK_ON bit was unset
(and not gated to ON state) due to which the DMA reset operation
failed in dwmac-core driver.

Below is the thread,
[0] https://lore.kernel.org/all/CA+V-a8uWY1Av8eS1k9C6Td=RuB4PbCnQyXbNLzmhao0nr8Spbg@xxxxxxxxxxxxxx/

> This looks rather fragile to me. How do you know when the clock
> is actually running, and thus usable?
>
I was thinking the consumer driver would request the external device
to turn it ON/OFF.

> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
>
> > --- a/drivers/clk/renesas/rzv2h-cpg.c
> > +++ b/drivers/clk/renesas/rzv2h-cpg.c
> > @@ -569,6 +569,25 @@ static void rzv2h_mod_clock_mstop_disable(struct rzv2h_cpg_priv *priv,
> > spin_unlock_irqrestore(&priv->rmw_lock, flags);
> > }
> >
> > +static bool rzv2h_mod_clock_is_external(struct rzv2h_cpg_priv *priv,
> > + u16 ext_clk_offset,
>
> unsigned int
>
> > + u8 ext_clk_bit,
>
> unsigned int
>
> > + u8 ext_cond)
>
> bool
>
Agreed I 'll change to the above.

> > +{
> > + u32 value;
> > +
> > + if (!ext_clk_offset)
> > + return false;
> > +
> > + value = readl(priv->base + ext_clk_offset) & BIT(ext_clk_bit);
> > + value >>= ext_clk_bit;
>
> No need to shift:
>
> return !!value == ext_cond;
>
OK.

> > +
> > + if (value == ext_cond)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > static int rzv2h_mod_clock_is_enabled(struct clk_hw *hw)
> > {
> > struct mod_clock *clock = to_mod_clock(hw);
> > @@ -691,6 +710,11 @@ rzv2h_cpg_register_mod_clk(const struct rzv2h_mod_clk *mod,
> > clock->on_index = mod->on_index;
> > clock->on_bit = mod->on_bit;
> > clock->mon_index = mod->mon_index;
> > + /* If clock is coming from external source ignore the monitor bit for it */
> > + if (rzv2h_mod_clock_is_external(priv, mod->external_clk_offset,
> > + mod->external_clk_bit,
> > + mod->external_cond))
>
> Perhaps just pass "mod" instead of three of its members, to fully
> hide the logic inside the helper function?
>
Agreed.

Cheers,
Prabhakar