Re: [PATCH v2 3/7] clk: renesas: r8a779g0: Add display related clocks

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

 



Hi Tomi,

On Thu, Dec 1, 2022 at 10:26 AM Tomi Valkeinen
<tomi.valkeinen+renesas@xxxxxxxxxxxxxxxx> wrote:
> On 30/11/2022 21:18, Geert Uytterhoeven wrote:
> > On Wed, Nov 23, 2022 at 8:00 AM Tomi Valkeinen
> > <tomi.valkeinen+renesas@xxxxxxxxxxxxxxxx> wrote:
> >> Add clocks related to display which are needed to get the DSI output
> >> working.
> >>
> >> Extracted from Renesas BSP tree.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@xxxxxxxxxxxxxxxx>
> >> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@xxxxxxxxxxxxxxxx>
> >> Reviewed-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>

> >> --- a/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> >> +++ b/drivers/clk/renesas/r8a779g0-cpg-mssr.c

> >> +       DEF_MOD("dis0",                 411,    R8A779G0_CLK_S0D3),
> >
> > I doubt this parent clock is correct.
> > Based on Table 8.1.4e ("Lists of CPG clocks generated from PLL5"),
> > this should be one of the VIOBUS clocks.
> > VIOBUSD2 has the same rate as S0D3, so I'd use that one.
> >
> >> +       DEF_MOD("dsitxlink0",           415,    R8A779G0_CLK_DSIREF),
> >> +       DEF_MOD("dsitxlink1",           416,    R8A779G0_CLK_DSIREF),
>
> Now that you started questioning about the clocks, I started to wonder
> about the DSI clocks. They don't quite make sense to me, but here also I
> just assumed it's "fine" as I copied it and it works.
>
> The VIOBUS & VIOBUSD2 are marked to as going to the DSI. But we don't
> actually mark any of the DSI clocks as coming from those sources.
>
> DSIREF is quite clear, it's the source for DSI PLL.
>
> DSIEXT goes to the DSI PHY and is also marked to be used for LP-TX.
>
> In the DT we have now:
>
> clocks = <&cpg CPG_MOD 415>,
>          <&cpg CPG_CORE R8A779G0_CLK_DSIEXT>,
>          <&cpg CPG_CORE R8A779G0_CLK_DSIREF>;
> clock-names = "fck", "dsi", "pll";
>
> The "dsi" clock name is a bit vague, but maybe it's "not fclk, not pll,
> but still needed for dsi"? =)
>
> Is it ok to refer to DSIEXT & DSIREF like that, or should they be in the

Sounds fine to me.

> r8a779g0_mod_clks list? Or is that list for fclks only?

That list is only for clocks which have a bit in an MSTPCR (module
stop control register, Section 9.2.3).  These are typically controlled
through the Clock Domain and Runtime PM (but not for the DU, as there
is always only a single node in DT, even when the DU has multiple module
clocks on R-Car Gen2/3).

Actually our abstraction may be a bit off: sometimes that bit may gate
multiple clocks leading to the module, but as that was never documented
well, we settled on a single functional clock only, which is the most
common case.

> So the fclk in the dts is mod clock 415 (416 for the second dsi), which
> is dsitxlink0 or dsitxlink1. Well, those names don't quite make sense if
> it's a fclk.
>
> I would rename those clocks to "dsi0" and "dsi1", and source them from
> R8A779G0_CLK_VIOBUSD2, similarly to the other video clocks.
>
> Does the above make sense?

Please keep the names, as that's how they are called in Section 9.2.3.5
("Module Stop Control Register 4 (MSTPCR4)").

Thanks!

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



[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