RE: [PATCH v7 06/13] clk: renesas: Add support for R9A09G077 SoC

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

 



Hi Geert,

> -----Original Message-----
> From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> Sent: mercredi 23 avril 2025 10:52
> To: Thierry Bultel <thierry.bultel.yh@xxxxxxxxxxxxxx>
> Cc: thierry.bultel@xxxxxxxxxxx; linux-renesas-soc@xxxxxxxxxxxxxxx; Paul
> Barker <paul.barker.ct@xxxxxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
> linux-clk@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v7 06/13] clk: renesas: Add support for R9A09G077 SoC
> 
> Hi Thierry,
> 
> On Wed, 23 Apr 2025 at 09:36, Thierry Bultel
> <thierry.bultel.yh@xxxxxxxxxxxxxx> wrote:
> > > From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> On Fri, 18 Apr 2025
> > > at 23:22, Thierry Bultel <thierry.bultel.yh@xxxxxxxxxxxxxx> wrote:
> > >  > +};
> > > > > > +
> > > > > > +static const struct mssr_mod_clk r9a09g077_mod_clks[]
> > > > > > +__initconst =
> > > {
> > > > > > +       DEF_MOD("sci0", 108, R9A09G077_PCLKM),
> > > > >
> > > > > Shouldn't that be 8 instead of 108?
> > > > > Using R9A09G077_PCLKM as the parent is a temporary
> > > > > simplification,
> > > right?
> > > >
> > > > I am probably missing something, isn’t PCKML actually the parent
> clock ?
> > >
> > > According to Figure 7.1 ("Block diagram of clock generation
> > > circuit"), it is PCLKSCI0, which can be switched to PCLKM.  I guess
> > > that is the default, hence my "temporary simplification" question.
> > >
> > > As the actual switching is controlled through the SCI's CCR3
> > > register, the SCI block should have two clock inputs in DT (PCLKM
> > > and PCLKSCIn), and thus the DT bindings should be amended.  See also
> > > Figure 33.1 ("SCI block diagram").
> > >
> >
> > Thanks for clarifying.
> > Indeed, this is the default setting (and the one we have at this stage).
> > I think that support for PCLKSCIn can be added at the time we support
> > baudrate setting.
> 
> I am not sure we can do that in a clean backwards-compatible way.
> Currently the DT bindings describe a single clock:
> 
>   clock-names:
>     const: fck # UART functional clock
> 
> The documentation calls the two clocks:
>   - Bus clock (PCLKM),
>   - Operation clock (PCLKSCIn).
> 
> Which one is the functional clock? I'd say the latter...
> Currently, DT says:
> 
>         clocks = <&cpg CPG_MOD 8>;
>         clock-names = "fck";
> 
> and the clock driver uses PCLKM as the module's parent clock, I think you
> will have a very hard time to synchronize all of the clock driver, sci
> driver, and DTS when transitioning to something like:
> 
>         clocks = <&cpg CPG_MOD 8>, <&cpgR9A09G077_PCLKM>;
>         clock-names = "fck", "bus";
> 
> where the modulo clock has to become PCLKSCIn (actually SCInASYNC, as seen
> from the CPG).
> 
> Does that make sense, or am I missing something?

You are right, I completely understand how hard it would be to have backward compatibility.
However, doing so:

		clocks = <&cpg CPG_MOD R9A09G077_PCLK_SCI0>, <&cpg CPG_CORE R9A09G077_CLK_PCLKM>;
		clock-names = "fck", "bus";

without modifying the sh-sci driver (yet) would lead to this bogus clk_summary:

  clock                          count    count    count        rate   accuracy phase  cycle    enable   consumer                         id
---------------------------------------------------------------------------------------------------------------------------------------------
 loco                                0       0        0        1000000     0          0     50000      Y   deviceless                      no_connection_id         
 extal                               1       1        0        25000000    0          0     50000      Y   clock-controller@80280000       extal                    
                                                                                                           deviceless                      no_connection_id         
    .pll4                            1       1        0        2400000000  0          0     50000      Y      deviceless                      no_connection_id         
       .sel_pll4                     1       1        0        2400000000  0          0     50000      Y         deviceless                      no_connection_id         
          .sel_clk_pll4              1       1        0        2400000000  0          0     50000      Y            deviceless                      no_connection_id         
             .pll4d1                 1       1        0        2400000000  0          0     50000      Y               deviceless                      no_connection_id         
                .sci0async           1       1        0        100000000   0          0     50000      Y                  deviceless                      no_connection_id         
                   sci0              2       2        0        100000000   0          0     50000      Y                     80005000.serial                 fck                      
                                                                                                                             deviceless                      of_clk_get_from_provider 
                                                                                                                             deviceless                      no_connection_id   

it is wrong because the actual default state is that PCKLM is used, not sci0async. 
Having PCKML consumed by sci0 is an obvious fix in sci_init_clocks, but it won't show up that only one clock is used at a time.

Couldn't it be better be solved by introducing an extra mux clock ? (the one controlled by BPEN) ?

Thanks !
Thierry

> 
> 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