RE: [PATCH v3 07/10] arm64: dts: renesas: Add initial DTSI for RZ/G3L SoC
From: Biju Das
Date: Fri Mar 06 2026 - 06:57:57 EST
Hi Geert,
> -----Original Message-----
> From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> Sent: 06 March 2026 09:25
> Subject: Re: [PATCH v3 07/10] arm64: dts: renesas: Add initial DTSI for RZ/G3L SoC
>
> Hi Biju,
>
> On Fri, 6 Mar 2026 at 10:10, Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > > From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> On Thu, 5 Mar 2026
> > > at 17:58, Biju Das <biju.das.jz@xxxxxxxxxxxxxx> wrote:
> > > > > From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> On Tue, 3 Feb
> > > > > 2026 at 11:30, Biju <biju.das.au@xxxxxxxxx> wrote:
> > > > > > Add the initial DTSI for the RZ/G3L SoC.
> > > > > > The files in this commit have the following meaning:
> > > > > > - r9a08g046.dtsi: RZ/G3L family SoC common parts
> > > > > > - r9a08g046l48.dtsi: RZ/G3L R0A08G046L{46,48} SoC specific
> > > > > > parts
> > > > > >
> > > > > > Added place holders to reuse the code for Renesas SMARC II
> > > > > > carrier board.
> > > > > >
> > > > > > Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > >
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
> > > =
> > > > > > + dmac: dma-controller@11820000 {
> > > > >
> > > > > Unused. Surely you can wire up scif0?
> > > >
> > > > Yes, but I don't get login prompt, as SCIF0 interrupts have
> > > > dependency on DMA reset/clocks to route the interrupts to CPU.
> > >
> > > Aha ;-)
> > >
> > > So you need to enable the DMA clock and deassert the DMA reset in
> > > the clock/reset driver, and mark them critical.
> >
> > For CLK, already framework is providing critical clock support, which turns on the clk at the start.
> > But for reset there is no support for critical reset in the reset framework.
> >
> > you mean handle this in SoC specific driver for DMA deassert like[1]
> > DEF_RST_INIT_DEASSERTED during boot??
> >
> > Or
> >
> > Create a critical reset table in the SoC specific driver like clk and
> > explicitly deassert the resets in CPG core driver during probe??
>
> The latter sounds simpler to me...
OK.
>
> You also have to avoid the DMAC is reset is ever being asserted again.
Agreed.
>
> > Note:
> > For Suspend to RAM, marking critical clock/critical reset won't solve
> > the issue as we need to explicitly turn on DMA CLK/dessert reset for routing SCIF0 irq to CPU.
>
> So you need to add suspendresume support to the clock driver, to enable the clock and deassert the
> reset during resume?
Will send patches for supporting critical reset and enabling critical clks for RZ/G2L
Family.
Cheers,
Biju