Message-ID:
 <TY3PR01MB11346A05C348FE0AE83203FEA8666A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Fri, 6 Feb 2026 07:25:36 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Claudiu.Beznea <claudiu.beznea@...on.dev>, geert <geert@...ux-m68k.org>
CC: "vkoul@...nel.org" <vkoul@...nel.org>, Prabhakar Mahadev Lad
	<prabhakar.mahadev-lad.rj@...renesas.com>, "lgirdwood@...il.com"
	<lgirdwood@...il.com>, "broonie@...nel.org" <broonie@...nel.org>,
	"perex@...ex.cz" <perex@...ex.cz>, "tiwai@...e.com" <tiwai@...e.com>,
	"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>, "geert+renesas@...der.be"
	<geert+renesas@...der.be>, Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
	"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-sound@...r.kernel.org" <linux-sound@...r.kernel.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: RE: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM support

Hi All,

> -----Original Message-----
> From: Biju Das
> Sent: 05 February 2026 17:42
> Subject: RE: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM support
> 
> Hi Claudiu,
> 
> > -----Original Message-----
> > From: Claudiu Beznea <claudiu.beznea@...on.dev>
> > Sent: 05 February 2026 17:21
> > Subject: Re: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM
> > support
> >
> > Hi, Biju,
> >
> > On 2/5/26 16:06, Biju Das wrote:
> > > Hi Geert,
> > >
> > >> -----Original Message-----
> > >> From: Geert Uytterhoeven <geert@...ux-m68k.org>
> > >> Sent: 05 February 2026 13:34
> > >> Subject: Re: [PATCH 5/7] dmaengine: sh: rz-dmac: Add suspend to RAM
> > >> support
> > >>
> > >> Hi Biju,
> > >>
> > >> On Thu, 5 Feb 2026 at 14:30, Biju Das <biju.das.jz@...renesas.com> wrote:
> > >>>> From: Claudiu Beznea <claudiu.beznea@...on.dev> On 1/26/26 17:28,
> > >>>> Biju Das wrote:
> > >>>>>> For s2idle issue on RZ/G3L is DMA device is in asserted state,
> > >>>>>> not forwarding any IRQ to cpu for wakeup.
> > >>>>>>
> > >>>>>> For S2RAM issue on RZ/G3L is during suspend hardware turns
> > >>>>>> DMAACLK off/ Asserted state. Clock framwork is not turning On DMAACLK as it critical clk.
> > >>>>>>
> > >>>>>> Can you please check your TF-A for the second case? First case,
> > >>>>>> RZ/G3S may ok for reset assert state, it can forward IRQs to CPU.
> > >>>>>
> > >>>>> Just to summarize, currently there are 2 differences identified between RZ/G3S and RZ/G3L:
> > >>>>>
> > >>>>> SoC differences for s2idle:
> > >>>>>
> > >>>>> RZ/G3S: Can wake the system if the DMA device is in the assert
> > >>>>> state
> > >>>>>
> > >>>>> RZ/G3L: Cannot wake the system if the DMA device is in the assert state.
> > >>>>>
> > >>>>>
> > >>>>> TF-A differences for s2ram:
> > >>>>>
> > >>>>> RZ/G3S: TF_A turns on DMA_ACLK during boot/resume.
> > >>>>>
> > >>>>> RZ/G3L: TF_A does not handle DMA_ACLK during boot/resume.
> > >>>>
> > >>>> I'm seeing at [1] you are addressing these differences in the
> > >>>> clock/reset drivers. With that, are you still considering this patch is breaking your system?
> > >>>
> > >>> Still, thinking whether to add critical reset or go with SoC quirk in DMA driver.
> > >>> Some SoCs need DMA should be deasserted like critical clock that
> > >>> can be handled either
> > >>>
> > >>> 1) Add a simple SoC quirk in DMA driver
> > >>>
> > >>> Or
> > >>>
> > >>> 2) Implement critical reset in SoC specific clock driver and check for all resets.
> > >>>
> > >>> Is simple SoC quirk in DMA driver, something can be done for RZ/G2L family SoCs?
> > >>
> > >> What if the DMA driver is not enabled?
> > >
> > > The below use cases will work (patch[1] - removing the code for
> > > deassert in cpg_resume) as there is no DMA driver to assert the reset.
> > >
> > > 1) system will boot without DMA driver
> > > 2) s2idle will work as there is no DMA driver to assert the reset.
> > > 3) s2ram will work without DMA driver.
> > >
> > > If DMA driver is enabled, then there is an issue with  s2idle as DMA
> > > driver assert the reset and we cannot use serial console as wakeup
> > > source
> >
> > I think we're taking here about both DMA clocks and resets.
> >
> > What if the DMA clocks are declared critical in Linux and clocks and
> > resets are not handled by bootloader in probe or resume? Who will restore critical clocks?
> 
> Patch [1] will restore critical clocks.
> >
> > >
> > > One solution is SoC quirk will prevent assert/deassert  of the DMA
> > > reset during
> > > suspend/resume() for affected SoCs.
> >
> > This can't work w/o taking care of the DMA clocks in the clock driver
> > resume function (in case DMA clocks are critical). If so, why handling DMA clocks and resets
> differently?
> 
> 
> What will you prefer
> 
> a single check in suspend/resume of DMA driver?
> 
> Or
> 
> Around 100 checks in suspend/resume in clock driver for checking critical resets for skipping DMA
> reset?

Just FYI,

With patch [1] alone + DMA as critical clock all the use case works on RZ/G3L.

1) System can boot without DMA driver
2) s2idle with serial wakeup works with DMA assert in DMA driver
3) s2ram works.
4) system can boot without bootloader turning DMA clocks/resets.

The issue we are discussing, if we remove, the cpg_suspend code from patch[1]
that will lead to s2idle breakage with serial console as wakeup source because
this patch does a DMA assert and Serial IRQ is not routed to CPU for Wakeup.


So, either implement one of the solutions to support this patch

1) Implement critical reset in reset framework

2) custom implementation in Renesas reset driver

3) Using SoC compatible and avoid assert in DMA driver in affected SoCs 

4) just use patch [1]

Looking for efficient handling for this s2idle breakage with serial console
as wakeup source.

Cheers,
Biju

Powered by blists - more mailing lists