Received-SPF: pass (google.com: domain of linux-kernel+bounces-204187-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240524082800.333991-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
 <20240524082800.333991-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
 <CAMuHMdWzrEKFHauJ=6UnsufJjDO3LfJ45eJXx1V72AmVzvsjyw@mail.gmail.com> <CAMuHMdXdFM2u5TjRQZCSiigC=uBk1kz6aW6hYTy5Wa=PCgX7yQ@mail.gmail.com>
In-Reply-To: <CAMuHMdXdFM2u5TjRQZCSiigC=uBk1kz6aW6hYTy5Wa=PCgX7yQ@mail.gmail.com>
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Date: Thu, 6 Jun 2024 12:36:17 +0100
Message-ID: <CA+V-a8sch-XTk2ByBztEQd3QDef4RbVt7k-k=GnJGd-XvAkAdg@mail.gmail.com>
Subject: Re: [PATCH 1/4] dt-bindings: clock: renesas: Document RZ/V2H(P) SoC
 CPG driver
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, 
	Rob Herring <robh@kernel.org>, Krzysztof Kozlowski <krzk+dt@kernel.org>, Conor Dooley <conor+dt@kernel.org>, 
	Philipp Zabel <p.zabel@pengutronix.de>, Magnus Damm <magnus.damm@gmail.com>, 
	linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org, 
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, 
	Fabrizio Castro <fabrizio.castro.jz@renesas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Geert,

Thank you for the review.

On Wed, Jun 5, 2024 at 10:42=E2=80=AFAM Geert Uytterhoeven <geert@linux-m68=
k.org> wrote:
>
> Hi Prabhakar,
>
> On Tue, Jun 4, 2024 at 5:49=E2=80=AFPM Geert Uytterhoeven <geert@linux-m6=
8k.org> wrote:
> > On Fri, May 24, 2024 at 10:29=E2=80=AFAM Prabhakar <prabhakar.csengg@gm=
ail.com> wrote:
> > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > >
> > > Document the device tree bindings of the Renesas RZ/V2H(P) SoC
> > > Clock Pulse Generator (CPG).
> > >
> > > CPG block handles the below operations:
> > > - Handles the generation and control of clock signals for the IP modu=
les
> > > - The generation and control of resets
> > > - Control over booting
> > > - Low power consumption and the power supply domains
> > >
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com=
>
> >
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/clock/renesas,rzv2h-cpg.yaml
> > > +
> > > +  '#clock-cells':
> > > +    description: |
> > > +      - For CPG core clocks, the two clock specifier cells must be "=
CPG_CORE"
> > > +        and a core clock reference, as defined in
> > > +        <dt-bindings/clock/r9a09g057-cpg.h>,
> > > +      - For module clocks, the two clock specifier cells must be "CP=
G_MOD" and
> > > +        a module number, as defined in <dt-bindings/clock/r9a09g057-=
cpg.h>.
> > > +    const: 2
> >
> > I understand this will be changed to 1, the clock number?
>
> We typically come up with our own definitions in header files if there
> are no suitable module numbers listed in the hardware documentation.
>
Agreed.

> For RZ/V2H, you could use a combination (e.g. concatenation) of the
> column (register) and row (bit) numbers from Tables 4.4-14-19
> ("Specifications of the CPG_CLKON_m Registers") and Tables 4.4-22-25
> ("Specifications of the CPG_RST_m Registers") as the clock resp. reset
> number, like is done on R-Car Gen2+ SoCs (see MOD_CLK_PACK() for
> conversion from sparse to packed module numbers).
>
Thanks for the pointer.

I'll model as per your suggestion (this way we can avoid adding any
macros for module clocks) and dont have to worry about reserved bits.

Cheers,
Prabhakar