Re: [PATCH v2 9/9] clk: renesas: r9a09g057: Add clock and reset entries for GBETH0/1

[Geert Uytterhoeven]

Hi Prabhakar,

On Tue, 15 Apr 2025 at 21:25, Lad, Prabhakar <prabhakar.csengg@xxxxxxxxx> wrote:
> On Tue, Apr 15, 2025 at 3:37 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
> > On Mon, 7 Apr 2025 at 18:52, Prabhakar <prabhakar.csengg@xxxxxxxxx> wrote:
> > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > >
> > > Add clock and reset entries for GBETH instances. Include core clocks for
> > > PTP, sourced from PLLETH, and add PLLs, dividers, and static mux clocks
> > > used as clock sources for the GBETH IP.
> > >
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/clk/renesas/r9a09g057-cpg.c
> > > +++ b/drivers/clk/renesas/r9a09g057-cpg.c
> >
> > > @@ -78,6 +87,19 @@ static const struct clk_div_table dtable_2_64[] = {
> > >         {0, 0},
> > >  };
> > >
> > > +static const struct clk_div_table dtable_2_100[] = {
> > > +       {0, 2},
> > > +       {1, 10},
> > > +       {2, 100},
> > > +       {0, 0},
> > > +};
> > > +
> > > +/* Mux clock tables */
> > > +static const char * const smux2_gbe0_rxclk[] = { ".plleth_gbe0", "et0-rxc-rxclk" };
> > > +static const char * const smux2_gbe0_txclk[] = { ".plleth_gbe0", "et0-txc-txclk" };
> > > +static const char * const smux2_gbe1_rxclk[] = { ".plleth_gbe1", "et1-rxc-rxclk" };
> > > +static const char * const smux2_gbe1_txclk[] = { ".plleth_gbe1", "et1-txc-txclk" };
> >
> > The "et[01]-[rt]xc-[rt]xclk" clocks are not created by this driver.
> > IIUIC, they are actually Ethernet PHY signals.
> > How is this supposed to work?
> >
> My intention was to add support for PHY drivers to provide the clocks
> and hook them up accordingly. Currently, for the RX clocks, we get a
> rate of 0 since they are external.

So the link would not be provided by DT?
If these clocks are inputs to the clock controller, they should be
listed in the clock controller's clock{,-name}s' properties...

> I haven’t written a prototype yet for the PHY driver to provide the
> clocks, but the plan is to get the initial pieces in place and then
> extend support for that.
>
> Is my understanding correct that the PHY should provide the clocks? Or
> would you suggest a different approach?

The Static Mux Control Registers (CPG_SSEL[01]) registers treat them as
clock inputs.  However, Figure 6.3-1 ("Block Diagram of the Ethernet
Interface") shows the TX clocks are bidirectional, so they can be used
as either inputs or outputs?  On RGMII[1], RXC is an input (PHY-to-MAC),
while TXC is an output (MAC-to-PHY).

I'm a bit lost on how this works, and how to model and handle this...

[1] https://en.wikipedia.org/wiki/Media-independent_interface#Reduced_gigabit_media-independent_interface

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

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